Commit Graph

282 Commits

Author SHA1 Message Date
Junio C Hamano
f67d2e82d6 Merge branch 'jk/format-patch-am'
* jk/format-patch-am:
  format-patch: preserve subject newlines with -k
  clean up calling conventions for pretty.c functions
  pretty: add pp_commit_easy function for simple callers
  mailinfo: always clean up rfc822 header folding
  t: test subject handling in format-patch / am pipeline

Conflicts:
	builtin/branch.c
	builtin/log.c
	commit.h
2011-05-31 12:19:11 -07:00
Junio C Hamano
3d109dd8ef Merge branch 'jc/notes-batch-removal'
* jc/notes-batch-removal:
  show: --ignore-missing
  notes remove: --stdin reads from the standard input
  notes remove: --ignore-missing
  notes remove: allow removing more than one
2011-05-29 23:51:26 -07:00
Jeff King
9553d2b263 format-patch: preserve subject newlines with -k
In older versions of git, we used rfc822 header folding to
indicate that the original subject line had multiple lines
in it.  But since a1f6baa (format-patch: wrap long header
lines, 2011-02-23), we now use header folding whenever there
is a long line.

This means that "git am" cannot trust header folding as a
sign from format-patch that newlines should be preserved.
Instead, format-patch needs to signal more explicitly that
the newlines are significant.  This patch does so by
rfc2047-encoding the newlines in the subject line. No
changes are needed on the "git am" end; it already decodes
the newlines properly.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-26 15:56:55 -07:00
Junio C Hamano
cc243c3ceb show: --ignore-missing
Instead of barfing, simply ignore bad object names seen in the
input. This is useful when reading from "git notes list" output
that may refer to objects that have already been garbage collected.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-19 10:55:54 -07:00
Jay Soffian
0c47695a69 Add log.abbrevCommit config variable
Add log.abbrevCommit config variable as a convenience for users who
often use --abbrev-commit with git log and friends. Allow the option
to be overridden with --no-abbrev-commit. Per 635530a2fc and 4f62c2bc57,
the config variable is ignored when log is given "--pretty=raw".

(Also, a drive-by spelling correction in git log's short help.)

Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-18 12:40:15 -07:00
Michael J Gruber
b388e14b89 rev-list --count: separate count for --cherry-mark
When --count is used with --cherry-mark, omit the patch equivalent
commits from the count for left and right commits and print the count of
equivalent commits separately.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-26 13:13:20 -07:00
Junio C Hamano
bf0c5bbe25 Merge branch 'mg/rev-list-n-parents'
* mg/rev-list-n-parents:
  tests: avoid nonportable {foo,bar} glob
  rev-list --min-parents,--max-parents: doc, test and completion
  revision.c: introduce --min-parents and --max-parents options
  t6009: use test_commit() from test-lib.sh
2011-03-26 20:13:17 -07:00
Michael J Gruber
ad5aeeded3 revision.c: introduce --min-parents and --max-parents options
Introduce --min-parents and --max-parents options which limit the
revisions to those commits which have at least (or at most) that many
commits, where negative arguments for --max-parents= denote infinity
(i.e. no upper limit).

In particular:

  --max-parents=1 is the same as --no-merges;
  --min-parents=2 is the same as --merges;
  --max-parents=0 shows only roots; and
  --min-parents=3 shows only octopus merges

Using --min-parents=n and --max-parents=m with n>m gives you what you ask
for (i.e. nothing) for obvious reasons, just like when you give --merges
(show only merge commits) and --no-merges (show only non-merge commits) at
the same time.

Also, introduce --no-min-parents and --no-max-parents to do the obvious
thing for convenience.

We compute the number of parents only when we limit by that, so there
is no performance impact when there are no limiters.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-23 10:16:44 -07:00
Junio C Hamano
aeb2aaa771 Merge branch 'mg/rev-list-one-side-only'
* mg/rev-list-one-side-only:
  git-log: put space after commit mark
  t6007: test rev-list --cherry
  log --cherry: a synonym
  rev-list: documentation and test for --cherry-mark
  revision.c: introduce --cherry-mark
  rev-list/log: factor out revision mark generation
  rev-list: --left/right-only are mutually exclusive
  rev-list: documentation and test for --left/right-only
  t6007: Make sure we test --cherry-pick
  revlist.c: introduce --left/right-only for unsymmetric picking
2011-03-22 21:38:50 -07:00
Michael J Gruber
b1b47554ae git-log: put space after commit mark
Currently, commit marks (left, right, boundary, cherry) are output right
before the commit sha1, which makes it difficult to copy sha1s. Sample
output for "git log --oneline --cherry":

=049c269 t6007: test rev-list --cherry

Change this to

= 049c269 t6007: test rev-list --cherry

which matches exactly the current output of "git log --graph".

Leave "git rev-list" output as is (no space) so that they do not break.

Adjust "git-svn" which uses "git log --pretty=raw --boundary".

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-10 21:55:29 -08:00
Michael J Gruber
adbbb31e0d revision.c: introduce --cherry-mark
for marking those commits which "--cherry-pick" would drop.
The marker for those commits is '=' because '-' denotes a boundary
commit already, even though 'git cherry' uses it.

Nonequivalent commits are denoted '+' unless '--left-right' is used.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09 13:50:54 -08:00
Michael J Gruber
1df2d656cc rev-list/log: factor out revision mark generation
Currently, we have identical code for generating revision marks ('<',
'>', '-') in 5 places.

Factor out the code to a single function get_revision_mark() for easier
maintenance and extensibility.

Note that the check for !!revs in graph.c (which gets removed
effectively by this patch) is superfluous.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09 13:50:54 -08:00
Michael J Gruber
60adf7d73e revlist.c: introduce --left/right-only for unsymmetric picking
The existing "--cherry-pick" does not work with unsymmetric ranges
(A..B) for obvious reasons.

Introduce "--left-only" and "--right-only" which limit the output to
commits on the respective sides of a symmetric range (i.e. only "<"
resp. ">" commits as per "--left-right").

This is especially useful for things like

    git log --cherry-pick --right-only @{u}...

which is much more flexible (and descriptive) than

    git cherry @{u} | sed -ne 's/^+ //p'

and potentially more useful than

    git log --cherry-pick @{u}...

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-21 16:30:58 -08:00
Nguyễn Thái Ngọc Duy
afe069d166 struct rev_info: convert prune_data to struct pathspec
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-02-03 14:08:30 -08:00
Heiko Voigt
9ef6aeb09f setup_revisions(): Allow walking history in a submodule
By passing the path to a submodule in opt->submodule, the function can
be used to walk history in the named submodule repository, instead of
the toplevel repository.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-07-07 09:48:33 -07:00
Junio C Hamano
6296062285 Merge branch 'tr/rev-list-count'
* tr/rev-list-count:
  bash completion: Support "divergence from upstream" messages in __git_ps1
  rev-list: introduce --count option

Conflicts:
	contrib/completion/git-completion.bash
2010-06-30 11:55:38 -07:00
Thomas Rast
f69c501832 rev-list: introduce --count option
Add a --count option that, instead of actually listing the commits,
merely counts them.

This is mostly geared towards script use, and to this end it acts
specially when used with --left-right: it outputs the left and right
counts separately.  Previously, scripts would have to run a shell loop
or small inline script over to achieve the same.  (Without
--left-right, a simple |wc -l does the job.)

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-06-12 09:39:06 -07:00
Junio C Hamano
ebdc94f3be revision: --ancestry-path
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A.  This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).

	       x---x---A---B---C  <-- topic
	      /			\
     x---x---x---o---o---o---o---M---D---E---F---G  <-- dev
    /						  \
   x---o---o---o---o---o---o---o---o---o---o---o---N---H  <-- master

