Граф коммитов

207 Коммитов

Автор SHA1 Сообщение Дата
Brandon Casey d0f19d0471 revision.c: use proper data type in call to sizeof() within xrealloc
A type char** was being used instead of char*.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-14 21:41:19 -08:00
Junio C Hamano a4d7d2c6db log --author/--committer: really match only with name part
When we tried to find commits done by AUTHOR, the first implementation
tried to pattern match a line with "^author .*AUTHOR", which later was
enhanced to strip leading caret and look for "^author AUTHOR" when the
search pattern was anchored at the left end (i.e. --author="^AUTHOR").

This had a few problems:

 * When looking for fixed strings (e.g. "git log -F --author=x --grep=y"),
   the regexp internally used "^author .*x" would never match anything;

 * To match at the end (e.g. "git log --author='google.com>$'"), the
   generated regexp has to also match the trailing timestamp part the
   commit header lines have.  Also, in order to determine if the '$' at
   the end means "match at the end of the line" or just a literal dollar
   sign (probably backslash-quoted), we would need to parse the regexp
   ourselves.

An earlier alternative tried to make sure that a line matches "^author "
(to limit by field name) and the user supplied pattern at the same time.
While it solved the -F problem by introducing a special override for
matching the "^author ", it did not solve the trailing timestamp nor tail
match problem.  It also would have matched every commit if --author=author
was asked for, not because the author's email part had this string, but
because every commit header line that talks about the author begins with
that field name, regardleses of who wrote it.

Instead of piling more hacks on top of hacks, this rethinks the grep
machinery that is used to look for strings in the commit header, and makes
sure that (1) field name matches literally at the beginning of the line,
followed by a SP, and (2) the user supplied pattern is matched against the
remainder of the line, excluding the trailing timestamp data.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-09-04 22:21:56 -07:00
Jeff King 0843acfd2c Fix "git log -i --grep"
This has been broken in v1.6.0 due to the reorganization of
the revision option parsing code. The "-i" is completely
ignored, but works fine in "git log --grep -i".

What happens is that the code for "-i" looks for
revs->grep_filter; if it is NULL, we do nothing, since there
are no grep filters. But that is obviously not correct,
since we want it to influence the later --grep option. Doing
it the other way around works, since "-i" just impacts the
existing grep_filter option.

Instead, we now always initialize the grep_filter member and
just fill in options and patterns as we get them. This means
that we can no longer check grep_filter for NULL, but
instead must check the pattern list to see if we have any
actual patterns.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-24 23:28:02 -07:00
Pierre Habouzit 0fe8c13810 Allow "non-option" revision options in parse_option-enabled commands
Commands which use parse_options() but also call setup_revisions()
must do their parsing in a two step process:

  1. first, they parse all options. Anything unknown goes to
     parse_revision_opt() (which calls handle_revision_opt), which
     may claim the option or say "I don't recognize this"

  2. the non-option remainder goes to setup_revisions() to
     actually get turned into revisions

Some revision options are "non-options" in that they must be
parsed in order with their revision counterparts in
setup_revisions().  For example, "--all" functions as a
pseudo-option expanding to all refs, and "--no-walk" affects refs
after it on the command line, but not before. The revision option
parser in step 1 recognizes such options and sets them aside for
later parsing by setup_revisions().

However, the return value used from handle_revision_opt indicated
"I didn't recognize this", which was wrong. It did, and it took
appropriate action (even though that action was just deferring it
for later parsing). Thus it should return "yes, I recognized
this."

Previously, these pseudo-options generated an error when used with
parse_options parsers (currently just blame and shortlog). With
this patch, they should work fine, enabling things like "git
shortlog --all".

Signed-off-by: Jeff King <peff@peff.net>
Acked-By: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-31 11:35:17 -07:00
Junio C Hamano 88bbda08d7 Merge branch 'maint'
* maint:
  Start preparing 1.5.6.4 release notes
  git fetch-pack: do not complain about "no common commits" in an empty repo
  rebase-i: keep old parents when preserving merges
  t7600-merge: Use test_expect_failure to test option parsing
  Fix buffer overflow in prepare_attr_stack
  Fix buffer overflow in git diff
  Fix buffer overflow in git-grep
  git-cvsserver: fix call to nonexistant cleanupWorkDir()
  Documentation/git-cherry-pick.txt et al.: Fix misleading -n description

Conflicts:
	RelNotes
2008-07-16 17:10:28 -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
Junio C Hamano c158cae110 Merge branch 'ag/rewrite_one'
* ag/rewrite_one:
  Fix quadratic performance in rewrite_one.
2008-07-15 18:59:48 -07:00
Junio C Hamano fa6200fc02 Merge branch 'ph/parseopt-step-blame'
* ph/parseopt-step-blame:
  revisions: refactor handle_revision_opt into parse_revision_opt.
  git-shortlog: migrate to parse-options partially.
  git-blame: fix lapsus
  git-blame: migrate to incremental parse-option [2/2]
  git-blame: migrate to incremental parse-option [1/2]
  revisions: split handle_revision_opt() from setup_revisions()
  parse-opt: add PARSE_OPT_KEEP_ARGV0 parser option.
  parse-opt: fake short strings for callers to believe in.
  parse-opt: do not print errors on unknown options, return -2 intead.
  parse-opt: create parse_options_step.
  parse-opt: Export a non NORETURN usage dumper.
  parse-opt: have parse_options_{start,end}.
  git-blame --reverse
  builtin-blame.c: allow more than 16 parents
  builtin-blame.c: move prepare_final() into a separate function.
  rev-list --children
  revision traversal: --children option
2008-07-13 15:16:35 -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
Pierre Habouzit 6b61ec0564 revisions: refactor handle_revision_opt into parse_revision_opt.
It seems we're using handle_revision_opt the same way each time, have a
wrapper around it that does the 9-liner we copy each time instead.

handle_revision_opt can be static in the module for now, it's always
possible to make it public again if needed.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-09 15:14:11 -07:00
Pierre Habouzit 02e542206f revisions: split handle_revision_opt() from setup_revisions()
Add two fields to struct rev_info:

 - .def to store --default argument; and
 - .show_merge 1-bit field.

handle_revision_opt() is able to deal with any revision option, and
consumes them, and leaves revision arguments or pseudo arguments
(like --all, --not, ...) in place.

For now setup_revisions() does a pass of handle_revision_opt() again
so that code not using it in a parse-opt parser still work the same.

Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-08 15:29:40 -07:00
Junio C Hamano 8bb65883d1 Merge branch 'jc/blame' (early part) into HEAD
* 'jc/blame' (early part):
  git-blame --reverse
  builtin-blame.c: allow more than 16 parents
  builtin-blame.c: move prepare_final() into a separate function.
  rev-list --children
  revision traversal: --children option

Conflicts:

	Documentation/rev-list-options.txt
	revision.c
2008-07-08 15:25:44 -07:00
Adam Brewster 1fc561d169 Move read_revisions_from_stdin from builtin-rev-list.c to revision.c
Reading rev-list parameters from the command line can be reused by
commands other than rev-list.  Move this function to more "library-ish"
place to promote code reuse.

Signed-off-by: Adam Brewster <asb@bu.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-05 17:30:58 -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 f35f5603f4 revision traversal: --children option
This adds a new --children option to the revision machinery.  In addition
to the list of parents, child commits of each commit are computed and
stored as a decoration to each commit.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-12 19:41:29 -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