Commit Graph

196 Commits

Author SHA1 Message Date
Junio C Hamano
1e040c0b05 Merge branch 'ag/rewrite_one' into maint
* ag/rewrite_one:
  Fix quadratic performance in rewrite_one.
2008-08-07 11:40:12 -07:00
Dmitry Potapov
fd55a19eb1 Fix buffer overflow in git diff
If PATH_MAX on your system is smaller than a path stored, it may cause
buffer overflow and stack corruption in diff_addremove() and diff_change()
functions when running git-diff

Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-16 14:03:24 -07:00
Alexander N. Gavrilov
fce87ae538 Fix quadratic performance in rewrite_one.
Parent commits are usually older than their children. Thus,
on each iteration of the loop in rewrite_one, add_parents_to_list
traverses all commits previously processed by the loop.
It performs very poorly in case of very long rewrite chains.

Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13 13:46:56 -07:00
Junio C Hamano
48ded91674 log --pretty: do not accept bogus "--prettyshort"
... nor bogus "format.pretty = '=short'".  Both are syntax errors.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25 20:29:07 -07:00
Junio C Hamano
37869f40a8 log --graph: do not accept log --graphbogus
An obvious fix to the argument parser.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25 20:28:58 -07:00
Adam Simpkins
4603ec0f96 get_revision(): honor the topo_order flag for boundary commits
Now get_revision() sorts the boundary commits when topo_order is set.
Since sort_in_topological_order() takes a struct commit_list, it first
places the boundary commits into revs->commits.

Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25 12:22:24 -07:00
Adam Simpkins
3c68d67b57 Fix output of "git log --graph --boundary"
Previously the graphing API wasn't aware of the revs->boundary flag, and
it always assumed that commits marked UNINTERESTING would not be
displayed.  As a result, the boundary commits were printed at the end of
the log output, but they didn't have any branch lines connecting them to
their children in the graph.

There was also another bug in the get_revision() code that caused
graph_update() to be called twice on the first boundary commit.  This
caused the graph API to think that a commit had been skipped, and print
a "..." line in the output.

Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25 12:16:56 -07:00
Adam Simpkins
7528f27dd6 log --graph --left-right: show left/right information in place of '*'
With the --graph option, the graph already outputs 'o' instead of '*'
for boundary commits.  Make it emit '<' or '>' when --left-right is
specified.

(This change also disables the '^' prefix for UNINTERESTING commits.
The graph code currently doesn't print anything special for these
commits, since it assumes no UNINTERESTING, non-BOUNDARY commits are
displayed.  This is potentially a bug if UNINTERESTING non-BOUNDARY
commits can actually be displayed via some code path.)

[jc: squashed the left-right change from Dscho and Adam's fixup into one]

Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-25 12:06:52 -07:00
Junio C Hamano
f0abea652b Merge branch 'sv/first-parent'
* sv/first-parent:
  revision.c: really honor --first-parent
  Simplify and fix --first-parent implementation
2008-05-21 14:15:52 -07:00
Lars Hjemli
ad1012ebde revision.c: really honor --first-parent
In add_parents_to_list, if any parent of a revision had already been
SEEN, the current code would continue with the next parent, skipping
the test for --first-parent. This patch inverts the test for SEEN so
that the test for --first-parent is always performed.

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-12 16:24:51 -07:00
Adam Simpkins
7fefda5cc7 log and rev-list: add --graph option
This new option causes a text-based representation of the history to be
printed to the left of the normal output.

Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-05 18:46:35 -07:00
Adam Simpkins
885cf80899 revision API: split parent rewriting and parent printing options
This change allows parent rewriting to be performed without causing
the log and rev-list commands to print the parents.

Signed-off-by: Adam Simpkins <adam@adamsimpkins.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-05-05 17:38:22 -07:00
Stephen R. van den Berg
d9c292e8bb Simplify and fix --first-parent implementation
The purpose of --first-parent is to view the tree without looking at
side branche.  This is accomplished by pretending there are no other
parents than the first parent when encountering a merge.

The current code marks the other parents as seen, which means that the tree
traversal will behave differently depending on the order merges are handled.

When a fast forward is artificially recorded as a merge,

       -----
      /     \
 D---E---F---G master

the current first-parent code considers E to be seen and stops the
traversal after showing G and F.

Signed-off-by: Stephen R. van den Berg <srb@cuci.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-29 17:47:37 -07:00
Junio C Hamano
d52301630f Merge branch 'jc/terminator-separator'
* jc/terminator-separator:
  log: teach "terminator" vs "separator" mode to "--pretty=format"
2008-04-19 21:10:54 -07:00
Junio C Hamano
eed81838f0 Merge branch 'maint-1.5.4' into maint
* maint-1.5.4:
  bisect: fix bad rev checking in "git bisect good"
  revision.c: make --date-order overriddable
  Fix section about backdating tags in the git-tag docs
  Document option --only of git commit
  Documentation/git-request-pull: Fixed a typo ("send" -> "end")
2008-04-11 23:55:55 -07:00
Michele Ballabio
a710522bfc revision.c: make --date-order overriddable
Jan Engelhardt noticed that while --topo-order can be overridden by a
subsequent --date-order, the reverse was not possible. That's because
setup_revisions() failed to set revs->lifo properly.

Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-11 23:01:33 -07:00
Junio C Hamano
4da45bef56 log: teach "terminator" vs "separator" mode to "--pretty=format"
This attached patch introduces a single bit "use_terminator" in "struct
rev_info", which is normally false (i.e. most formats use separator
semantics) but by flipping it to true, you can ask for terminator
semantics just like oneline format does.

