aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* More permissive "git-rm --cached" behavior without -f.Matthieu Moy2007-07-13
| | | | | | | | | | | | | | | | In the previous behavior, "git-rm --cached" (without -f) had the same restriction as "git-rm". This forced the user to use the -f flag in situations which weren't actually dangerous, like: $ git add foo # oops, I didn't want this $ git rm --cached foo # back to initial situation Previously, the index had to match the file *and* the HEAD. With --cached, the index must now match the file *or* the HEAD. The behavior without --cached is unchanged, but provides better error messages. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Document new --date=<format>Junio C Hamano2007-07-13
| | | | | | | Now, git-log family can take full range of internally supported date format to their --date=<format> argument. Document it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Wire new date formats to --date=<format> parser.Junio C Hamano2007-07-13
| | | | | | | | | | Now we can use all internally supported date formats with git log --date=<format> syntax. Earlier, we only allowed relative/local/default. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Make show_rfc2822_date() just another date output format.Junio C Hamano2007-07-13
| | | | | | | | | | | These days, show_date() takes a date_mode parameter to specify the output format, and a separate specialized function for dates in E-mails does not make much sense anymore. This retires show_rfc2822_date() function and make it just another date output format. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Support output ISO 8601 format datesRobin Rosenberg2007-07-13
| | | | | | | | Support output of full ISO 8601 style dates in e.g. git log and other places that use interpolation for formatting. Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'master' of git://git.kernel.org/pub/scm/gitk/gitkJunio C Hamano2007-07-13
|\ | | | | | | | | * 'master' of git://git.kernel.org/pub/scm/gitk/gitk: gitk: Fix bug introduced by previous commit
| * gitk: Fix bug introduced by previous commitPaul Mackerras2007-07-13
| | | | | | | | | | | | | | | | | | | | | | | | | | When I added the "--" case to the code scanning the arguments, I missed the fact that since the switch statement uses -regexp, the "--" case will match any argument containing "--", e.g. "--all". This fixes it by taking out the -regexp (since we don't actually need regular expression matching) and adjusting the match strings. A side effect of this is that previously any argument starting with "-d" would be taken to indicate date mode; now the argument has to be exactly "-d" if you want date mode. Signed-off-by: Paul Mackerras <paulus@samba.org>
* | Fix git-rebase -i to allow squashing of fast-forwardable commitsAlex Riesen2007-07-13
| | | | | | | | | | | | | | | | Without this change the commits will be left standalone, with duplicated commit message. Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | lockfile.c: schedule remove_lock_file only once.Sven Verdoolaege2007-07-13
| | | | | | | | | | | | | | Removing a lockfile once should be enough. Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | send-email: discard blank around address in extract_valid_address as well.Stephen Rothwell2007-07-13
| | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | make git-send-email.perl handle email addresses with no names when ↵Greg KH2007-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Email::Valid is present When using git-send-email.perl on a changeset that has: Cc: <stable@kernel.org> in the body of the description, and the Email::Valid perl module is installed on the system, the email address will be deemed "invalid" for some reason (Email::Valid isn't smart enough to handle this?) and complain and not send the address the email. Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Document git commit --untracked-files and --verboseJakub Narebski2007-07-12
| | | | | | | | | | | | | | | | | | | | | | Documentation based on description of commit 443f8338 which added '-u'|'--untracked-files' option to git-status, and on git-runstatus(1) man page. Note that those options apply also to git-status. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Document long options '--message=<msg>' and '--no-commit'Jakub Narebski2007-07-12
| | | | | | | | | | | | | | | | | | Document that '--message=<msg>' is long version of '-m <msg>' in git-commit, and that '--no-checkout' is long version of '-n' in git-clone. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Update git-merge documentation.Jakub Narebski2007-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add "Configuration" section to describe merge.summary configuration variable (which is mentioned in git-fmt-merge-msg(1) man page, but it is a plumbing command), and merge.verbosity configuration variable (so there is a place to make reference from "Environment Variables" section of git(7) man page) to the git-merge(1) man page. Also describe GIT_MERGE_VERBOSITY environment. The configuration variable merge.verbosity and environment variable GIT_MERGE_VERBOSITY were introduced in commit 8c3275ab, which also documented configuration variable but not environment variable. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Pack-objects: properly initialize the depth valueNicolas Pitre2007-07-12
| | | | | | | | | | | | | | | | | | | | Commit 5a235b5e was missing this little detail. Otherwise your pack will explode. Problem noted by Brian Downing. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | GIT v1.5.3-rc1v1.5.3-rc1Junio C Hamano2007-07-12
| | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'master' of git://git.kernel.org/pub/scm/gitk/gitkJunio C Hamano2007-07-12
|\ \ | |/ | | | | | | | | | | | | | | | | | | * 'master' of git://git.kernel.org/pub/scm/gitk/gitk: gitk: Improve handling of -- and ambiguous arguments gitk: Use git log and add support for --left-right gitk: Fix bug causing "can't read commitrow(0,n)" error [PATCH] gitk: Fix for tree view ending in nested directories gitk: Remove the unused stopfindproc function gitk: Fix bug in the anc_or_desc routine gitk: Fix the find and highlight functions
| * gitk: Improve handling of -- and ambiguous argumentsPaul Mackerras2007-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes gitk more consistent with git rev-list and git log in its handling of arguments that could be either a revision or a filename; now gitk displays an error message and quits, rather than treating it as a revision and getting an error in the underlying git log. Now gitk always passes "--" to git log even if no filenames are being specified. It also makes gitk display errors in invoking git log in a window rather than on stderr, and makes gitk stop looking for a -d flag when it sees a "--" argument. Signed-off-by: Paul Mackerras <paulus@samba.org>
| * gitk: Use git log and add support for --left-rightPaul Mackerras2007-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on patches from Linus Torvalds and Junio Hamano, so the ideas here are theirs. This makes gitk use "git log -z --pretty=raw" instead of "git rev-list" to generate the list of commits, and also makes it grok the "<" and ">" markers that git log (and git rev-list) output with the --left-right flag to indicate which side of a symmetric diff a commit is reachable from. Left-side commits are drawn with a triangle pointing leftwards instead of a circle, and right-side commits are drawn with a triangle pointing rightwards. The commitlisted list is used to store the left/right information as well as the information about whether each commit is on the boundary. Signed-off-by: Paul Mackerras <paulus@samba.org>
| * gitk: Fix bug causing "can't read commitrow(0,n)" errorPaul Mackerras2007-07-09
| | | | | | | | | | | | | | | | | | | | In commit 66e46f37de3ed3211a8ae0e8fc09c063bc3a1e08 I changed gitk to store ids in rowrangelist and idrowranges rather than row numbers, but I missed two places in the layouttail procedure. This resulted in occasional errors such as the "can't read "commitrow(0,8572)": no such element in array" error reported by Mark Levedahl. This fixes it by using the id rather than the row number. Signed-off-by: Paul Mackerras <paulus@samba.org>
| * [PATCH] gitk: Fix for tree view ending in nested directoriesBrian Downing2007-07-09
| | | | | | | | | | | | | | | | | | | | | | | | Unroll the prefix stack when assigning treeheights when leaving proc treeview. Previously, when the ls-tree output ended in multiple nested directories (for instance in a repository with a single file "foo/bar/baz"), $treeheight("foo/bar/") was assigned twice, and $treeheight("foo/") was never assigned. This led to an error when expanding the "foo" directory in the gitk treeview. Signed-off-by: Brian Downing <bdowning@lavos.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
| * gitk: Remove the unused stopfindproc functionPaul Mackerras2007-07-04
| | | | | | | | | | | | | | | | This was a hangover from before the "Files" and "Pickaxe" parts of the Find function were moved to the highlight facility in commit 60f7a7dc4904ba4baab44b70e2675a01e6172f54. It serves no useful purpose any more, so this removes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
| * gitk: Fix bug in the anc_or_desc routinePaul Mackerras2007-07-04
| | | | | | | | | | | | I missed the case where both nodes have no children and therefore have no incoming arcs. This fixes it. Signed-off-by: Paul Mackerras <paulus@samba.org>
| * gitk: Fix the find and highlight functionsPaul Mackerras2007-07-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reworks the way that the "Find" button (and the /, ?, ^F, and ^G keys) works. Previously, pressing the "Find" button would cause gitk to go off and scan through every commit to see which commits matched, and the user interface was completely unreponsive during that time. Now the searching is done in chunks using the scheduler, so the UI still responds, and the search stops as soon as a matching commit is found. The highlighting of matches using a yellow background is now done in the commit-drawing code and the highlighting code. This ensures that all the commits that are visible that match are highlighted without the search code having to find them all. This also fixes a bug where previously-drawn commits that need to be highlighted were not being highlighted. Signed-off-by: Paul Mackerras <paulus@samba.org>
* | gitweb: new cgi parameter: optMiklos Vajna2007-07-12
| | | | | | | | | | | | | | | | | | Currently the only supported value is '--no-merges' for the 'rss', 'atom', 'log', 'shortlog' and 'history' actions, but it can be easily extended to allow other parameters for other actions. Signed-off-by: Miklos Vajna <vmiklos@frugalware.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Add missing functions to contrib/emacs/vc-git.elDavid Kastrup2007-07-12
| | | | | | | | | | | | | | | | This is necessary to make several editing functions work, like C-u C-x v = Signed-off-by: David Kastrup <dak@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Documentation for git-log --followSteven Walter2007-07-12
| | | | | | | | | | | | | | | | | | | | | | After vainly searching the Documentation for how to follow renames, I finally broke down and grepped the source. It would appear that Linus didn't add write and docs for this feature when he wrote it. The following patch rectifies that, hopefully sparing future users from resorting to the source code. Signed-off-by: Steven Walter <stevenrwalter@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | reduce git-pack-objects memory usage a little moreNicolas Pitre2007-07-12
| | | | | | | | | | | | | | | | The delta depth doesn't have to be stored in the global object array structure since it is only used during the deltification pass. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Add documentation for --window-memory, pack.windowMemoryBrian Downing2007-07-12
| | | | | | | | | | | | Signed-off-by: Brian Downing <bdowning@lavos.net> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Add --window-memory option to git-repackBrian Downing2007-07-12
| | | | | | | | | | | | Signed-off-by: Brian Downing <bdowning@lavos.net> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Add pack-objects window memory usage limitBrian Downing2007-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds an option (--window-memory=N) and configuration variable (pack.windowMemory = N) to limit the memory size of the pack-objects delta search window. This works by removing the oldest unpacked objects whenever the total size goes above the limit. It will always leave at least one object, though, so as not to completely eliminate the possibility of computing deltas. This is an extra limit on top of the normal window size (--window=N); the window will not dynamically grow above the fixed number of entries specified to fill the memory limit. With this, repacking a repository with a mix of large and small objects is possible even with a very large window. Cleaner and correct circular buffer handling courtesy of Nicolas Pitre. Signed-off-by: Brian Downing <bdowning@lavos.net> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Add functions for parsing integers with size suffixesBrian Downing2007-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | Split out the nnn{k,m,g} parsing code from git_config_int into git_parse_long, so command-line parameters can enjoy the same functionality. Also add get_parse_ulong for unsigned values. Make git_config_int use git_parse_long, and add get_config_ulong as well. Signed-off-by: Brian Downing <bdowning@lavos.net> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Support fetching the memory usage of a delta indexBrian Downing2007-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Delta indices, at least on 64-bit platforms, tend to be larger than the actual uncompressed data. As such, keeping track of this storage is important if you want to successfully limit the memory size of your pack window. Squirrel away the total allocation size inside the delta_index struct, and add an accessor "sizeof_delta_index" to access it. Signed-off-by: Brian Downing <bdowning@lavos.net> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Don't try to delta if target is much smaller than sourceBrian Downing2007-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a new try_delta heuristic. Don't bother trying to make a delta if the target object size is much smaller (currently 1/32) than the source, as it's very likely not going to get a match. Even if it does, you will have to read at least 32x the size of the new file to reassemble it, which isn't such a good deal. This leads to a considerable performance improvement when deltifying a mix of small and large files with a very large window, because you don't have to wait for the large files to percolate out of the window before things start going fast again. Signed-off-by: Brian Downing <bdowning@lavos.net> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Correct shebang line for contrib/stats/packinfo.plBrian Downing2007-07-12
| | | | | | | | | | | | | | "/bin/perl"? What was I thinking? Signed-off-by: Brian Downing <bdowning@lavos.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | script to display a distribution of longest common hash prefixesNicolas Pitre2007-07-12
| | | | | | | | | | | | | | | | This script was originally posted on the git mailing list by Randal L. Schwartz <merlyn@stonehenge.com>. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | apply delta depth bias to already deltified objectsNicolas Pitre2007-07-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We already apply a bias on the initial delta attempt with max_size being a function of the base object depth. This has the effect of favoring shallower deltas even if deeper deltas could be smaller, and therefore creating a wider delta tree (see commits 4e8da195 and c3b06a69). This principle should also be applied to all delta attempts for the same object and not only the first attempt. With this the criteria for the best delta is not only its size but also its depth, so that a shallower delta might be selected even if it is larger than a deeper one. Even if some deltas get larger, they allow for wider delta trees making the depth limit less quickly reached and therefore better deltas can be subsequently found, keeping the resulting pack size even smaller. Runtime access to the pack should also benefit from shallower deltas. Testing on different repositories showed slighter faster repacks, smaller resulting packs, and a much nicer curve for delta depth distribution with no more peak at the maximum depth level. Improvements are even more significant with smaller depth limits. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Update list of older git docsJunio C Hamano2007-07-12
| |
* | Merge commit 'git-gui/master'Junio C Hamano2007-07-12
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * commit 'git-gui/master': (36 commits) git-gui: Change prior tree SHA-1 verification to use git_read git-gui: Include a space in Cygwin shortcut command lines git-gui: Use sh.exe in Cygwin shortcuts git-gui: Paper bag fix for Cygwin shortcut creation git-gui: Improve the Windows and Mac OS X shortcut creators git-gui: Teach console widget to use git_read git-gui: Perform our own magic shbang detection on Windows git-gui: Treat `git version` as `git --version` git-gui: Assume unfound commands are known by git wrapper git-gui: Correct gitk installation location git-gui: Always use absolute path to all git executables git-gui: Show a progress meter for checking out files git-gui: Change the main window progress bar to use status_bar git-gui: Extract blame viewer status bar into mega-widget git-gui: Allow double-click in checkout dialog to start checkout git-gui: Default selection to first matching ref git-gui: Unabbreviate commit SHA-1s prior to display git-gui: Refactor branch switch to support detached head git-gui: Refactor our ui_status_value update technique git-gui: Better handling of detached HEAD ...
| * | git-gui: Change prior tree SHA-1 verification to use git_readShawn O. Pearce2007-07-12
| | | | | | | | | | | | | | | | | | | | | This cat-file was done on maint, where we did not have git_read available to us. But here on master we do, so we should make use of it. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | Merge branch 'maint'Shawn O. Pearce2007-07-12
| |\ \ | | | | | | | | | | | | | | | | * maint: git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}
| * | | git-gui: Include a space in Cygwin shortcut command linesShawn O. Pearce2007-07-09
| | | | | | | | | | | | | | | | Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | git-gui: Use sh.exe in Cygwin shortcutsShawn O. Pearce2007-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Because we are trying to execute /bin/sh we know it must be a real Windows executable and thus ends with the standard .exe suffix. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | git-gui: Paper bag fix for Cygwin shortcut creationShawn O. Pearce2007-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We cannot execute the git directory, it is not a valid Tcl command name. Instead we just want to pass it as an argument to our sq proc. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | Merge branch 'maint'Shawn O. Pearce2007-07-09
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | * maint: git-gui: Don't linewrap within console windows git-gui: Correct ls-tree buffering problem in browser
| * | | | git-gui: Improve the Windows and Mac OS X shortcut creatorsShawn O. Pearce2007-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We now embed any GIT_* and SSH_* environment variables as well as the path to the git wrapper executable into the Mac OS X .app file. This should allow us to restore the environment properly when we restart. We also try to use proper Bourne shell single quoting when we can, as this avoids any sort of problems that might occur due to a path containing shell metacharacters. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | | git-gui: Teach console widget to use git_readShawn O. Pearce2007-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Now that we are pretty strict about setting up own absolute paths to any git helper (saving a marginal runtime cost to resolve the tool) we can do the same in our console widget by making sure all console execs go through git_read if they are a git subcommand, and if not make sure they at least try to use the Tcl 2>@1 IO redirection if possible, as it should be faster than |& cat. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | | git-gui: Perform our own magic shbang detection on WindowsShawn O. Pearce2007-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we cannot locate a .exe for a git tool that we want to run than it may just be a Bourne shell script as these are popular in Git. In such a case the first line of the file will say "#!/bin/sh" so a UNIX kernel knows what program to start to parse and run that. But Windows doesn't support shbang lines, and neither does the Tcl that comes with Cygwin. We can pass control off to the git wrapper as that is a real Cygwin program and can therefore start the Bourne shell script, but that is at least two fork+exec calls to get the program running. One to do the fork+exec of the git wrapper and another to start the Bourne shell script. If the program is run multiple times it is rather expensive as the magic shbang detection won't be cached across executions. On MinGW/MSYS we don't have the luxury of such magic detection. The MSYS team has taught some of this magic to the git wrapper, but again its slower than it needs to be as the git wrapper must still go and run the Bourne shell after it is called. We now attempt to guess the shbang line on Windows by reading the first line of the file and building our own command line path from it. Currently we support Bourne shell (sh), Perl and Python. That is the entire set of shbang lines that appear in git.git today. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | | git-gui: Treat `git version` as `git --version`Shawn O. Pearce2007-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We know that the version subcommand of git is special. It does not currently have an executable link installed into $gitexecdir and we therefore would never match it with one of our file exists tests. So we forward any invocations to it directly to the git wrapper, as it is a builtin within that executable. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
| * | | | git-gui: Assume unfound commands are known by git wrapperShawn O. Pearce2007-07-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we cannot locate a command in $gitexecdir on our own then it may just be because we are supposed to run it by `git $name` rather than by `git-$name`. Many commands are now builtins, more are likely to go in that direction, and we may see the hardlinks in $gitexecdir go away in future versions of git. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>