* maint:
  pre-commit hook: complain about conflict markers.
  git-merge: a bit more readable user guidance.

Now I am not doing any real "git-diff in C" yet, but this would
help before doing so.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Several <<< or === or >>> characters at the beginning of a line
is very likely to be leftover conflict markers from a failed
automerge the user resolved incorrectly, so detect them.

As usual, this can be defeated with "git commit --no-verify" if
you really do want to have those files, just like changes that
introduce trailing whitespaces.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We said "fix up by hand" after failed automerge, which was a big
"Huh?  Now what?".  Be a bit more explicit without being too
verbose. Suggested by Carl Worth.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

I personally prefer "ignore_merges" to be on by default, because quite
often the merge diff is distracting and not interesting. That's true both
with "-p" and with "--stat" output.

If you want output from merges, you can trivially use the "-m", "-c" or
"--cc" flags to tell that you're interested in merges, which also tells
the diff generator what kind of diff to do (for --stat, any of the three
will do, of course, but they differ for plain patches or for
--patch-with-stat).

This trivial patch just removes the two lines that tells "git log" not to
ignore merges. It will still show the commit log message, of course, due
to the "always_show_header" part.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

.. but don't even bother documenting it. I don't think any normal person
is supposed to ever really care, but it simplifies testing when you want
to use the "git repack" wrapper rather than forcing you to use the core
programs (which already do support the window/depth arguments, of course).
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* fix:
  Document git-clone --reference
  Fix filename scaling for binary files

When I unified the revision argument parsing, I introduced a simple bug
wrt tags that had been marked uninteresting. When it was preparing for the
revision walk, it would mark all the parent commits of an uninteresting
tag correctly uninteresting, but it would forget about the commit itself.

This means that when I just did my 2.6.17-rc2 release, and my scripts
generated the log for "v2.6.17-rc1..v2.6.17-rc2", everything was fine,
except the commit pointed to by 2.6.17-rc1 (which shouldn't have been
there) was included. Even though it should obviously have been marked as
being uninteresting.

Not a huge deal, and the fix is trivial.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The new --reference flag introduced to git-clone in
GIT 1.3.0 was not documented but is rather handy.
So document it.

Also corrected a minor issue with the documentation for the
-s flag; the info/alternates file name was spelled wrong.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Set maximum filename length for binary files so that scaling won't be
triggered and result in invalid string access.
Signed-off-by: NJonas Fonseca <fonseca@diku.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/pager-cat:
  Do not fork PAGER=cat

* 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

Signed-off-by: NJunio C Hamano <junkio@cox.net>

[jc: with entries in git.txt]
Signed-off-by: NJonas Fonseca <fonseca@diku.dk>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Just like "patch" format always needs recursive, "diffstat"
format does not make sense without setting recursive.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Just like "patch" format always needs recursive, "diffstat"
format does not make sense without setting recursive.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

added svn:special symlink support for access methods other than
direct-http
Signed-off-by: NHerbert Valerio Riedel <hvr@gnu.org>
Acked-by: NMatthias Urlichs <smurf@smurf.noris.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Asking for stat (either with --stat or --patch-with-stat) gives
you diffstat for the first parent, even under combine-diff.

While the combined patch is useful to highlight the complexity
and interaction of the parts touched by all branches when
reviewing a merge commit, diffstat is a tool to assess the
extent of damage the merge brings in, and showing stat with the
first parent is more sensible than clever per-parent diffstat.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

This option is very special, since pretty_print_commit() will _remove_
the newline at the end of it, so we want to have an extra separator
between the things.

I added a honking big comment this time, so that (a) I don't forget this
_again_ (I broke "oneline" several times during this printout cleanup),
and so that people can understand _why_ the code does what it does.

Now, arguably the alternate fix is to always have the '\n' at the end in
pretty-print-commit, but git-rev-list depends on the current behaviour
(but we could have git-rev-list remove it, whatever).

With the big comment, the code hopefully doesn't get broken again. And now
things like

	git log --pretty=oneline --cc --patch-with-stat

works (even if that is admittedly a totally insane combination: if you
want the patch, having the "oneline" log format is just crazy, but hey,
it _works_. Even insane people are people).
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Here's a further patch on top of the previous one with cosmetic
improvements (no "real" code changes, just trivial updates):

 - it gets the "---" before a diffstat right, including for the combined
   merge case. Righ now the logic is that we always use "---" when we have
   a diffstat, and an empty line otherwise. That's how I visually prefer
   it, but hey, it can be tweaked later.

 - I made "diff --cc/combined" add the "---/+++" header lines too. The
   thing won't be mistaken for a valid diff, since the "@@" lines have too
   many "@" characters (three or more), but it just makes it visually
   match a real diff, which at least to me makes a big difference in
   readability. Without them, it just looks very "wrong".

   I guess I should have taken the filename from each individual entry
   (and had one "---" file per parent), but I didn't even bother to try to
   see how that works, so this was the simple thing.

With this, doing a

	git log --cc --patch-with-stat

looks quite readable, I think. The only nagging issue - as far as I'm
concerned - is that diffstats for merges are pretty questionable the way
they are done now. I suspect it would be better to just have the _first_
diffstat, and always make the merge diffstat be the one for "result
against first parent".
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Serge E. Hallyn noticed that we compute how many input bytes are
still left, but did not use it for sanity checking.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Not sure whether it should be removed, or whether
execv_git_cmd() should return it rather than -1 at bottom.
Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Config_filename and lockfile are strduped and then leaked in
git_config_set_multivar.
Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The switch is inside an if statement which is false if
the character is ' '.  Either the if should be <=' '
instead of <' ', or the case should be removed as it could
be misleading.
Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Mod_type in particular sure looks like it wants to be used, but isn't.
Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The strncmp for ACK was ACK does not include the final space.
Presumably either we should either remove the trailing space,
or compare 4 chars (as this patch does).

'path' is sometimes strdup'ed, but never freed.
Signed-off-by: NSerge E. Hallyn <serue@us.ibm.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/boundary:
  rev-list --boundary: show boundary commits even when limited otherwise.

* jc/bottomless:
  rev-list --bisect: limit list before bisecting.

In addition to the existing comment support, that just allows the user
to use a convention that works pretty much everywhere else.
Signed-off-by: NYann Dirson <ydirson@altern.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Initial fix prepared by Johannes, but I did it slightly differently.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NA Large Angry SCM <gitzilla@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* git://git.kernel.org/pub/scm/gitk/gitk:
  gitk: Fix bug caused by missing commitlisted elements

This bug was reported by Yann Dirson, and results in an 'Error:
expected boolean value but got ""' dialog when scrolling to the bottom
of the graph under some circumstances.  The issue is that git-rev-list
isn't outputting all the boundary commits when it is asked for commits
affecting only certain files.  We already cope with that by adding the
missing boundary commits in addextraid, but there we weren't adding a
0 to the end of the commitlisted list when we added the extra id to
the end of the displayorder list.

This fixes it by appending 0 to commitlisted in addextraid, thus keeping
commitlisted and displayorder in sync.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

Make sure "git show" always show the header, regardless of whether there
is a diff or not.

Also, make sure "always_show_header" actually works, since generate_header
only tested it in one out of three return paths.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Noticed by Yann Dirson.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>