The function get_commit_format(), which is what parses "--pretty=" option,
now takes a pointer to "struct rev_info" and updates its commit_format and
use_terminator fields.  It used to return the value of type "enum
cmit_fmt", but all the callers assigned it to rev->commit_format.

There are only two cases the code turns use_terminator on.  Obviously, the
traditional oneline format (--pretty=oneline) is one of them, and the new
case is --pretty=tformat:... that acts like --pretty=format:... but flips
the bit on.

With this, "--pretty=tformat:%H %s" acts like --pretty=oneline.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-10 03:25:03 -07:00
Linus Torvalds
7d004199d1 Make revision limiting more robust against occasional bad commit dates
The revision limiter uses the commit date to decide when it has seen
enough commits to finalize the revision list, but that can get confused
if there are incorrect dates far in the past on some commits.

This makes the logic a bit more robust by

 - we always walk an extra SLOP commits from the source list even if we
   decide that the source list is probably all done (unless the source is
   entirely empty, of course, because then we really can't do anything at
   all)

 - we keep track of the date of the last commit we added to the
   destination list (this will *generally* be the oldest entry we've seen
   so far)

 - we compare that with the youngest entry (the first one) of the source
   list, and if the destination is older than the source, we know we want
   to look at the source.

which causes occasional date mishaps to be handled cleanly.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-03-19 01:42:35 -07:00
Junio C Hamano
d2c425aa2b Merge branch 'jc/maint-log-merge-left-right'
* jc/maint-log-merge-left-right:
  Fix "git log --merge --left-right"
2008-03-02 15:12:04 -08:00
Uwe Kleine-König
a5aa930d50 rev-list: add --branches, --tags and --remotes
These flags are already known to rev-parse and have the same meaning.

This patch allows to run gitk as follows:

	gitk --branches --not --remotes

to show only your local work.

Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-29 00:00:29 -08:00
Junio C Hamano
e82447b1df Fix "git log --merge --left-right"
The command did not reject the combination of these options, but
did not show left/right markers.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-27 15:42:05 -08:00
Junio C Hamano
860cc3a4f9 Merge branch 'jc/diff-relative'
* jc/diff-relative:
  diff --relative: help working in a bare repository
  diff --relative: output paths as relative to the current subdirectory
2008-02-27 11:55:28 -08:00
Jakub Narebski
dc1c0fffd3 Add '--fixed-strings' option to "git log --grep" and friends
Add support for -F | --fixed-strings option to "git log --grep"
and friends: "git log --author", "git log --committer=<pattern>".
Code is based on implementation of this option in "git grep".

Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-26 23:59:49 -08:00
Junio C Hamano
428ae2eff0 Merge branch 'lt/revision-walker'
* lt/revision-walker:
  Add "--show-all" revision walker flag for debugging