The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.

When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'.  Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".

Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-21 01:15:33 -07:00
Junio C Hamano
a86ed83cce Merge branch 'tr/notes-display'
* tr/notes-display:
  git-notes(1): add a section about the meaning of history
  notes: track whether notes_trees were changed at all
  notes: add shorthand --ref to override GIT_NOTES_REF
  commit --amend: copy notes to the new commit
  rebase: support automatic notes copying
  notes: implement helpers needed for note copying during rewrite
  notes: implement 'git notes copy --stdin'
  rebase -i: invoke post-rewrite hook
  rebase: invoke post-rewrite hook
  commit --amend: invoke post-rewrite hook
  Documentation: document post-rewrite hook
  Support showing notes from more than one notes tree
  test-lib: unset GIT_NOTES_REF to stop it from influencing tests

Conflicts:
	git-am.sh
	refs.c
2010-03-24 16:26:43 -07:00
Thomas Rast
894a9d333e Support showing notes from more than one notes tree
With this patch, you can set notes.displayRef to a glob that points at
your favourite notes refs, e.g.,

[notes]
	displayRef = refs/notes/*

Then git-log and friends will show notes from all trees.

Thanks to Junio C Hamano for lots of feedback, which greatly
influenced the design of the entire series and this commit in
particular.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-12 21:55:39 -08:00
Junio C Hamano
b449005997 show -c: show patch text
Traditionally, "show" defaulted to "show --cc" (dense combined patch), but
asking for combined patch with "show -c" didn't turn the patch output
format on; the placement of this logic in setup_revisions() dates back to
cd2bdc5 (Common option parsing for "git log --diff" and friends,
2006-04-14).

This unfortunately cannot be done as a trivial change of "if dense
combined is asked, default to patch format" done in setup_revisions() to
"if any combined is asked, default to patch format", as "diff-tree -c"
needs to default to raw, while "diff-tree --cc" needs to default to patch,
and they share the codepath.  These command specific defaults are now
handled in the new "tweak" callback that can be customized by individual
command implementations.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-09 01:11:18 -08:00
Junio C Hamano
32962c9bd5 revision: introduce setup_revision_opt
So far the last parameter to setup_revisions() was to specify the default
ref when the command line did not give any (typically "HEAD").  This changes
it to take a pointer to a structure so that we can add other information without
touching too many codepaths in later patches.

There is no functionality change.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-09 01:11:18 -08:00
Junio C Hamano
66b2ed09c2 Fix "log" family not to be too agressive about showing notes
Giving "Notes" information in the default output format of "log" and
"show" is a sensible progress (the user has asked for it by having the
notes), but for some commands (e.g. "format-patch") spewing notes into the
formatted commit log message without being asked is too aggressive.

Enable notes output only for "log", "show", "whatchanged" by default and
only when the user didn't ask any specific --pretty/--format from the
command line; users can explicitly override this default with --show-notes
and --no-notes option.

Parts of tests are taken from Jeff King's fix.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-20 19:57:02 -08:00
Junio C Hamano
e61f25f3a6 Merge branch 'jc/log-stdin'
* jc/log-stdin:
  Add trivial tests for --stdin option to log family
  Make --stdin option to "log" family read also pathspecs
  setup_revisions(): do not call get_pathspec() too early
  Teach --stdin option to "log" family
  read_revision_from_stdin(): use strbuf

Conflicts:
	revision.c
2009-11-23 22:30:08 -08:00
Junio C Hamano
8b3dce5650 Teach --stdin option to "log" family
Move the logic to read revs from standard input that rev-list knows about
from it to revision machinery, so that all the users of setup_revisions()
can feed the list of revs from the standard input when "--stdin" is used
on the command line.

Allow some users of the revision machinery that want different semantics
from the "--stdin" option to disable it by setting an option in the
rev_info structure.

This also cleans up the kludge made to bundle.c via cut and paste.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20 15:10:29 -08:00
Linus Torvalds
ad3f9a71a8 Add '--bisect' revision machinery argument
I personally use "git bisect visualize" all the time when I bisect, but it
turns out that that is not a very flexible model. Sometimes I want to do
bisection based on all commits (no pathname limiting), but then visualize
the current bisection tree with just a few pathnames because I _suspect_
those pathnames are involved in the problem but am not totally sure about
them.

And at other times, I want to use other revision parsing logic, none of
which is available with "git bisect visualize".

So this adds "--bisect" as a revision parsing argument, and as a result it
just works with all the normal logging tools. So now I can just do

	gitk --bisect --simplify-by-decoration filename-here

etc.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-28 16:07:43 -07:00
Jeff King
f4ea32f0b4 improve reflog date/number heuristic
When we show a reflog, we have two ways of naming the entry:
by sequence number (e.g., HEAD@{0}) or by date (e.g.,
HEAD@{10 minutes ago}). There is no explicit option to set
one or the other, but we guess based on whether or not the
user has provided us with a date format, showing them the
date version if they have done so, and the sequence number
otherwise.

This usually made sense if the use did something like "git
log -g --date=relative". However, it didn't make much sense
if the user set the date format using the log.date config
variable; in that case, all of their reflogs would end up as
dates.

This patch records the source of the date format and only
triggers the date-based view if --date= was given on the
command line.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2009-09-29 10:06:49 -07:00
Junio C Hamano
24343c6099 Merge branch 'as/maint-graph-interesting-fix'
* as/maint-graph-interesting-fix:
  Add tests for rev-list --graph with options that simplify history
  graph API: fix bug in graph_is_interesting()
2009-08-27 16:59:56 -07:00
Adam Simpkins
beb5af43a6 graph API: fix bug in graph_is_interesting()
Previously, graph_is_interesting() did not behave quite the same way as
the code in get_revision().  As a result, it would sometimes think
commits were uninteresting, even though get_revision() would return
them.  This resulted in incorrect lines in the graph output.

This change creates a get_commit_action() function, which
graph_is_interesting() and simplify_commit() both now use to determine
if a commit will be shown.  It is identical to the old simplify_commit()
behavior, except that it never calls rewrite_parents().

This problem was reported by Santi Béjar.  The following command
would exhibit the problem before, but now works correctly:

  git log --graph --simplify-by-decoration --oneline v1.6.3.3

Previously git graph did not display the output for this command
correctly between f29ac4f and 66996ec, among other places.

Signed-off-by: Adam Simpkins <simpkins@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-21 12:41:25 -07:00
Lars Hjemli
33e7018c45 git-log: allow --decorate[=short|full]
Commit de435ac0 changed the behavior of --decorate from printing the
full ref (e.g., "refs/heads/master") to a shorter, more human-readable
version (e.g., just "master"). While this is nice for human readers,
external tools using the output from "git log" may prefer the full
version.

This patch introduces an extension to --decorate to allow the caller to
specify either the short or the full versions.

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-08-18 13:14:17 -07:00
Linus Torvalds
b8e8db281c git log: add '--merges' flag to match '--no-merges'
I do various statistics on git, and one of the things I look at is merges,
because they are often interesting events to count ("how many merges vs
how much 'real development'" kind of statistics). And you can do it with
some fairly straightforward scripting, ie

	git rev-list --parents HEAD |
		grep ' .* ' |
		git diff-tree --always -s --pretty=oneline --stdin |
		less -S

will do it.

But I finally got irritated with the fact that we can skip merges with
'--no-merges', but we can't do the trivial reverse operation.

So this just adds a '--merges' flag that _only_ shows merges. Now you can
do the above with just a

	git log --merges --pretty=oneline

which is a lot simpler. It also means that we automatically get a lot of
statistics for free, eg

	git shortlog -ns --merges

does exactly what you'd want it to do.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-29 12:32:51 -07:00
Linus Torvalds
ceff8e7ade Clean up and simplify rev_compare_tree()
This simplifies the logic of rev_compare_tree() by removing a special
case.

It does so by turning the special case of finding a diff to be "all new
files" into a more generic case of "all new" vs "all removed" vs "mixed
changes", so now the code is actually more powerful and more generic, and
the added symmetry actually makes it simpler too.

This makes no changes to any existing behavior, but apart from the
simplification it does make it possible to some day care about whether all
changes were just deletions if we want to. Which we may well want to for
merge handling.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-06-03 00:49:50 -07:00
Junio C Hamano
9824a388e5 Merge branch 'lt/pack-object-memuse'
* lt/pack-object-memuse:
  show_object(): push path_name() call further down
  process_{tree,blob}: show objects without buffering

Conflicts:
	builtin-pack-objects.c
	builtin-rev-list.c
	list-objects.c
	list-objects.h
	upload-pack.c
2009-04-18 14:46:17 -07:00
Linus Torvalds
cf2ab916af show_object(): push path_name() call further down
In particular, pushing the "path_name()" call _into_ the show() function
would seem to allow

 - more clarity into who "owns" the name (ie now when we free the name in
   the show_object callback, it's because we generated it ourselves by
   calling path_name())

 - not calling path_name() at all, either because we don't care about the
   name in the first place, or because we are actually happy walking the
   linked list of "struct name_path *" and the last component.

Now, I didn't do that latter optimization, because it would require some
more coding, but especially looking at "builtin-pack-objects.c", we really
don't even want the whole pathname, we really would be better off with the
list of path components.

Why? We use that name for two things:
 - add_preferred_base_object(), which actually _wants_ to traverse the
   path, and now does it by looking for '/' characters!
 - for 'name_hash()', which only cares about the last 16 characters of a
   name, so again, generating the full name seems to be just unnecessary
   work.

Anyway, so I didn't look any closer at those things, but it did convince
me that the "show_object()" calling convention was crazy, and we're
actually better off doing _less_ in list-objects.c, and giving people
access to the internal data structures so that they can decide whether
they want to generate a path-name or not.

This patch does that, and then for people who did use the name (even if
they might do something more clever in the future), it just does the
straightforward "name = path_name(path, component); .. free(name);" thing.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-12 17:28:31 -07:00
Linus Torvalds
8d2dfc49b1 process_{tree,blob}: show objects without buffering
Here's a less trivial thing, and slightly more dubious one.

I was looking at that "struct object_array objects", and wondering why we
do that. I have honestly totally forgotten. Why not just call the "show()"
function as we encounter the objects? Rather than add the objects to the
object_array, and then at the very end going through the array and doing a
'show' on all, just do things more incrementally.

Now, there are possible downsides to this:

 - the "buffer using object_array" _can_ in theory result in at least
   better I-cache usage (two tight loops rather than one more spread out
   one). I don't think this is a real issue, but in theory..

 - this _does_ change the order of the objects printed. Instead of doing a
   "process_tree(revs, commit->tree, &objects, NULL, "");" in the loop
   over the commits (which puts all the root trees _first_ in the object
   list, this patch just adds them to the list of pending objects, and
   then we'll traverse them in that order (and thus show each root tree
   object together with the objects we discover under it)

   I _think_ the new ordering actually makes more sense, but the object
   ordering is actually a subtle thing when it comes to packing
   efficiency, so any change in order is going to have implications for
   packing. Good or bad, I dunno.

 - There may be some reason why we did it that odd way with the object
   array, that I have simply forgotten.

Anyway, now that we don't buffer up the objects before showing them
that may actually result in lower memory usage during that whole
traverse_commit_list() phase.

This is seriously not very deeply tested. It makes sense to me, it seems
to pass all the tests, it looks ok, but...

Does anybody remember why we did that "object_array" thing? It used to be
an "object_list" a long long time ago, but got changed into the array due
to better memory usage patterns (those linked lists of obejcts are
horrible from a memory allocation standpoint). But I wonder why we didn't
do this back then. Maybe there's a reason for it.

Or maybe there _used_ to be a reason, and no longer is.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-12 17:28:31 -07:00
Junio C Hamano
87d2062b39 Merge branch 'sb/format-patch-patchname'
* sb/format-patch-patchname:
  format_sanitized_subject: Don't trim past initial length of strbuf
  log-tree: fix patch filename computation in "git format-patch"
  format-patch: --numbered-files and --stdout aren't mutually exclusive
  format-patch: --attach/inline uses filename instead of SHA1
  format-patch: move get_patch_filename() into log-tree
  format-patch: pass a commit to reopen_stdout()
  format-patch: construct patch filename in one function
  pretty.c: add %f format specifier to format_commit_message()
2009-04-06 00:42:23 -07:00
Junio C Hamano
3c91bf6805 Merge branch 'jc/maint-1.6.0-keep-pack'
* jc/maint-1.6.0-keep-pack:
  pack-objects: don't loosen objects available in alternate or kept packs
  t7700: demonstrate repack flaw which may loosen objects unnecessarily
  Remove --kept-pack-only option and associated infrastructure
  pack-objects: only repack or loosen objects residing in "local" packs
  git-repack.sh: don't use --kept-pack-only option to pack-objects
  t7700-repack: add two new tests demonstrating repacking flaws

Conflicts:
	t/t7700-repack.sh
2009-04-01 22:34:19 -07:00
Stephen Boyd
108dab2811 format-patch: --attach/inline uses filename instead of SHA1
Currently when format-patch is used with --attach or --inline the patch
attachment has the SHA1 of the commit for its filename.  This replaces
the SHA1 with the filename used by format-patch when outputting to
files.

Fix tests relying on the SHA1 output and add a test showing how the
--suffix option affects the attachment filename output.

Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22 21:45:19 -07:00
Brandon Casey
4d6acb7041 Remove --kept-pack-only option and associated infrastructure
This option to pack-objects/rev-list was created to improve the -A and -a
options of repack.  It was found to be lacking in that it did not provide
the ability to differentiate between local and non-local kept packs, and
found to be unnecessary since objects residing in local kept packs can be
filtered out by the --honor-pack-keep option.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-20 13:32:33 -07:00
Junio C Hamano
aec813062b Merge branch 'jc/maint-1.6.0-keep-pack'
* jc/maint-1.6.0-keep-pack:
  is_kept_pack(): final clean-up
  Simplify is_kept_pack()
  Consolidate ignore_packed logic more
  has_sha1_kept_pack(): take "struct rev_info"
  has_sha1_pack(): refactor "pretend these packs do not exist" interface
  git-repack: resist stray environment variable
2009-03-11 13:49:56 -07:00
Junio C Hamano
69e020ae00 is_kept_pack(): final clean-up
Now is_kept_pack() is just a member lookup into a structure, we can write
it as such.

Also rewrite the sole caller of has_sha1_kept_pack() to switch on the
criteria the callee uses (namely, revs->kept_pack_only) between calling
has_sha1_kept_pack() and has_sha1_pack(), so that these two callees do not
have to take a pointer to struct rev_info as an argument.

This removes the header file dependency issue temporarily introduced by
the earlier commit, so we revert changes associated to that as well.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-28 01:06:06 -08:00
Junio C Hamano
03a9683d22 Simplify is_kept_pack()
This removes --unpacked=<packfile> parameter from the revision parser, and
rewrites its use in git-repack to pass a single --kept-pack-only option
instead.

The new --kept-pack-only option means just that.  When this option is
given, is_kept_pack() that used to say "not on the --unpacked=<packfile>
list" now says "the packfile has corresponding .keep file".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-28 01:06:06 -08:00
Junio C Hamano
386cb77210 Consolidate ignore_packed logic more
This refactors three loops that check if a given packfile is on the
ignore_packed list into a function is_kept_pack().  The function returns
false for a pack on the list, and true for a pack not on the list, because
this list is solely used by "git repack" to pass list of packfiles that do
not have corresponding .keep files, i.e. a packfile not on the list is
"kept".

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-28 01:06:06 -08:00
Junio C Hamano
b8431b033f has_sha1_kept_pack(): take "struct rev_info"
Its "ignore_packed" parameter always comes from struct rev_info.  This
patch makes the function take a pointer to the surrounding structure, so
that the refactoring in the next patch becomes easier to review.

There is an unfortunate header file dependency and the easiest workaround
is to temporarily move the function declaration from cache.h to
revision.h; this will be moved back to cache.h once the function loses
this "ignore_packed" parameter altogether in the later part of the
series.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-28 01:06:06 -08:00
Thomas Rast
b079c50e03 format-patch: track several references
Currently, format-patch can only track a single reference (the
In-Reply-To:) for each mail.  To ensure proper threading, we should
list all known references for every mail.

Change the rev_info.ref_message_id field to a string_list, so that we
can append references at will, and change the output formatting
routines to print all of them in the References: header.  The last
entry in the list is implicitly assumed to be the In-Reply-To:, which
gives output consistent with RFC 2822:

   The "References:" field will contain the contents of the parent's
   "References:" field (if any) followed by the contents of the
   parent's "Message-ID:" field (if any).

Note that this is just preparatory work; nothing uses it yet, so all
"References:" fields in the output are still only one deep.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-21 20:26:03 -08:00
Linus Torvalds
78892e3261 revision traversal: '--simplify-by-decoration'
With this, you can simplify history not by the contents of the tree, but
whether a commit has been named (ie it's referred to by some branch or
tag) or not.

This makes it possible to see the relationship between different named
commits, without actually seeing any of the details.

When used with pathspec, you would get the usual view that is limited to
the commits that change the contents of the tree plus commits that are
named.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-04 00:45:34 -08:00
Linus Torvalds
d467a525da Make '--decorate' set an explicit 'show_decorations' flag
We will want to add decorations without necessarily showing them, so add
an explicit revisions info flag as to whether we're showing decorations
or not.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-04 00:08:19 -08:00
Linus Torvalds
0f3a290b89 Add a 'source' decorator for commits
We already support decorating commits by tags or branches that point to
them, but especially when we are looking at multiple branches together,
we sometimes want to see _how_ we reached a particular commit.

We can abuse the '->util' field in the commit to keep track of that as
we walk the commit lists, and get a reasonably useful view into which
branch or tag first reaches that commit.

Of course, if the commit is reachable through multiple sources (which is
common), our particular choice of "first" reachable is entirely random
and depends on the particular path we happened to follow.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-11-04 00:08:03 -08:00
Junio C Hamano
b805ef08e6 Merge branch 'tr/rev-list-reverse'
* tr/rev-list-reverse:
  t6013: replace use of 'tac' with equivalent Perl
  rev-list: fix --reverse interaction with --parents
2008-09-18 20:18:37 -07:00
Junio C Hamano
01914577ed Merge branch 'tr/filter-branch'
* tr/filter-branch:
  revision --simplify-merges: make it a no-op without pathspec
  revision --simplify-merges: do not leave commits unprocessed
  revision --simplify-merges: use decoration instead of commit->util field
  Documentation: rev-list-options: move --simplify-merges documentation
  filter-branch: use --simplify-merges
  filter-branch: fix ref rewriting with --subdirectory-filter
  filter-branch: Extend test to show rewriting bug
  Topo-sort before --simplify-merges
  revision traversal: show full history with merge simplification
  revision.c: whitespace fix
2008-09-02 17:47:13 -07:00
Thomas Rast
498bcd3159 rev-list: fix --reverse interaction with --parents
--reverse did not interact well with --parents, as the included test
case shows: in a history like

  A--B.
   \   \
    `C--M--D

the command

  git rev-list --reverse --parents --full-history HEAD

erroneously lists D as having no parents at all.  (Without --reverse,
it correctly lists M.)

This is caused by the machinery driving --reverse: it first grabs all
commits through the normal routines, then runs them through the same
routines again, effectively simplifying them twice.

Fix this by moving the --reverse one level up, into get_revision().
This way we can cleanly grab all commits via the normal calls, then
just pop them off the list one by one without interfering with
get_revision_internal().

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-29 22:20:51 -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
Brandon Casey
4dc1db0bd1 revision.h: make show_early_output an extern which is defined in revision.c
The variable show_early_output is defined in revision.c and should be
declared extern in revision.h so that the linker does not complain
about multiply defined variables.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-20 19:59:06 -07:00
Junio C Hamano
faf0156b27 revision --simplify-merges: use decoration instead of commit->util field
The users of revision walking machinery may want to use the util pointer
for their own use.  Use decoration to hold the data needed during merge
simplification instead.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-14 15:45:16 -07:00
Junio C Hamano
6546b5931e revision traversal: show full history with merge simplification
The --full-history traversal keeps all merges in addition to non-merge
commits that touch paths in the given pathspec.  This is useful to view
both sides of a merge in a topology like this:

        A---M---o
       /   /
   ---O---B

even when A and B makes identical change to the given paths.  The revision
traversal without --full-history aims to come up with the simplest history
to explain the final state of the tree, and one of the side branches can
be pruned away.

The behaviour to keep all merges however is inconvenient if neither A nor
B touches the paths we are interested in.  --full-history reduces the
topology to:

   ---O---M---o

in such a case, without removing M.

This adds a post processing phase on top of --full-history traversal to
remove needless merges from the resulting history.

The idea is to compute, for each commit in the "full history" result set,
the commit that should replace it in the simplified history.  The commit
to replace it in the final history is determined as follows:

 * In any case, we first figure out the replacement commits of parents of
   the commit we are looking at.  The commit we are looking at is
   rewritten as if the replacement commits of its original parents are its
   parents.  While doing so, we reduce the redundant parents from the
   rewritten parent list by not just removing the identical ones, but also
   removing a parent that is an ancestor of another parent.

 * After the above parent simplification, if the commit is a root commit,
   an UNINTERESTING commit, a merge commit, or modifies the paths we are
   interested in, then the replacement commit of the commit is itself.  In
   other words, such a commit is not dropped from the final result.

The first point above essentially means that the history is rewritten in
the bottom up direction.  We can rewrite the parent list of a commit only
after we know how all of its parents are rewritten.  This means that the
processing needs to happen on the full history (i.e. after limit_list()).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-08-02 00:33:15 -07:00
Johannes Schindelin
e358f3c31e sort_in_topological_order(): avoid setting a commit flag
We used to set the TOPOSORT flag of commits during the topological
sorting, but we can just as well use the member "indegree" for it:
indegree is now incremented by 1 in the cases where the commit used
to have the TOPOSORT flag.

This is the same behavior as before, since indegree could not be
non-zero when TOPOSORT was unset.

Incidentally, this fixes the bug in show-branch where the 8th column
was not shown: show-branch sorts the commits in topological order,
assuming that all the commit flags are available for show-branch's
private matters.

But this was not true: TOPOSORT was identical to the flag corresponding
to the 8th ref.  So the flags for the 8th column were unset by the
topological sorting.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-23 12:00:21 -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
Junio C Hamano
e636799b4d Merge branch 'jc/report-tracking'
* jc/report-tracking:
  branch -r -v: do not spit out garbage
  stat_tracking_info(): clear object flags used during counting
  git-branch -v: show the remote tracking statistics
  git-status: show the remote tracking statistics
  Refactor "tracking statistics" code used by "git checkout"
2008-07-13 15:15:23 -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
c0234b2ef6 stat_tracking_info(): clear object flags used during counting
When left-right traversal counts the commits in a diverged history, it
leaves the flags in the commits smudged, and we need to clear them before
we return.  Otherwise the caller cannot inspect other branches with this
function again.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-03 12:14:53 -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
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
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
Junio C Hamano
992221d05e Merge branch 'db/cover-letter'
* db/cover-letter:
  Improve collection of information for format-patch --cover-letter
  Add API access to shortlog
  t4014: Replace sed's non-standard 'Q' by standard 'q'
  Support a --cc=<email> option in format-patch
  Combine To: and Cc: headers
  Fix format.headers not ending with a newline
  Add tests for extra headers in format-patch
  Add a --cover-letter option to format-patch
  Export some email and pretty-printing functions
  Improve message-id generation flow control for format-patch
  Add more tests for format-patch

Conflicts:

	builtin-log.c
	builtin-shortlog.c
	pretty.c
2008-02-27 12:06:41 -08:00
Daniel Barkalow
e1a3734621 Improve message-id generation flow control for format-patch
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-02-19 00:56:46 -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
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
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
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
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
Junio C Hamano
2d93b9face More missing static
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-08 02:37:19 -07:00
Alex Riesen
cc0e6c5adc Handle return code of parse_commit in revision machinery
This fixes a crash in broken repositories where random commits
suddenly disappear.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-05-06 00:07:07 -07:00
Junio C Hamano
a7b02ccf9a Add --date={local,relative,default}
This adds --date={local,relative,default} option to log family of commands,
to allow displaying timestamps in user's local timezone, relative time, or
the default format.

Existing --relative-date option is a synonym of --date=relative; we could
probably deprecate it in the long run.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-25 21:39:43 -07:00
Martin Koegler
bb6c2fba41 store mode in rev_list, if <tree>:<filename> syntax is used
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-24 00:08:49 -07:00
Junio C Hamano
d7a17cad97 git-log --cherry-pick A...B
This is meant to be a saner replacement for "git-cherry".

When used with "A...B", this filters out commits whose patch
text has the same patch-id as a commit on the other side.  It
would probably most useful to use with --left-right.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-11 20:02:03 -07:00
Robin H. Johnson
2d9e4a47d1 Add custom subject prefix support to format-patch (take 3)
Add a new option to git-format-patch, entitled --subject-prefix that allows
control of the subject prefix '[PATCH]'. Using this option, the text 'PATCH' is
replaced with whatever input is provided to the option. This allows easily
generating patches like '[PATCH 2.6.21-rc3]' or properly numbered series like
'[-mm3 PATCH N/M]'. This patch provides the implementation and documentation.

Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-04-11 18:48:30 -07:00
Junio C Hamano
0053e902b4 git-log --first-parent: show only the first parent log
If your development history does not have fast-forward merges,
i.e. the "first parent" of commits in your history are special
than other parents, this option gives a better overview of the
evolution of a particular branch.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-14 16:22:18 -07:00
Junio C Hamano
2422f1ca3b Merge branch 'jc/boundary'
* jc/boundary:
  git-bundle: prevent overwriting existing bundles
  git-bundle: die if a given ref is not included in bundle
  git-bundle: handle thin packs in subcommand "unbundle"
  git-bundle: Make thin packs
  git-bundle: avoid packing objects which are in the prerequisites
  bundle: fix wrong check of read_header()'s return value & add tests
  revision --boundary: fix uncounted case.
  revision --boundary: fix stupid typo
  git-bundle: make verify a bit more chatty.
  revision traversal: SHOWN means shown
  git-bundle: various fixups
  revision traversal: retire BOUNDARY_SHOW
  revision walker: Fix --boundary when limited
2007-03-11 23:02:52 -07:00
Junio C Hamano
2b064697a5 revision traversal: retire BOUNDARY_SHOW
This removes the flag internally used by revision traversal to
decide which commits are indeed boundaries and renames it to
CHILD_SHOWN.  builtin-bundle uses the symbol for its
verification, but I think the logic it uses it is wrong.  The
flag is still useful but it is local to the git-bundle, so it is
renamed to PREREQ_MARK.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-06 01:08:34 -08:00
Junio C Hamano
86ab4906a7 revision walker: Fix --boundary when limited
This cleans up the boundary processing in the commit walker.  It

 - rips out the boundary logic from the commit walker. Placing
   "negative" commits in the revs->commits list was Ok if all we
   cared about "boundary" was the UNINTERESTING limiting case,
   but conceptually it was wrong.

 - makes get_revision_1() function to walk the commits and return
   the results as if there is no funny postprocessing flags such
   as --reverse, --skip nor --max-count.

 - makes get_revision() function the postprocessing phase:

   If reverse is given, wait for get_revision_1() to give
   everything that it would normally give, and then reverse it
   before consuming.

   If skip is given, skip that many before going further.

   If max is given, stop when we gave out that many.

   Now that we are about to return one positive commit, mark
   the parents of that commit to be potential boundaries
   before returning, iff we are doing the boundary processing.

   Return the commit.

 - After get_revision() finishes giving out all the positive
   commits, if we are doing the boundary processing, we look at
   the parents that we marked as potential boundaries earlier,
   see if they are really boundaries, and give them out.

It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.

Note that this patch is purely for eyeballing and discussion
only.  It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore.  After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-06 01:08:34 -08:00
Johannes Schindelin
c112f689c2 format-patch: add --inline option and make --attach a true attachment
The existing --attach option did not create a true "attachment"
but multipart/mixed with Content-Disposition: inline.  It should
have been with Content-Disposition: attachment.

Introduce --inline to add multipart/mixed that is inlined, and
make --attach to create an attachement.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-03-04 17:31:29 -08:00
Johannes Schindelin
9c5e66e97d Teach revision machinery about --reverse
The option --reverse reverses the order of the commits.

[jc: with comments on rev_info.reverse from Simon 'corecode' Schubert.]

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-20 23:46:53 -08:00
Johannes Schindelin
8860fd42fc Teach the revision walker to walk by reflogs with --walk-reflogs
When called with "--walk-reflogs", as long as there are reflogs
available, the walker will take this information into account, rather
than the parent information in the commit object.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-20 21:32:31 -08:00
Junio C Hamano
52883fbd76 Teach log family --encoding
Updated commit objects record the encoding used in their
encoding header.  This updates the log family to reencode it
into the encoding specified in i18n.commitencoding (or the
default, which is "utf-8") upon output.

To force a specific encoding that is different, log family takes
command line flag --encoding=<encoding>; giving --encoding=none
entirely disables the reencoding and lets you view log messges
in their original encoding.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-26 00:52:13 -08:00
Junio C Hamano
d4ada4876d Merge branch 'jc/skip-count'
* jc/skip-count:
  revision: --skip=<n>
2006-12-25 03:27:41 -08:00
Junio C Hamano
d5db6c9ee7 revision: --skip=<n>
This adds --skip=<n> option to revision traversal machinery.
Documentation and test were added by Robert Fitzsimons.

Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-20 11:26:11 -08:00
Junio C Hamano
8dce823562 Revert "Make left-right automatic."
This reverts commit 5761231975.

Feeding symmetric difference to gitk is so useful, and it is the
same for other graphical Porcelains.  Rather than forcing them
to pass --no-left-right, making it optional.

Noticed and reported by Jeff King.
2006-12-19 02:28:16 -08:00
Junio C Hamano
5761231975 Make left-right automatic.
When using symmetric differences, I think the user almost always
would want to know which side of the symmetry each commit came
from.  So this removes --left-right option from the command
line, and turns it on automatically when a symmetric difference
is used ("git log --merge" counts as a symmetric difference
between HEAD and MERGE_HEAD).

Just in case, a new option --no-left-right is provided to defeat
this, but I do not know if it would be useful.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17 10:35:28 -08:00
Junio C Hamano
74bd902973 Teach all of log family --left-right output.
This makes reviewing

     git log --left-right --merge --no-merges -p

a lot more pleasant.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17 10:35:28 -08:00
Junio C Hamano
577ed5c20b rev-list --left-right
The output from "symmetric diff", i.e. A...B, does not
distinguish between commits that are reachable from A and the
ones that are reachable from B.  In this picture, such a
symmetric diff includes commits marked with a and b.

         x---b---b  branch B
        / \ /
       /   .
      /   / \
     o---x---a---a  branch A

However, you cannot tell which ones are 'a' and which ones are
'b' from the output.  Sometimes this is frustrating.  This adds
an output option, --left-right, to rev-list.

        rev-list --left-right A...B

would show ones reachable from A prefixed with '<' and the ones
reachable from B prefixed with '>'.

When combined with --boundary, boundary commits (the ones marked
with 'x' in the above picture) are shown with prefix '-', so you
would see list that looks like this:

    git rev-list --left-right --boundary --pretty=oneline A...B

    >bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 3rd on b
    >bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2nd on b
    <aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 3rd on a
    <aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2nd on a
    -xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on b
    -xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on a

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-12-17 10:35:28 -08:00
Junio C Hamano
2d10c55537 git log: Unify header_filter and message_filter into one.
Now we can tell the built-in grep to grep only in head or in
body, use that to update --author, --committer, and --grep.

Unfortunately, to make --and, --not and other grep boolean
expressions useful, as in:

	# Things written by Junio committed and by Linus and log
	# does not talk about diff.

	git log --author=Junio --and --committer=Linus \
		--grep-not --grep=diff

we will need to do another round of built-in grep core
enhancement, because grep boolean expressions are designed to
work on one line at a time.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-20 13:21:56 -07:00
Junio C Hamano
8ecae9b032 revision traversal: prepare for commit log match.
This is from a suggestion by Linus, just to mark the locations where we
need to modify to actually implement the filtering.

We do not have any actual filtering code yet.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-20 11:14:39 -07:00
Junio C Hamano
106d710bc1 pack-objects --unpacked=<existing pack> option.
Incremental repack without -a essentially boils down to:

	rev-list --objects --unpacked --all |
        pack-objects $new_pack

which picks up all loose objects that are still live and creates
a new pack.

This implements --unpacked=<existing pack> option to tell the
revision walking machinery to pretend as if objects in such a
pack are unpacked for the purpose of object listing.  With this,
we could say:

	rev-list --objects --unpacked=$active_pack --all |
	pack-objects $new_pack

instead, to mean "all live loose objects but pretend as if
objects that are in this pack are also unpacked".  The newly
created pack would be perfect for updating $active_pack by
replacing it.

Since pack-objects now knows how to do the rev-list's work
itself internally, you can also write the above example by:

	pack-objects --unpacked=$active_pack --all $new_pack </dev/null

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-07 02:46:03 -07:00
Junio C Hamano
5d6f0935e6 revision.c: allow injecting revision parameters after setup_revisions().
setup_revisions() wants to get all the parameters at once and
then postprocesses the resulting revs structure after it is done
with them.  This code structure is a bit cumbersome to deal with
efficiently when we want to inject revision parameters from the
side (e.g. read from standard input).

Fortunately, the nature of this postprocessing is not affected by
revision parameters; they are affected only by flags.  So it is
Ok to do add_object() after the it returns.

This splits out the code that deals with the revision parameter
out of the main loop of setup_revisions(), so that we can later
call it from elsewhere after it returns.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-09-05 21:28:36 -07:00
Jonas Fonseca
3dfb9278df Add --relative-date option to the revision interface
Exposes the infrastructure from 9a8e35e987.

Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-28 16:20:33 -07:00
Linus Torvalds
db6296a566 Call setup_git_directory() early
Any git command that expects to work in a subdirectory of a project, and
that reads the git config files (which is just about all of them) needs to
make sure that it does the "setup_git_directory()" call before it tries to
read the config file.

This means, among other things, that we need to move the call out of
"init_revisions()", and into the caller.

This does the mostly trivial conversion to do that.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-28 22:03:06 -07:00
Josh Triplett
d1566f7883 git-format-patch: Make the second and subsequent mails replies to the first
Add message_id and ref_message_id fields to struct rev_info, used in show_log
with CMIT_FMT_EMAIL to set Message-Id and In-Reply-To/References respectively.
Use these in git-format-patch to make the second and subsequent patch mails
replies to the first patch mail.

Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-14 20:41:36 -07:00
Linus Torvalds
1f1e895fcc Add "named object array" concept
We've had this notion of a "object_list" for a long time, which eventually
grew a "name" member because some users (notably git-rev-list) wanted to
name each object as it is generated.

That object_list is great for some things, but it isn't all that wonderful
for others, and the "name" member is generally not used by everybody.

This patch splits the users of the object_list array up into two: the
traditional list users, who want the list-like format, and who don't
actually use or want the name. And another class of users that really used
the list as an extensible array, and generally wanted to name the objects.

The patch is fairly straightforward, but it's also biggish. Most of it
really just cleans things up: switching the revision parsing and listing
over to the array makes things like the builtin-diff usage much simpler
(we now see exactly how many members the array has, and we don't get the
objects reversed from the order they were on the command line).

One of the main reasons for doing this at all is that the malloc overhead
of the simple object list was actually pretty high, and the array is just
a lot denser. So this patch brings down memory usage by git-rev-list by
just under 3% (on top of all the other memory use optimizations) on the
mozilla archive.

It does add more lines than it removes, and more importantly, it adds a
whole new infrastructure for maintaining lists of objects, but on the
other hand, the new dynamic array code is pretty obvious. The change to
builtin-diff-tree.c shows a fairly good example of why an array interface
is sometimes more natural, and just much simpler for everybody.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-19 18:45:48 -07:00
Linus Torvalds
9202434cbd gitweb.cgi history not shown
This does:

 - add a "rev.simplify_history" flag which defaults to on
 - it turns it off for "git whatchanged" (which thus now has real
   semantics outside of "git log")
 - it adds a command line flag ("--full-history") to turn it off for
   others (ie you can make "git log" and "gitk" etc get the semantics if
   you want to.

Now, just as an example of _why_ you really really really want to simplify
history by default, apply this patch, install it, and try these two
command lines:

	gitk --full-history -- git.c
	gitk -- git.c

and compare the output.

So with this, you can also now do

	git whatchanged -p -- gitweb.cgi
	git log -p --full-history -- gitweb.cgi

and it will show the old history of gitweb.cgi, even though it's not
relevant to the _current_ state of the name "gitweb.cgi"

NOTE NOTE NOTE! It will still actually simplify away merges that didn't
change anything at all into either child. That creates these bogus strange
discontinuities if you look at it with "gitk" (look at the --full-history
gitk output for git.c, and you'll see a few strange cases).

So the whole "--parent" thing ends up somewhat bogus with --full-history
because of this, but I'm not sure it's worth even worrying about. I don't
think you'd ever want to really use "--full-history" with the graphical
representation, I just give it as an example exactly to show _why_ doing
so would be insane.

I think this is trivial enough and useful enough to be worth merging into
the stable branch.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-16 22:53:11 -07:00
Johannes Schindelin
20ff06805c format-patch: resurrect extra headers from config
Once again, if you have

	[format]
		headers = "Origamization: EvilEmpire\n"

format-patch will add these headers just after the "Subject:" line.

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-06-02 07:30:55 -07:00
Junio C Hamano
cf2251b604 format-patch --signoff
This resurrects --signoff option to format-patch.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-31 15:11:49 -07:00
Johannes Schindelin
698ce6f87e fmt-patch: Support --attach
This patch touches a couple of files, because it adds options to print a
custom text just after the subject of a commit, and just after the
diffstat.

[jc: made "many dashes" used as the boundary leader into a single
 variable, to reduce the possibility of later tweaks to miscount the
 number of dashes to break it.]

Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-21 02:03:09 -07:00
Johannes Schindelin
596524b33d Teach fmt-patch about --numbered
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-05 14:11:57 -07:00
Junio C Hamano
34e98ea564 Merge branch 'lt/logopt'
* lt/logopt:
  Fix "git log --stat": make sure to set recursive with --stat.
  combine-diff: show diffstat with the first parent.
  git.c: LOGSIZE is unused after log printing cleanup.
  Log message printout cleanups (#3): fix --pretty=oneline
  Log message printout cleanups (#2)
  Log message printout cleanups
  rev-list --header: output format fix
  Fixes for option parsing
  log/whatchanged/show - log formatting cleanup.
  Simplify common default options setup for built-in log family.
  Tentative built-in "git show"
  Built-in git-whatchanged.
  rev-list option parser fix.
  Split init_revisions() out of setup_revisions()
  Fix up rev-list option parsing.
  Fix up default abbrev in setup_revisions() argument parser.
  Common option parsing for "git log --diff" and friends
2006-04-18 13:56:36 -07:00
Linus Torvalds
9153983310 Log message printout cleanups
On Sun, 16 Apr 2006, Junio C Hamano wrote:
>
> In the mid-term, I am hoping we can drop the generate_header()
> callchain _and_ the custom code that formats commit log in-core,
> found in cmd_log_wc().

Ok, this was nastier than expected, just because the dependencies between
the different log-printing stuff were absolutely _everywhere_, but here's
a patch that does exactly that.

The patch is not very easy to read, and the "--patch-with-stat" thing is
still broken (it does not call the "show_log()" thing properly for
merges). That's not a new bug. In the new world order it _should_ do
something like

	if (rev->logopt)
		show_log(rev, rev->logopt, "---\n");

but it doesn't. I haven't looked at the --with-stat logic, so I left it
alone.

That said, this patch removes more lines than it adds, and in particular,
the "cmd_log_wc()" loop is now a very clean:

	while ((commit = get_revision(rev)) != NULL) {
		log_tree_commit(rev, commit);
		free(commit->buffer);
		commit->buffer = NULL;
	}

so it doesn't get much prettier than this. All the complexity is entirely
hidden in log-tree.c, and any code that needs to flush the log literally
just needs to do the "if (rev->logopt) show_log(...)" incantation.

I had to make the combined_diff() logic take a "struct rev_info" instead
of just a "struct diff_options", but that part is pretty clean.

This does change "git whatchanged" from using "diff-tree" as the commit
descriptor to "commit", and I changed one of the tests to reflect that new
reality. Otherwise everything still passes, and my other tests look fine
too.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-17 15:18:25 -07:00
Junio C Hamano
1b65a5aa44 rev-list --boundary: show boundary commits even when limited otherwise.
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>
2006-04-16 22:05:38 -07:00
Junio C Hamano
cb8f64b4e3 log/whatchanged/show - log formatting cleanup.
This moves the decision to print the log message, while diff
options are in effect, to log-tree.  It gives behaviour closer
to the traditional one.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-16 03:35:38 -07:00
Linus Torvalds
ba1d45051e Tentative built-in "git show"
This uses the "--no-walk" flag that I never actually implemented (but I'm
sure I mentioned it) to make "git show" be essentially the same thing as
"git whatchanged --no-walk".

It just refuses to add more interesting parents to the revision walking
history, so you don't actually get any history, you just get the commit
you asked for.

I was going to add "--no-walk" as a real argument flag to git-rev-list
too, but I'm not sure anybody actually needs it. Although it might be
useful for porcelain, so I left the door open.

[jc: ported to the unified option structure by Linus]

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-16 00:13:38 -07:00
Linus Torvalds
cd2bdc5309 Common option parsing for "git log --diff" and friends
This basically does a few things that are sadly somewhat interdependent,
and nontrivial to split out

 - get rid of "struct log_tree_opt"

   The fields in "log_tree_opt" are moved into "struct rev_info", and all
   users of log_tree_opt are changed to use the rev_info struct instead.

 - add the parsing for the log_tree_opt arguments to "setup_revision()"

 - make setup_revision set a flag (revs->diff) if the diff-related
   arguments were used. This allows "git log" to decide whether it wants
   to show diffs or not.

 - make setup_revision() also initialize the diffopt part of rev_info
   (which we had from before, but we just didn't initialize it)

 - make setup_revision() do all the "finishing touches" on it all (it will
   do the proper flag combination logic, and call "diff_setup_done()")

Now, that was the easy and straightforward part.

The slightly more involved part is that some of the programs that want to
use the new-and-improved rev_info parsing don't actually want _commits_,
they may want tree'ish arguments instead. That meant that I had to change
setup_revision() to parse the arguments not into the "revs->commits" list,
but into the "revs->pending_objects" list.

Then, when we do "prepare_revision_walk()", we walk that list, and create
the sorted commit list from there.

This actually cleaned some stuff up, but it's the less obvious part of the
patch, and re-organized the "revision.c" logic somewhat. It actually paves
the way for splitting argument parsing _entirely_ out of "revision.c",
since now the argument parsing really is totally independent of the commit
walking: that didn't use to be true, since there was lots of overlap with
get_commit_reference() handling etc, now the _only_ overlap is the shared
(and trivial) "add_pending_object()" thing.

However, I didn't do that file split, just because I wanted the diff
itself to be smaller, and show the actual changes more clearly. If this
gets accepted, I'll do further cleanups then - that includes the file
split, but also using the new infrastructure to do a nicer "git diff" etc.

Even in this form, it actually ends up removing more lines than it adds.

It's nice to note how simple and straightforward this makes the built-in
"git log" command, even though it continues to support all the diff flags
too. It doesn't get much simpler that this.

I think this is worth merging soonish, because it does allow for future
cleanup and even more sharing of code. However, it obviously touches
"revision.c", which is subtle. I've tested that it passes all the tests we
have, and it passes my "looks sane" detector, but somebody else should
also give it a good look-over.

[jc: squashed the original and three "oops this too" updates, with
 another fix-up.]

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-14 21:56:55 -07:00
Junio C Hamano
c4e05b1a22 blame and friends: adjust to multiple pathspec change.
This makes things that include revision.h build again.

Blame is also built, but I am not sure how well it works (or how
well it worked to begin with) -- it was relying on tree-diff to
be using whatever pathspec was used the last time, which smells
a bit suspicious.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-10 19:17:31 -07:00
Linus Torvalds
3381c790e5 Make "--parents" logs also be incremental
The parent rewriting feature caused us to create the whole history in one
go, and then simplify it later, because of how rewrite_parents() had been
written. However, with a little tweaking, it's perfectly possible to do
even that one incrementally.

Right now, this doesn't really much matter, because every user of
"--parents" will probably generally _also_ use "--topo-order", which will
cause the old non-incremental behaviour anyway. However, I'm hopeful that
we could make even the topological sort incremental, or at least
_partially_ so (for example, make it incremental up to the first merge).

In the meantime, this at least moves things in the right direction, and
removes a strange special case.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-08 23:37:21 -07:00
Linus Torvalds
7b0c996679 Move "--parent" parsing into generic revision.c library code
Not only do we do it in both rev-list.c and git.c, the revision walking
code will soon want to know whether we should rewrite parenthood
information or not.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-31 16:24:48 -08:00
Junio C Hamano
384e99a4a9 rev-list --boundary
With the new --boundary flag, the output from rev-list includes
the UNINTERESING commits at the boundary, which are usually not
shown.  Their object names are prefixed with '-'.

For example, with this graph:

              C side
             /
	A---B---D master

You would get something like this:

	$ git rev-list --boundary --header --parents side..master
	D B
        tree D^{tree}
        parent B
        ... log message for commit D here ...
        \0-B A
        tree B^{tree}
        parent A
        ... log message for commit B here ...
        \0

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-28 17:29:21 -08:00
Fredrik Kuivinen
8efdc326c9 rev-lib: Make it easy to do rename tracking (take 2)
prune_fn in the rev_info structure is called in place of
try_to_simplify_commit. This makes it possible to do rename tracking
with a custom try_to_simplify_commit-like function.

This commit also introduces init_revisions which initialises the rev_info
structure with default values.

Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-10 22:22:00 -08:00
Junio C Hamano
7ae0b0cb65 git-log (internal): more options.
This ports the following options from rev-list based git-log
implementation:

 * -<n>, -n<n>, and -n <n>.  I am still wondering if we want
    this natively supported by setup_revisions(), which already
    takes --max-count.  We may want to move them in the next
    round.  Also I am not sure if we can get away with not
    setting revs->limited when we set max-count.  The latest
    rev-list.c and revision.c in this series do not, so I left
    them as they are.

 * --pretty and --pretty=<fmt>.

 * --abbrev=<n> and --no-abbrev.

The previous commit already handles time-based limiters
(--since, --until and friends).  The remaining things that
rev-list based git-log happens to do are not useful in a pure
log-viewing purposes, and not ported:

 * --bisect (obviously).

 * --header.  I am actually in favor of doing the NUL
   terminated record format, but rev-list based one always
   passed --pretty, which defeated this option.  Maybe next
   round.

 * --parents.  I do not think of a reason a log viewer wants
   this.  The flag is primarily for feeding squashed history
   via pipe to downstream tools.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-01 03:16:34 -08:00
Linus Torvalds
765ac8ec46 Rip out merge-order and make "git log <paths>..." work again.
Well, assuming breaking --merge-order is fine, here's a patch (on top of
the other ones) that makes

	git log <filename>

actually work, as far as I can tell.

I didn't add the logic for --before/--after flags, but that should be
pretty trivial, and is independent of this anyway.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-01 01:45:50 -08:00
Linus Torvalds
a4a88b2bab git-rev-list libification: rev-list walking
This actually moves the "meat" of the revision walking from rev-list.c
to the new library code in revision.h. It introduces the new functions

	void prepare_revision_walk(struct rev_info *revs);
	struct commit *get_revision(struct rev_info *revs);

to prepare and then walk the revisions that we have.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-28 14:49:29 -08:00
Linus Torvalds
d9a83684c4 Splitting rev-list into revisions lib, end of beginning.
This makes the rewrite easier to validate in that revision flag
parsing and warlking part are now all in rev_info structure.

Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-27 11:10:16 -08:00
Linus Torvalds
ae563542bf First cut at libifying revlist generation
This really just splits things up partially, and creates the
interface to set things up by parsing the command line.

No real code changes so far, although the parsing of filenames is a bit
stricter. In particular, if there is a "--", then we do not accept any
filenames before it, and if there isn't any "--", then we check that _all_
paths listed are valid, not just the first one.

The new argument parsing automatically also gives us "--default" and
"--not" handling as in git-rev-parse.

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-26 15:33:27 -08:00
Linus Torvalds
b2c0071867 Include <limits.h> in commit.c for ULONG_MAX. Remove old "revision.h".
The old revision.h helper header isn't used any more, but I never noticed
it until I started grepping for ULONG_MAX users.
2005-04-21 11:21:33 -07:00
Linus Torvalds
08ca0b04ba Make the revision tracking track the object types too.
This allows fsck to verify not just that an object exists, but
also that it has the type it was expected to have.
2005-04-17 16:19:32 -07:00
Linus Torvalds
7d60ad7cc9 Make "parse_commit" return the "struct revision" for the commit.
Also, make it a fatal error to pass in a non-commit object. The callers
never checked, so better check here.

This simplifies merge-base further. It's now so trivial that it's almost
ridiculous.
2005-04-17 12:40:18 -07:00
Linus Torvalds
01796b0e91 Make "revision.h" slightly better to use.
- mark_reachable() can be more generic, marking the reachable revisions
   with an arbitrary mask.
 - date parsing will parse to a date of 0 rather than ULONG_MAX for the
   bad old case, sorting the dates correctly.
2005-04-17 12:07:00 -07:00
Linus Torvalds
89d21f4b64 Move "parse_commit()" into common revision.h file.
This also drops the old-style date parsing. We just don't care
enough, since we dropped that format pretty early.

Yes, this could do with some cleanup, and a common library file.
Some day.
2005-04-17 11:39:18 -07:00
Linus Torvalds
458754a9fe Use common "revision.h" header for both fsck and rev-tree.
It's really a very generic thing: the notion of one sha1 revision
referring to another one. "fsck" uses it for all nodes, and "rev-tree"
only tracks commit-node relationships, but the code was already
the same - now we just make that explicit by moving it to a common
header file.
2005-04-13 21:37:59 -07:00