summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2007-05-24Merge branch 'maint'Libravatar Junio C Hamano3-10/+76
* maint: fix memory leak in parse_object when check_sha1_signature fails name-rev: tolerate clock skew in committer dates Update bash completion for git-config options Teach bash completion about recent log long options Teach bash completion about 'git remote update' Update bash completion header documentation Remove a duplicate --not option in bash completion Teach bash completion about git-shortlog Hide the plumbing diff-{files,index,tree} from bash completion Update bash completion to ignore some more plumbing commands
2007-05-24Merge branch 'master' of git://repo.or.cz/git/fastimport into maintLibravatar Junio C Hamano1-10/+71
* 'master' of git://repo.or.cz/git/fastimport: Update bash completion for git-config options Teach bash completion about recent log long options Teach bash completion about 'git remote update' Update bash completion header documentation Remove a duplicate --not option in bash completion Teach bash completion about git-shortlog Hide the plumbing diff-{files,index,tree} from bash completion Update bash completion to ignore some more plumbing commands
2007-05-24Make "git gc" pack all refs by defaultLibravatar Linus Torvalds1-2/+2
I've taught myself to use "git gc" instead of doing the repack explicitly, but it doesn't actually do what I think it should do. We've had packed refs for a long time now, and I think it just makes sense to pack normal branches too. So I end up having to do git pack-refs --all --prune in order to get a nice git repo that doesn't have any unnecessary files. So why not just do that in "git gc"? It's not as if there really is any downside to packing branches, even if they end up changing later. Quite often they don't, and even if they do, so what? Also, make the default for refs packing just be an unambiguous "do it", rather than "do it by default only for non-bare repositories". If you want that behaviour, you can always just add a [gc] packrefs = notbare in your ~/.gitconfig file, but I don't actually see why bare would be any different (except for the broken reason that http-fetching used to be totally broken, and not doing it just meant that it didn't even get fixed in a timely manner!). So here's a trivial patch to make "git gc" do a better job. Hmm? Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-24Teach mailsplit about Maildir'sLibravatar Fernando J. Pereda4-30/+133
Signed-off-by: Fernando J. Pereda <ferdy@gentoo.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-24Merge branch 'maint-1.5.1' into maintLibravatar Junio C Hamano2-0/+5
* maint-1.5.1: fix memory leak in parse_object when check_sha1_signature fails name-rev: tolerate clock skew in committer dates
2007-05-24fix memory leak in parse_object when check_sha1_signature failsLibravatar Carlos Rica1-0/+1
When check_sha1_signature fails, program is not terminated: it prints an error message and returns NULL, so the buffer returned by read_sha1_file should be freed before. Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-24name-rev: tolerate clock skew in committer datesLibravatar Junio C Hamano1-0/+4
In git.git repository, "git-name-rev v1.3.0~158" cannot name the rev, while adjacent revs can be named. This was because it gives up traversal from the tips of existing refs as soon as it sees a commit that has older commit timestamp than what is being named. This is usually a good heuristics, but v1.3.0~158 has a slightly older commit timestamp than v1.3.0~157 (i.e. it's child), as these two were made in a separate repostiory (in fact, in a different continent). This adds a hardcoded slop value (1 day) to the cut-off heuristics to work this kind of problem around. The current algorithm essentially runs around from the available tips down to ancient commits and names every single rev available that are newer than cut-off date, so a single day slop would not add that much overhead in repositories with long enough history where the performance of name-rev matters. I think the algorithm could be made a bit smarter by deepening the graph on demand as a new commit is asked to be named (this would require rewriting of name_rev() function not to recurse itself but use a traversal list like revision.c traverser does), but that would be a separate issue. Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-24Update bash completion for git-config optionsLibravatar Shawn O. Pearce1-2/+12
A few new configuration options grew out of the woodwork during the 1.5.2 series. Most of these are pretty easy to support a completion of, so we do so. I wanted to also add completion support for the <driver> part of merge.<driver>.name but to do that we have to look at all of the .gitattributes files and guess what the unique set of <driver> strings would be. Since this appears to be non-trivial I'm punting on it at this time. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-24Teach bash completion about recent log long optionsLibravatar Shawn O. Pearce1-2/+2
(Somewhat) recently git-log learned about --reverse (to show commits in the opposite order) and a looong time ago I think it learned about --raw (to show the raw diff, rather than a unified diff). These are both useful options, so we should make them easy for the user to complete. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-24Teach bash completion about 'git remote update'Libravatar Shawn O. Pearce1-2/+14
Recently the git-remote command grew an update subcommand, which can be used to execute git-fetch across multiple repositories in a single step. These can be configured with the 'remotes.*' configuration options, so we can offer completion for any name that matches and appears to be useful to git-remote update. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-23Merge branch 'maint'Libravatar Junio C Hamano3-31/+67
* maint: Fix possible coredump with fast-import --import-marks Refactor fast-import branch creation from existing commit fast-import: Fix crash when referencing already existing objects fast-import: Fix uninitialized variable Documentation: fix git-config.xml generation
2007-05-23Merge branch 'maint' of git://repo.or.cz/git/fastimport into maintLibravatar Junio C Hamano2-30/+66
* 'maint' of git://repo.or.cz/git/fastimport: Fix possible coredump with fast-import --import-marks Refactor fast-import branch creation from existing commit fast-import: Fix crash when referencing already existing objects fast-import: Fix uninitialized variable
2007-05-24Update bash completion header documentationLibravatar Shawn O. Pearce1-1/+14
1) Added a note about supporting the long options for most commands, as we have been doing so for quite some time. 2) Include a notice that these routines are covered by the GPL, as that may not be obvious, even though they are distributed as part of the core Git distribution. 3) Added a short section on how to send patches to the routines, and to whom they should get sent to. Currently that is me, as I am the active maintainer. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-23Merge branch 'maint-1.5.1' into maintLibravatar Junio C Hamano1-1/+1
* maint-1.5.1: Documentation: fix git-config.xml generation
2007-05-24Remove a duplicate --not option in bash completionLibravatar Shawn O. Pearce1-1/+1
This was just me being silly; I put the --not option into the completion list twice. There's no duplicates shown in the shell as the shell removes them before showing them to the user. But we really don't need the duplicates in the source script either. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-24Teach bash completion about git-shortlogLibravatar Shawn O. Pearce1-0/+23
We've had completion for git-log for quite some time, but just today I noticed we don't have it for the new builtin shortlog that runs git-log internally. This is indeed a handy thing to have completion for, especially when your branch names are of the Very-Very-Long-and-Hard/To-Type/Variety/That-Some-Use. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-24Hide the plumbing diff-{files,index,tree} from bash completionLibravatar Shawn O. Pearce1-3/+3
The diff-* programs are meant to be plumbing for the diff frontend; most end users aren't invoking these commands directly. Consequently we should avoid showing them as possible completions. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-24Fix possible coredump with fast-import --import-marksLibravatar Shawn O. Pearce2-5/+36
When e8438420bb7d368bec3647b90c557b9931582267 allowed us to reload the marks table on subsequent runs of fast-import we really broke things, as we set pack_id to MAX_PACK_ID for any objects we imported into the marks table. Creating a branch from that mark should fail as we attempt to read the object through a non-existant packed_git pointer. Instead we have to use the normal Git object system to locate the older commit, as we ourselves do not have a reference to the packed_git it resides in. This bug only occurred because t9300 was not complete enough. When we added the --import-marks feature we didn't actually test its implementation enough to verify the function worked as intended. I have corrected that, and included the changes as part of this fix. Prior versions of fast-import fail the new test(s); this commit allows them to pass. Credit for this bug find goes to Simon Hausmann <simon@lst.de> as he recently identified a similiar bug in the tree lazy-loading path. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-24Refactor fast-import branch creation from existing commitLibravatar Shawn O. Pearce1-27/+31
To resolve a corner case uncovered by Simon Hausmann I need to reuse the logic for the SHA-1 expression version of the 'from ' command within the mark version of the 'from ' command. This change doesn't alter any functionality, but is merely breaking the common code out to a function that I can reuse. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-23fast-import: Fix crash when referencing already existing objectsLibravatar Simon Hausmann1-1/+1
Commit a5c1780a0355a71b9fb70f1f1977ce726ee5b8d8 sets the pack_id of existing objects to MAX_PACK_ID. When the same object is referenced later again it is found in the local object hash. With such a pack_id fast-import should not try to locate that object in the newly created pack(s). Signed-off-by: Simon Hausmann <simon@lst.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-23fast-import: Fix uninitialized variableLibravatar Simon Hausmann1-0/+1
Fix uninitialized last_object->no_free variable that is accessed in store_object. Signed-off-by: Simon Hausmann <simon@lst.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-23Documentation: fix git-config.xml generationLibravatar James Bowes1-1/+1
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-23gitweb.perl - Optionally send archives as .zip filesLibravatar Mark Levedahl1-8/+17
git-archive already knows how to generate an archive as a tar or a zip file, but gitweb did not. zip archvies are much more usable in a Windows environment due to native support and this patch allows a site admin the option to deliver zip rather than tar files. The selection is done by inserting $feature{'snapshot'}{'default'} = ['x-zip', 'zip', '']; in gitweb_config.perl. Tar files remain the default option. Signed-off-by: Mark Levedahl <mdl123@verizon.net> Acked-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-23Merge branch 'fl/cvsserver'Libravatar Junio C Hamano1-0/+172
* fl/cvsserver: t9400: Add some basic pserver tests t9400: Add some more cvs update tests t9400: Add test cases for config file handling
2007-05-23Merge branch 'ar/progress'Libravatar Junio C Hamano2-1/+6
* ar/progress: Fix the progress code to output LF only when it is really needed
2007-05-23Merge branch 'maint'Libravatar Junio C Hamano1-5/+5
* maint: Use git-for-each-ref to check whether the origin branch exists.
2007-05-23Fix the progress code to output LF only when it is really neededLibravatar Alex Riesen2-1/+6
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-23Use git-for-each-ref to check whether the origin branch exists.Libravatar Stephan Springl1-5/+5
This works in repositories that have their refs packed by "git-pack-refs --all --prune" whereas testing the file $git_dir/refs/heads/$opt_o does not. Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-23Fix command line parameter parser of revert/cherry-pickLibravatar Junio C Hamano1-2/+5
The parser was inconsistently done, in that it did not look at the last command line parameter to see if it could be an unknown option, although it was designed to notice unknown options if they were given in positions the command expects to find them (i.e. everything except the last parameter, which ought to be <commit-ish>). This prevented a very natural invocation $ git cherry-pick --usage from issuing the usage help. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-23Merge branch 'jn/lstree'Libravatar Junio C Hamano2-6/+41
* jn/lstree: Add an option to git-ls-tree to display also the size of blob
2007-05-23Merge branch 'maint'Libravatar Junio C Hamano1-0/+7
* maint: Document branch.autosetupmerge.
2007-05-23Merge branch 'maint-1.5.1' into maintLibravatar Junio C Hamano1-0/+7
* maint-1.5.1: Document branch.autosetupmerge.
2007-05-22Document branch.autosetupmerge.Libravatar Paolo Bonzini1-0/+7
This patch documents the branch.autosetupmerge config option, added by commit 0746d19a. Signed-off-by: Paolo Bonzini <bonzini@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-22t9400: Add some basic pserver testsLibravatar Frank Lichtenheld1-0/+34
While we can easily test the cvs <-> git-cvsserver communication with :fork: and git-cvsserver server there are some pserver specifics we should test, too. Currently this are two tests of the pserver authentication. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-22t9400: Add some more cvs update testsLibravatar Frank Lichtenheld1-0/+69
Add some cvs update tests that include various merge situations. Also add a basic test for update -C since it fits so well in there. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-22t9400: Add test cases for config file handlingLibravatar Frank Lichtenheld1-0/+69
Add a few test cases for the config file parsing done by git-cvsserver. Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-21Merge branch 'mc/ws'Libravatar Junio C Hamano1-6/+25
* mc/ws: git-apply: Fix removal of new trailing blank lines. Teach 'git-apply --whitespace=strip' to remove empty lines at the end of file
2007-05-21Teach git-describe how to run name-revLibravatar Shawn O. Pearce4-7/+44
Often users want to know not which tagged version a commit came after, but which tagged version a commit is contained within. This latter task is the job of git-name-rev, but most users are looking to git-describe to do the job. Junio suggested we make `git describe --contains` run the correct tool, `git name-rev`, and that's exactly what we do here. The output of name-rev was adjusted slightly through the new --name-only option, allowing describe to execv into name-rev and maintain its current output format. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-21rename dirlink to gitlink.Libravatar Martin Waitz14-27/+27
Unify naming of plumbing dirlink/gitlink concept: git ls-files -z '*.[ch]' | xargs -0 perl -pi -e 's/dirlink/gitlink/g;' -e 's/DIRLNK/GITLINK/g;' Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-21Merge branch 'maint'Libravatar Junio C Hamano7-7/+57
* maint: git-cvsserver: fix disabling service via per-method config git-status: respect core.excludesFile SubmittingPatches: mention older C compiler compatibility git-daemon: don't ignore pid-file write failure
2007-05-21git-cvsserver: fix disabling service via per-method configLibravatar Junio C Hamano1-5/+3
When the per-method enable logic disables the access, we should not even look at the global one. git-cvsserver.perl | 8 +++----- 1 files changed, 3 insertions(+), 5 deletions(-) Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-21Merge branch 'maint-1.5.1' into maintLibravatar Junio C Hamano6-2/+54
* maint-1.5.1: git-status: respect core.excludesFile SubmittingPatches: mention older C compiler compatibility git-daemon: don't ignore pid-file write failure
2007-05-21git-status: respect core.excludesFileLibravatar Johannes Schindelin4-0/+39
git-add reads this variable, and honours the contents of that file if that exists. Match this behaviour in git-status, too. Noticed by Evan Carroll on IRC. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-21SubmittingPatches: mention older C compiler compatibilityLibravatar Johannes Schindelin1-0/+13
We do not appreciate C99 initializers, declarations after statements, or "0" instead of "NULL". Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-21git-daemon: don't ignore pid-file write failureLibravatar Jim Meyering1-2/+2
Note: since the consequence of failure is to call die, I don't bother to close "f". Signed-off-by: Jim Meyering <jim@meyering.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-20git-apply: Fix removal of new trailing blank lines.Libravatar Junio C Hamano1-33/+15
The earlier code removed one newline too many from the hunk that adds new lines at the end of the file. Also the way the code counted the added blank lines was somewhat roundabout; I think the way updated code does it is more direct and easier to follow: * We keep track of the number of blank lines added; * While processing each line, we notice if it adds a blank line, and increment the counter, or reset it to zero otherwise; * When actually we apply the data, we remove the empty lines we counted earlier if we are applying it at the end of the file. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-21Update bash completion to ignore some more plumbing commandsLibravatar Jonas Fonseca1-0/+3
[sp: Modified Jonas' original patch to keep checkout-index as a a valid completion.] Signed-off-by: Jonas Fonseca <fonseca@diku.dk> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-20Add an option to git-ls-tree to display also the size of blobLibravatar Jakub Narebski2-6/+41
Add -l/--long option to git-ls-tree command, which displays object size of a blob entry. Object size is placed after object id (left-justified with minimum width of 7 characters). For non-blob entries `-' is used. Rationale: for non-blob entries size of an object has no much meaning, and is not very interesting. Moreover, in planned pack v4 tree objects would be constructed on demand, so tree size would need to be calculated. Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-20Teach 'git-apply --whitespace=strip' to remove empty lines at the end of fileLibravatar Marco Costalba1-3/+40
[jc: with an obvious microfix to avoid doing this unless --whitespace=strip] Signed-off-by: Marco Costalba <mcostalba@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-20git-rev-list: Add regexp tuning optionsLibravatar Petr Baudis2-0/+22
This patch introduces --extended-regexp and --regexp-ignore-case options to tune what kind of patterns the pattern-limiting options (--grep, --author, ...) accept. Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>