2008-02-20 16:13:24 -08:00
Martin Koegler
9684afd967 revision.c: handle tag->tagged == NULL
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-18 19:25:26 -08:00
Martin Koegler
c1ee9013ad mark_blob/tree_uninteresting: check for NULL
As these functions are directly called with the result
from lookup_tree/blob, they must handle NULL.

Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-18 19:20:20 -08:00
Linus Torvalds
3131b71301 Add "--show-all" revision walker flag for debugging
It's really not very easy to visualize the commit walker, because - on
purpose - it obvously doesn't show the uninteresting commits!

This adds a "--show-all" flag to the revision walker, which will make
it show uninteresting commits too, and they'll have a '^' in front of
them (it also fixes a logic error for !verbose_header for boundary
commits - we should show the '-' even if left_right isn't shown).

A separate patch to gitk to teach it the new '^' was sent
to paulus.  With the change in place, it actually is interesting
even for the cases that git doesn't have any problems with, ie
for the kernel you can do:

	gitk -d --show-all v2.6.24..

and you see just how far down it has to parse things to see it all. The
use of "-d" is a good idea, since the date-ordered toposort is much better
at showing why it goes deep down (ie the date of some of those commits
after 2.6.24 is much older, because they were merged from trees that
weren't rebased).

So I think this is a useful feature even for non-debugging - just to
visualize what git does internally more.

When it actually breaks out due to the "everybody_uninteresting()"
case, it adds the uninteresting commits (both the one it's looking at
now, and the list of pending ones) to the list

This way, we really list *all* the commits we've looked at.

Because we now end up listing commits we may not even have been parsed
at all "show_log" and "show_commit" need to protect against commits
that don't have a commit buffer entry.

That second part is debatable just how it should work. Maybe we shouldn't
show such entries at all (with this patch those entries do get shown, they
just don't get any message shown with them). But I think this is a useful
case.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 15:59:26 -08:00
Junio C Hamano
c0cb4a0679 diff --relative: help working in a bare repository
This allows the --relative option to say which subdirectory to
pretend to be in, so that in a bare repository, you can say:

    $ git log --relative=drivers/ v2.6.20..v2.6.22 -- drivers/scsi/

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 14:59:34 -08:00
Junio C Hamano
cd676a5136 diff --relative: output paths as relative to the current subdirectory
This adds --relative option to the diff family.  When you start
from a subdirectory:

        $ git diff --relative

shows only the diff that is inside your current subdirectory,
and without $prefix part.  People who usually live in
subdirectories may like it.

There are a few things I should also mention about the change:

 - This works not just with diff but also works with the log
   family of commands, but the history pruning is not affected.

   In other words, if you go to a subdirectory, you can say:

        $ git log --relative -p

   but it will show the log message even for commits that do not
   touch the current directory.  You can limit it by giving
   pathspec yourself:

        $ git log --relative -p .

   This originally was not a conscious design choice, but we
   have a way to affect diff pathspec and pruning pathspec
   independently.  IOW "git log --full-diff -p ." tells it to
   prune history to commits that affect the current subdirectory
   but show the changes with full context.  I think it makes
   more sense to leave pruning independent from --relative than
   the obvious alternative of always pruning with the current
   subdirectory, which would break the symmetry.

 - Because this works also with the log family, you could
   format-patch a single change, limiting the effect to your
   subdirectory, like so:

        $ cd gitk-git
        $ git format-patch -1 --relative 911f1eb

   But because that is a special purpose usage, this option will
   never become the default, with or without repository or user
   preference configuration.  The risk of producing a partial
   patch and sending it out by mistake is too great if we did
   so.

 - This is inherently incompatible with --no-index, which is a
   bolted-on hack that does not have much to do with git
   itself.  I didn't bother checking and erroring out on the
   combined use of the options, but probably I should.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-13 14:58:07 -08:00
Arjen Laarhoven
0faf2da7e5 Fix "git log --diff-filter" bug
In commit b7bb760d5e (Fix revision
log diff setup, avoid unnecessary diff generation) an optimization was
made to avoid unnecessary diff generation.  This was partly fixed in
99516e35d0 (Fix embarrassing "git log
--follow" bug).  The '--diff-filter' option also needs the diff machinery
in action.

Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-26 11:57:36 -08:00
Junio C Hamano
3384a2dfc1 shortlog: default to HEAD when the standard input is a tty
Instead of warning the user that it is expecting git log output from
the standard input (and waiting for the user to type the log from
the keyboard, which is a silly thing to do), default to traverse from
HEAD when there is no rev parameter given and the standard input is
a tty.

This factors out a useful helper "add_head()" from builtin-diff.c to a
more appropriate place revision.c while renaming it to more descriptive
name add_head_to_pending(), as that is what the function is about.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-11 17:01:31 -08:00
Junio C Hamano
5d3d1cacc1 Merge branch 'lt/rev-list-gitlink'
* lt/rev-list-gitlink:
  Fix rev-list when showing objects involving submodules
2007-11-18 16:16:37 -08:00
Junio C Hamano
761e8566cb Merge branch 'lt/rev-list-interactive'
* lt/rev-list-interactive:
  Fix parent rewriting in --early-output
  revision walker: mini clean-up
  Enhance --early-output format
  Add "--early-output" log flag for interactive GUI use
  Simplify topo-sort logic
2007-11-18 16:03:24 -08:00
Linus Torvalds
7dc0fe3be5 Fix parent rewriting in --early-output
We cannot tell a node that has been checked and found not to be
interesting (which does not have the TREECHANGE flag) from a
node that hasn't been checked if it is interesting or not,
without relying on something else, such as object->parsed.

But an object can get the "parsed" flag for other reasons.
Which means that "TREECHANGE" has the wrong polarity.

This changes the way how the path pruning logic marks an
uninteresting commits.  From now on, we consider a commit
interesting by default, and explicitly mark the ones we decided
to prune.  The flag is renamed to "TREESAME".

Then, this fixes the logic to show the early output with
incomplete pruning.  It basically says "a commit that has
TREESAME set is kind-of-UNINTERESTING", but obviously in a
different way than an outright UNINTERESTING commit.  Until we
parse and examine enough parents to determine if a commit
becomes surely "kind-of-UNINTERESTING", we avoid rewriting
the ancestry so that later rounds can fix things up.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-14 03:59:37 -08:00
Linus Torvalds
4d1012c370 Fix rev-list when showing objects involving submodules
The function mark_tree_uninteresting() assumed that the tree entries
are blob when they are not trees.  This is not so.  Since we do
not traverse into submodules (yet), the gitlinks should be ignored.

In general, we should try to start moving away from using the
"S_ISLNK()" like things for internal git state. It was a mistake to
just assume the numbers all were same across all systems in the first
place.  This implementation converts to the "object_type", and then
uses a case statement.

Noticed by Ilari on IRC.
Test script taken from an earlier version by Dscho.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-14 03:44:22 -08:00
Pierre Habouzit
8f67f8aefb Make the diff_options bitfields be an unsigned with explicit masks.
reverse_diff was a bit-value in disguise, it's merged in the flags now.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-11 16:54:15 -08:00
Linus Torvalds
53b2c823f6 revision walker: mini clean-up
This removes the unnecessary indirection of "revs->prune_fn",
since that function is always the same one (or NULL), and there
is in fact not even an abstraction reason to make it a function
(i.e. its not called from some other file and doesn't allow us
to keep the function itself static or anything like that).

It then just replaces it with a bit that says "prune or not",
and if not pruning, every commit gets TREECHANGE.

That in turn means that

 - if (!revs->prune_fn || (flags & TREECHANGE))
 - if (revs->prune_fn && !(flags & TREECHANGE))

just become

 - if (flags & TREECHANGE)
 - if (!(flags & TREECHANGE))

respectively.

Together with adding the "single_parent()" helper function, the "complex"
conditional now becomes

	if (!(flags & TREECHANGE) && rev->dense && single_parent(commit))
		continue;

Also indirection of "revs->dense" checking is thrown away the
same way, because TREECHANGE bit is set appropriately now.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 18:19:28 -08:00
Linus Torvalds
252a7c0235 Enhance --early-output format
This makes --early-output a bit more advanced, and actually makes it
generate multiple "Final output:" headers as it updates things
asynchronously. I realize that the "Final output:" line is now illogical,
since it's not really final until it also says "done", but

It now _always_ generates a "Final output:" header in front of any commit
list, and that output header gives you a *guess* at the maximum number of
commits available. However, it should be noted that the guess can be
completely off: I do a reasonable job estimating it, but it is not meant
to be exact.

So what happens is that you may get output like this:

 - at 0.1 seconds:

	Final output: 2 incomplete
	.. 2 commits listed ..

 - half a second later:

	Final output: 33 incomplete
	.. 33 commits listed ..

 - another half a second after that:

	Final output: 71 incomplete
	.. 71 commits listed ..

 - another half second later:

	Final output: 136 incomplete
	.. 100 commits listed: we hit the --early-output limit, and
	.. will only output 100 commits, and after this you'll not
	.. see an "incomplete" report any more since you got as much
	.. early output as you asked for!

 - .. and then finally:

	Final output: 73106 done
	.. all the commits ..

The above is a real-life scenario on my current kernel tree after having
flushed all the caches.

Tested with the experimental gitk patch that Paul sent out, and by looking
at the actual log output (and verifying that my commit count guesses
actually match real life fairly well).

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-05 14:28:53 -08:00
Linus Torvalds
cdcefbc971 Add "--early-output" log flag for interactive GUI use
This adds support for "--early-output[=n]" as a flag to the "git log"
family of commands.  This allows GUI programs to state that they want to
get some output early, in order to be able to show at least something
quickly, even if the full output may take longer to generate.

If no count is specified, a default count of a hundred commits will be
used, although the actual numbr of commits output may be smaller
depending on how many commits were actually found in the first tenth of
a second (or if *everything* was found before that, in which case no
early output will be provided, and only the final list is made
available).

When the full list is generated, there will be a "Final output:" string
prepended to it, regardless of whether any early commits were shown or
not, so that the consumer can always know the difference between early
output and the final list.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-11-04 01:54:20 -07:00
Linus Torvalds
23c17d4a4a Simplify topo-sort logic
.. by not using quite so much indirection.

This currently grows the "struct commit" a bit, which could be avoided by
using a union for "util" and "indegree" (the topo-sort used to use "util"
anyway, so you cannot use them together), but for now the goal of this was
to simplify, not optimize.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2007-11-04 01:54:20 -07:00
Shawn O. Pearce
d55e7c3acf Merge branch 'maint'
* maint:
  Whip post 1.5.3.4 maintenance series into shape.
  rebase -i: use diff plumbing instead of porcelain
  Do not remove distributed configure script
  git-archive: document --exec
  git-reflog: document --verbose
  git-config: handle --file option with relative pathname properly
  clear_commit_marks(): avoid deep recursion
  git add -i: Remove unused variables
  git add -i: Fix parsing of abbreviated hunk headers
  git-config: don't silently ignore options after --list
  Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT
  Fix embarrassing "git log --follow" bug

Conflicts:

	RelNotes
	git-rebase--interactive.sh
2007-10-15 22:31:47 -04:00
Linus Torvalds
99516e35d0 Fix embarrassing "git log --follow" bug
It turns out that I completely broke "git log --follow" with my recent
patch to revision.c ("Fix revision log diff setup, avoid unnecessary diff
generation", commit b7bb760d5e).

Why? Because --follow obviously requires the diff machinery to function,
exactly the same way pickaxe does.

So everybody is away right now, but considering that nobody even noticed
this bug, I don't think it matters. But for the record, here's the trivial
one-liner fix (well, two, since I also fixed the comment).

Because of the nature of the bug, if you ask for patches when following
(which is one of the things I normally do), the bug is hidden, because
then the request for diff output will automatically also enable the diffs
themselves.

So while "git log --follow <filename>" didn't work, adding a "-p"
magically made it work again even without this fix.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-10-15 20:15:58 -04:00
Andy Parkins
856665f827 parse_date_format(): convert a format name to an enum date_mode
Factor out the code to parse --date=<format> parameter to revision
walkers into a separate function, parse_date_format().  This function
is passed a string and converts it to an enum date_format:

 - "relative"         => DATE_RELATIVE
 - "iso8601" or "iso" => DATE_ISO8601
 - "rfc2822"          => DATE_RFC2822
 - "short"            => DATE_SHORT
 - "local"            => DATE_LOCAL
 - "default"          => DATE_NORMAL

In the event that none of these strings is found, the function die()s.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-29 20:31:59 -07:00
Linus Torvalds
b7bb760d5e Fix revision log diff setup, avoid unnecessary diff generation
We used to incorrectly start calculating diffs whenever any argument but
'-z' was recognized by the diff options parsing. That was bogus, since not
all arguments result in diffs being needed, so we just waste a lot of time
and effort on calculating diffs that don't matter.

This actually also fixes another bug in "git log". Try this:

	git log -C

and notice how it prints an extra empty line in between log entries, even
though it never prints the actual diff (because we didn't ask for any diff
format, so the diff machinery never prints anything).

With this patch, that bogus empty line is gone, because "revs->diff" is
never set.  So this isn't just a "wasted time and effort" issue, it's also
a slight semantic fix.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-29 15:42:32 -07:00
Johannes Schindelin
023756f4eb revision walker: --cherry-pick is a limited operation
We used to rely on the fact that cherry-pick would trigger the code path
to set limited = 1 in handle_commit(), when an uninteresting commit was
encountered.

However, when cherry picking between two independent branches, i.e. when
there are no merge bases, and there is only linear development (which can
happen when you cvsimport a fork of a project), no uninteresting commit
will be encountered.

So set limited = 1 when --cherry-pick was asked for.

Noticed by Martin Bähr.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-09-15 16:34:11 -07:00
Junio C Hamano
a65f2005a6 Make "git-log --" without paths behave the same as "git-log" without --
"git log" family of commands, even when run from a subdirectory,
do not limit the revision range with the current directory as
the path limiter, but with double-dash without any paths after
it, i.e. "git log --" do so.  It was a mistake to have a
difference between "git log --" and "git log" introduced in
commit ae563542bf (First cut at
libifying revlist generation).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-31 00:26:41 -07:00
Shawn O. Pearce
d56651c0ef Don't allow combination of -g and --reverse as it doesn't work
The --walk-reflogs logic and the --reverse logic are completely
incompatible with one another.  Attempting to use both at the same
time leads to confusing results that sometimes violates the user's
formatting options or ignores the user's request to see the reflog
message and timestamp.

Unfortunately the implementation of both of these features is glued
onto the side of the revision walking machinary in such a way that
they are probably not going to be easy to make them compatible with
each other.  Rather than offering the user confusing results we are
better off bailing out with an error message until such a time as
the implementations can be refactored to be compatible.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-19 22:52:06 -07:00
Marco Costalba
9fa3465d6b Add --log-size to git log to print message size
With this option git-log prints log message size
just before the corresponding message.

Porcelain tools could use this to speedup parsing
of git-log output.

Note that size refers to log message only. If also
patch content is shown its size is not included.

In case it is not possible to know the size upfront
size value is set to zero.

Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-14 01:59:33 -07:00
Johannes Schindelin
7b69b873fa git log -g: Complain, but do not fail, when no reflogs are there
When asking "git log -g --all", clearly you want to see only those refs
that do have reflogs, but you do not want it to fail, either.

So instead of die()ing, complain about it, but move on to the other refs.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-24 17:28:10 -07:00
Johannes Schindelin
8e64006eee Teach revision machinery about --no-walk
The flag "no_walk" is present in struct rev_info since a long time, but
so far has been in use exclusively by "git show".

With this flag, you can see all your refs, ordered by date of the last
commit:

$ git log --abbrev-commit --pretty=oneline --decorate --all --no-walk

which is extremely helpful if you have to juggle with a lot topic
branches, and do not remember in which one you introduced that uber
debug option, or simply want to get an overview what is cooking.

(Note that the "git log" invocation above does not output the same as

 $ git show --abbrev-commit --pretty=oneline --decorate --all --quiet

 since "git show" keeps the alphabetic order that "--all" returns the
 refs in, even if the option "--date-order" was passed.)

For good measure, this also adds the "--do-walk" option which overrides
"--no-walk".

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-23 23:57:50 -07:00