summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2006-02-02Provide a more meaningful initial "From " line when using --compose in ↵Libravatar Ryan Anderson1-1/+1
git-send-email. git-send-email, when used with --compose, provided the user with a mbox-format file to edit. Some users, however, were confused by the leading, blank, "From " line, so this change puts the value that will appear on the From: line of the actual email on this line, along with a note that the line is ignored. Signed-off-by: Ryan Anderson <ryan@michonline.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-02commit.c: "Merge" fix in pretty_print_commit.Libravatar Junio C Hamano1-5/+5
Earlier, f2d4227530499db3e273ae84f30adfd4b70791c6 commit broke Merge: lines for unabbreviated case. Do not emit extra dots if we do not abbreviate. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-02merge-recursive: Speed up commit graph constructionLibravatar Fredrik Kuivinen1-1/+4
Use __slots__ to speed up construction and decrease memory consumption of the Commit objects. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-02merge-recursive: Make use of provided basesLibravatar Fredrik Kuivinen1-10/+21
This makes some cases faster as we don't have to build the commit graph. Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-02Documentation: git-diff-tree --cc also omits empty commitsLibravatar Junio C Hamano1-1/+1
A misguided attempt to show logs at all time was inserted only to the documentation of this flag. Worse yet, it was not even implemented, causing more confusion. Drop it. We might want to have an option to show --pretty even when there is no diff output, but that is applicable to all forms of diff, not just --cc. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-02combine-diff: fix placement of deletion.Libravatar Junio C Hamano1-1/+13
The code misplaced a raw hunk that consists of solely deleted lines by one line. This showed e.g. Len's 12-way octopus (9fdb62af in the linux-2.6), kernel/power/disk.c, hunk starting at line 95, incorrectly. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-02combine-diff: add safety check to --cc.Libravatar Junio C Hamano1-2/+18
The earlier change implemented "only two version" check but without checking if the change rewrites from all the parents. This implements a check to make sure that a change introduced by the merge from all the parents is caught to be interesting. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-02combine-diff: update --cc "uninteresting hunks" logic.Libravatar Junio C Hamano1-69/+33
Earlier logic was discarding hunks that has difference from only one parent or the same difference from all but one parent. This changes it to check if the differences on all lines are from the same sets of parents. This discards more uninteresting hunks and seems to match expectations more naturally. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-02combine-diff: reuse diff from the same blob.Libravatar Junio C Hamano1-2/+37
When dealing with an insanely large Octopus, it is possible to optimize by noticing that more than one parents have the same blob and avoid running diff between a parent and the merge result by reusing an earlier result. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-01Allow diff and index commands to be interruptedLibravatar Petr Baudis2-0/+4
So far, e.g. git-update-index --refresh was basically uninterruptable by ctrl-c, since it hooked the SIGINT handler, but that handler would only unlink the lockfile but not actually quit. This makes it propagate the signal to the default handler. Note that I expected it to work without resetting the signal handler to SIG_DFL, but without that it ended in an infinite loop of tgkill()s - is my glibc violating SUS or what? Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-01rev-list: omit duplicated parents.Libravatar Junio C Hamano1-1/+14
Showing the same parent more than once for a commit does not make much sense downstream, so stop it. This can happen with an incorrectly made merge commit that merges the same parent twice, but can happen in an otherwise sane development history while squishing the history by taking into account only commits that touch specified paths. For example, $ git rev-list --max-count=1 --parents addafaf -- rev-list.c would have to show this commit ancestry graph: .---o---. / \ .---*---o---. / 93b74bc \ ---*---o---o-----o---o-----o addafaf d8f6b34 \ / .---o---o---. \ / .---*---. 3815f42 where 5 independent development tracks, only two of which have changes in the specified paths since they forked. The last change for the other three development tracks was done by the same commit before they forked, and we were showing that three times. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-01update-index --index-info: allow stage 0 entries.Libravatar Junio C Hamano1-1/+1
Somehow we did not allow stuffing the index with stage 0 entries through --index-info interface. I do not think of a reason to forbid it offhand. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-01git-svnimport.perl: fix for 'arg list too long...'Libravatar Sasha Khapyorsky1-9/+16
This fixes 'arg list too long..' problem with git-ls-files. Note that second arg list separation loop (with 'git-update-index') is needed since git-ls-files arguments can be directories. Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-31Use local structs for HTTP slot callback dataLibravatar Nick Hengeveld1-5/+5
There's no need for these structures to be static, and it could potentially cause problems down the road. Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-31rev-list: allow -<n> as shorthand for --max-count=<n>Libravatar Eric Wong2-0/+9
This builds on top of the previous one. Traditionally, head(1) and tail(1) allow their line limits to be parsed this way. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-31rev-list: allow -n<n> as shorthand for --max-count=<n>Libravatar Eric Wong2-0/+25
Both -n<n> and -n <n> are supported. POSIX versions of head(1) and tail(1) allow their line limits to be parsed this way. I find --max-count to be a commonly used option, and also similar in spirit to head/tail, so I decided to make life easier on my worn out (and lazy :) fingers with this patch. Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-31Make apply accept the -pNUM option like patch does.Libravatar Daniel Barkalow2-3/+11
This only applies to traditional diffs, not to git diffs. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-31Fix HTTP request result processing after slot reuseLibravatar Nick Hengeveld3-7/+29
Add a way to store the results of an HTTP request when a slot finishes so the results can be processed after the slot has been reused. Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-31Make git-tar-tree use the tree_desc abstractionsLibravatar Linus Torvalds1-23/+24
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-31Make the "struct tree_desc" operations available to othersLibravatar Linus Torvalds2-6/+9
We have operations to "extract" and "update" a "struct tree_desc", but we only used them in tree-diff.c and they were static to that file. But other tree traversal functions can use them to their advantage Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-30Merge branches 'bf/doc' and 'db/tartree'Libravatar Junio C Hamano3-284/+193
2006-01-30documentation: cvs migration - typofix.Libravatar Junio C Hamano1-1/+1
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-30Use struct commit in tar-treeLibravatar Daniel Barkalow1-35/+6
It was open-coding getting the commit date from a commit. Signed-off-by: Daniel Barkalow <barkalow@iabervon> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-30Use struct tree in tar-treeLibravatar Daniel Barkalow1-26/+24
It was using an open-coded tree parser; use a struct tree instead. Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-30cvs-migration documentation updateLibravatar J. Bruce Fields2-223/+163
Here's some changes to the cvs-migration.txt. As usual, in my attempt to make things clearer someone may have found I've made them less so, or I may have just gotten something wrong; so any review is welcomed. I can break up this sort of thing into smaller steps if preferred, the monolothic patch is just a bit simpler for me for this sort of thing. I moved the material describing shared repository management from core-tutorial.txt to cvs-migration.txt, where it seems more appropriate, and combined two sections to eliminate some redundancy. I also revised the earlier sections of cvs-migration.txt, mainly trying to make it more concise. I've left the last section of cvs-migration.txt (on CVS annotate alternatives) alone for now. Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-29cvsexportcommit: add some examples to the documentationLibravatar Martin Langhoff1-0/+21
Updated with Randall Schwartz's suggestion. Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-29exportcommit: replace backticks with safe_pipe_capture() or system() - ↵Libravatar Martin Langhoff1-20/+33
initial pass Replaced backticks with potentially troublesome unescaped input with safe_pipe_capture(). Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-29cvsimport: Add -S <skipfileregex> support and -v announces files retrievedLibravatar Martin Langhoff1-4/+15
A couple of things that seem to help importing broken CVS repos... -S '<slash-delimited-regex>' skips files with a matching path -v prints file name and version before fetching from cvs Signed-off-by: Martin Langhoff <martin@catalyst.net.nz> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-29Merge fixes up to GIT 1.1.6Libravatar Junio C Hamano5-15/+30
2006-01-29GIT 1.1.6Libravatar Junio C Hamano5-15/+30
2006-01-29git push -f documentationLibravatar J. Bruce Fields1-4/+4
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-29git-branch: Documentation fixesLibravatar Fredrik Kuivinen2-3/+6
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-29merge-recursive: Improve the error message printed when merge(1) isn't found.Libravatar Fredrik Kuivinen1-5/+10
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-29[PATCH] pre-commit sample hook: do not barf on the initial importLibravatar Junio C Hamano1-3/+10
The example hook barfs on the initial import. Ideally it should produce a diff from an empty tree, but for now let's stop at squelching the bogus error message. Often an initial import involves tons of badly formatted files from foreign SCM, so not complaining about them like this patch does might actually be a better idea than enforcing the "Perfect Patch" format on them. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28Documentation: diff -c/--ccLibravatar Junio C Hamano3-3/+73
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28diff-files -c/--cc: combine only when both ours and theirs exist.Libravatar Junio C Hamano1-2/+7
The previous round forgot to make sure there actually are two versions to compare against the working tree version. Otherwise using -c/--cc would not make much sense. Also plug a small memory leak. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28Merge lt/revlist,jc/diff,jc/revparse,jc/abbrevLibravatar Junio C Hamano15-107/+932
2006-01-28rev-parse: make "whatchanged -- git-fetch-script" work again.Libravatar Junio C Hamano1-1/+3
The latest update to avoid misspelled revs interfered when we were not interested in parsing non flags or arguments not meant for rev-list. This makes these two forms work again: git whatchanged -- git-fetch-script We could enable "!def" in the part this change touches to make the above work without '--', but then it would cause misspelled v2.6.14..v2.6.16 to be given to diff-tree and defeats the whole point of the previous fix. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28diff --abbrev=<n> option fix.Libravatar Junio C Hamano1-1/+6
Earier specifying an abbreviation shorter than minimum fell back to full 40 letters, which was nonsense. Make it to fall back to the minimum number (currently 4). Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28pretty_print_commit: honor grafts.Libravatar Junio C Hamano1-26/+26
When displaying Merge: lines, we used to take the real commit parents from the commit objects. Use the parsed parents from the commit object instead, so that we honor fake parent information from info/grafts. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28pretty_print_commit(): pass commit object instead of commit->buffer.Libravatar Junio C Hamano5-10/+10
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28Rename rev-parse --abbrev to --short.Libravatar Junio C Hamano1-2/+2
The usage of rev-parse to serve as a flag/option parser for git-whatchanged and other commands have serious limitation that the flags cannot be something that is supported by rev-parse itself, and it cannot worked around easily. Since this is rarely used "poor-man's describe", rename the option for now as an easier workaround. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28rev-parse --abbrev: do not try abbrev shorter than minimum.Libravatar Junio C Hamano1-2/+4
We do not allow abbreviation shorter than 4 letters in other parts of the system so do not attempt to generate such. Noticed by Uwe Zeisberger. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28diff-tree: abbreviate merge parent object names with --abbrev --pretty.Libravatar Junio C Hamano5-9/+18
When --abbrev is in effect, abbreviate the merge parent names in prettyprinted output. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28rev-parse: --abbrev option.Libravatar Junio C Hamano1-0/+14
The new option behaves just like --verify, but outputs an abbreviated object name that is unique within the repository. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28abbrev cleanup: use symbolic constantsLibravatar Junio C Hamano5-8/+7
The minimum length of abbreviated object name was hardcoded in different places to be 4, risking inconsistencies in the future. Also there were three different "default abbreviation precision". Use two C preprocessor symbols to clean up this mess. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28rev-list --remove-empty: add minimum help and doc entry.Libravatar Junio C Hamano2-0/+5
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28rev-list: stop when the file disappearsLibravatar Linus Torvalds1-58/+78
The one thing I've considered doing (I really should) is to add a "stop when you don't find the file" option to "git-rev-list". This patch does some of the work towards that: it removes the "parent" thing when the file disappears, so a "git annotate" could do do something like git-rev-list --remove-empty --parents HEAD -- "$filename" and it would get a good graph that stops when the filename disappears (it's not perfect though: it won't remove all the unintersting commits). It also simplifies the logic of finding tree differences a bit, at the cost of making it a tad less efficient. The old logic was two-phase: it would first simplify _only_ merges tree as it traversed the tree, and then simplify the linear parts of the remainder independently. That was pretty optimal from an efficiency standpoint because it avoids doing any comparisons that we can see are unnecessary, but it made it much harder to understand than it really needed to be. The new logic is a lot more straightforward, and compares the trees as it traverses the graph (ie everything is a single phase). That makes it much easier to stop graph traversal at any point where a file disappears. As an example, let's say that you have a git repository that has had a file called "A" some time in the past. That file gets renamed to B, and then gets renamed back again to A. The old "git-rev-list" would show two commits: the commit that renames B to A (because it changes A) _and_ as its parent the commit that renames A to B (because it changes A). With the new --remove-empty flag, git-rev-list will show just the commit that renames B to A as the "root" commit, and stop traversal there (because that's what you want for "annotate" - you want to stop there, and for every "root" commit you then separately see if it really is a new file, or if the paths history disappeared because it was renamed from some other file). With this patch, you should be able to basically do a "poor mans 'git annotate'" with a fairly simple loop: push("HEAD", "$filename") while (revision,filename = pop()) { for each i in $(git-rev-list --parents --remove-empty $revision -- "$filename") pseudo-parents($i) = git-rev-list parents for that line if (pseudo-parents($i) is non-empty) { show diff of $i against pseudo-parents continue } /* See if the _real_ parents of $i had a rename */ parent($i) = real-parent($i) if (find-rename in $parent($i)->$i) push $parent($i), "old-name" } which should be doable in perl or something (doing stacks in shell is just too painful to be worth it, so I'm not going to do this). Anybody want to try? Linus
2006-01-28diff-files: -c and --cc options.Libravatar Junio C Hamano3-23/+99
This ports the "combined diff" to diff-files so that differences to the working tree files since stage 2 and stage 3 are shown the same way as combined diff output from diff-tree for the merge commit would be shown if the current working tree files are committed. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-01-28combine-diff: better hunk splitting.Libravatar Junio C Hamano1-27/+116
It considered an otherwise unchanged line that had line removals in front of it an interesting line, which caused hunks to have one extra the trailing context line. Signed-off-by: Junio C Hamano <junkio@cox.net>