The boundary commits are shown for UI like gitk to draw them as
soon as topo-order sorting allows, and should not be omitted by
get_revision() filtering logic. As long as their immediate
child commits are shown, we should not filter them out.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This bug was reported by Yann Dirson, and results in an 'Error:
expected boolean value but got ""' dialog when scrolling to the bottom
of the graph under some circumstances. The issue is that git-rev-list
isn't outputting all the boundary commits when it is asked for commits
affecting only certain files. We already cope with that by adding the
missing boundary commits in addextraid, but there we weren't adding a
0 to the end of the commitlisted list when we added the extra id to
the end of the displayorder list.
This fixes it by appending 0 to commitlisted in addextraid, thus keeping
commitlisted and displayorder in sync.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This skips an extra pipe, and helps debugging tremendously.
[jc: PAGER=cat is a questionable hack and should be done as a separate
patch. ]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this option, git prepends a diffstat in front of the patch.
Since I really, really do not know what a diffstat of a combined diff
("merge diff") should look like, the diffstat is not generated for these.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The "--help" argument is special, in that it is (along with "--version")
in that is taken by the "git" program itself rather than the sub-command,
and thus we've had the syntax "git --help cmd".
However, as anybody who has ever used CVS or some similar devil-spawn
program, it's confusing as h*ll when options before the sub-command act
differently from options after the sub-command, so this quick hack just
makes it acceptable to do "git cmd --help" instead, and get the exact same
result.
It may be hacky, but it's simple and does the trick.
Of course, this does not help if you use one of the non-builtin commands
without using the "git" helper. Ie you won't be getting a man-page just
because you do "git-rev-list --help". Don't expect us to be quite _that_
helpful.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I missed that "git-diff-* --stat" spits out three-dash separator
on its own without being asked. Remove it.
When we output commit log followed by diff, perhaps --patch-with-stat,
for downstream consumer, we _would_ want the three-dash between
the message and the diff material, but that logic belongs to the
caller, not diff generator.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Recent diff_tree_setup_paths() update made it take a second
argument of type "struct diff_options", but we passed another
struct that happenes to have that type at the beginning by
mistake.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I've merged everything I think is ready for 1.3.0, so this is
the final round -- hopefully I can release this with minimum
last-minute fixup as v1.3.0 early next week.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Partly because we've messed up and now have some commits with trailing
whitespace, but partly because this also just simplifies the code, let's
remove trailing whitespace from the end when pretty-printing commits.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Noticed by Johannes. We do not install it anymore, but still have
been shipping the source, which was crazy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes f4ee3eb689 breakage, which
added an extra trailing blank line after stripping trailing blank lines
by mistake.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Relying on eye-candy progress bar was fragile to begin with.
Run fetch-pack with -k option, and count the objects that are in
the pack that were transferred from the other end.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The regexp on the right hand side of expr : operator somehow was
broken.
expr 'z+pu:refs/tags/ko-pu' : 'z\+\(.*\)'
does not strip '+'; write 'z+\(.*\)' instead.
We probably should switch to shell based substring post 1.3.0;
that's not bashism but just POSIX anyway.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now, you can say "git diff --stat" (to get an idea how many changes are
uncommitted), or "git log --stat".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some words, e.g., `match', are special to expr(1), and cause strange
parsing effects. Track down all uses of expr and mangle the arguments
so that this isn't a problem.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When running t3600-rm test under fakeroot (or as root), we
cannot make a file unremovable with "chmod a-w .". Detect this
case early and skip that test.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This trivially avoids keeping the commit message data around after we
don't need it any more, avoiding a continually growing "git log" memory
footprint.
It's not a huge deal, but it's somewhat noticeable. For the current kernel
tree, doing a full "git log" I got
- before: /usr/bin/time git log > /dev/null
0.81user 0.02system 0:00.84elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+8851minor)pagefaults 0swaps
- after: /usr/bin/time git log > /dev/null
0.79user 0.03system 0:00.83elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+5039minor)pagefaults 0swaps
ie the touched pages dropped from 8851 to 5039. For the historic kernel
archive, the numbers are 18357->11037 minor page faults.
We could/should in theory free the commits themselves, but that's really a
lot harder, since during revision traversal we may hit the same commit
twice through different children having it as a parent, even after we've
shown it once (when that happens, we'll silently ignore it next time, but
we still need the "struct commit" to know).
And as the commit message data is clearly the biggest part of the commit,
this is the really easy 60% solution.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This target lists undocumented commands, and/or whose document
is not referenced from the main git documentation.
For now, there are some exceptions I added primarily because I
lack the energy to document them myself:
- merge backends (we should really document them)
- ssh-push/ssh-pull (does anybody still use them?)
- annotate and blame (maybe after one of them eats the other ;-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/combine:
stripspace: make sure not to leave an incomplete line.
git-commit: do not muck with commit message when no_edit is set.
When showing a commit message, do not lose an incomplete line.
Retire t5501-old-fetch-and-upload test.
combine-diff: type fix.
* master:
stripspace: make sure not to leave an incomplete line.
git-commit: do not muck with commit message when no_edit is set.
When showing a commit message, do not lose an incomplete line.
Retire t5501-old-fetch-and-upload test.
The variable hunk_end points at a line number, which is
represented as unsigned long by all the other variables.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When dealing with a commit log message for human consumption, it
never makes sense to keep a log that ends with an incomplete
line, so make it a part of the clean-up process done by
git-stripspace.
Acked-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Spotted by Linus and Darrin Thompson. When we took a commit
message from -F <file> with an incomplete line, we appended "git
status" output, which ended up attaching a lone "#" at the end.
We still need the "do we have anything to commit?" check by
running "status" (which has to know what to do in different
cases with -i/-o/-a), but there is no point appending its output
to the proposed commit message given by the user.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The previous round showed the delete-only hunks at the end, but
forgot to mark them interesting when they were.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to lose hunks that appear at the end and have only
deletion. This makes sure that the record beyond the end of
file (which holds such deletions) is examined.
Signed-off-by: Junio C Hamano <junkio@cox.net>
More friendly for human reading I believe, and possibly friendlier to some
parsers (although only by an epsilon).
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
