Call it "git diff" not "git diffn", remove the shell script
version, and hardlink the git binary to it.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This starts to replace the shell script version of "git diff".
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When I split out the builtin commands into their own files, I left the
include of <sys/ioctl.h> in git.c rather than moving it to the file that
needed it (builtin-help.c).

Nobody seems to have noticed, because everything still worked, but because
the TIOCGWINSZ macro was now no longer defined when compiling the
"term_columns()" function, it would no longer automatically notice the
terminal size unless your system used the ancient "COLUMNS" environment
variable approach.

Trivially fixed by just moving the header include to the file that
actually needs it.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Right now it split it into "builtin-log.c" for log-related commands
("log", "show" and "whatchanged"), and "builtin-help.c" for the
informational commands (usage printing and "help" and "version").

This just makes things easier to read, I find.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
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>

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>

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>

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>

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>

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

Split internal "git log" into reusable piece and add "git
whatchanged".  This is based on the option parsing unification
work Linus did.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Merging all three option parsers related to whatchanged is
unarguably the right thing, but the fallout was too big to scare
me away.  Let's try it once again, but once step at time.

This splits out init_revisions() call from setup_revisions(), so
that the callers can set different defaults to match the
traditional benaviour.

The rev-list command is still broken in a big way, which is the
topic of next step.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The "--help" argument is special, in that it is (along with "--version")
in that is taken by the "git" program itself rather than the sub-command,
and thus we've had the syntax "git --help cmd".

However, as anybody who has ever used CVS or some similar devil-spawn
program, it's confusing as h*ll when options before the sub-command act
differently from options after the sub-command, so this quick hack just
makes it acceptable to do "git cmd --help" instead, and get the exact same
result.

It may be hacky, but it's simple and does the trick.

Of course, this does not help if you use one of the non-builtin commands
without using the "git" helper. Ie you won't be getting a man-page just
because you do "git-rev-list --help". Don't expect us to be quite _that_
helpful.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

I missed that "git-diff-* --stat" spits out three-dash separator
on its own without being asked.  Remove it.

When we output commit log followed by diff, perhaps --patch-with-stat,
for downstream consumer, we _would_ want the three-dash between
the message and the diff material, but that logic belongs to the
caller, not diff generator.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The default abbreviation precision should be DEFAULT_ABBREV as before.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

This trivially avoids keeping the commit message data around after we
don't need it any more, avoiding a continually growing "git log" memory
footprint.

It's not a huge deal, but it's somewhat noticeable. For the current kernel
tree, doing a full "git log" I got

 - before: /usr/bin/time git log > /dev/null
	0.81user 0.02system 0:00.84elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
	0inputs+0outputs (0major+8851minor)pagefaults 0swaps

 - after: /usr/bin/time git log > /dev/null
	0.79user 0.03system 0:00.83elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
	0inputs+0outputs (0major+5039minor)pagefaults 0swaps

ie the touched pages dropped from 8851 to 5039. For the historic kernel
archive, the numbers are 18357->11037 minor page faults.

We could/should in theory free the commits themselves, but that's really a
lot harder, since during revision traversal we may hit the same commit
twice through different children having it as a parent, even after we've
shown it once (when that happens, we'll silently ignore it next time, but
we still need the "struct commit" to know).

And as the commit message data is clearly the biggest part of the commit,
this is the really easy 60% solution.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

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

Without this flag, "git log -p paths..." shows commits that
touch the specified paths, and diffs about the same specified
paths.  With this, the full diff is shown for commits that touch
the specified paths.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

And this makes "git log" to take common diff-tree options, so
that it can be used as "git whatchanged".

The recent revision walker updates by Linus to make path
limiting low-latency helps this quite a bit.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

[jc: with suggestions by Jan-Benedict Glaw]
Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

Mark Wooding noticed there was a type mismatch warning in git.c; this
patch does things slightly differently (mostly tightening const) and
was what I was holding onto, waiting for the setup-revisions change
to be merged into the master branch.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This moves the handling of max-count shorthand from the internal
implementation of "git log" to setup_revisions() so other users
of setup_revisions() can use it.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

This is what the previous diffs all built up to.

We can do "git log" as a trivial small helper function inside git.c,
because the infrastructure is all there for us to use as a library.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is another patch in the "prepare to do more in C" series, where the
git wrapper command is taught about the notion of handling some
functionality internally.

Right now, the only internal commands are "version" and "help", but the
point being that we can now easily extend it to handle some of the trivial
scripts internally. Things like "git log" and "git diff" wouldn't need
separate external scripts any more.

This also implies that to support the old "git-log" and "git-diff" syntax,
the "git" wrapper now automatically looks at the name it was executed as,
and if it is "git-xxxx", it will assume that it is to internally do what
"git xxxx" would do.

In other words, you can (once you implement an internal command) soft- or
hard-link that command to the "git" wrapper command, and it will do the
right thing, whether you use the "git xxxx" or the "git-xxxx" format.

There's one other change: the search order for external programs is
modified slightly, so that the first entry remains GIT_EXEC_DIR, but the
second entry is the same directory as the git wrapper itself was executed
out of - if we can figure it out from argv[0], of course.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The git suite may not be in PATH (and thus programs such as
git-send-pack could not exec git-rev-list).  Thus there is a need for
logic that will locate these programs.  Modifying PATH is not
desirable as it result in behavior differing from the user's
intentions, as we may end up prepending "/usr/bin" to PATH.

- git C programs will use exec*_git_cmd() APIs to exec sub-commands.
- exec*_git_cmd() will execute a git program by searching for it in
  the following directories:
	1. --exec-path (as used by "git")
	2. The GIT_EXEC_PATH environment variable.
	3. $(gitexecdir) as set in Makefile (default value $(bindir)).
- git wrapper will modify PATH as before to enable shell scripts to
  invoke "git-foo" commands.

Ideally, shell scripts should use the git wrapper to become independent
of PATH, and then modifying PATH will not be necessary.

[jc: with minor updates after a brief review.]
Signed-off-by: NMichal Ostrowski <mostrows@watson.ibm.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Most other scm's understand it, most users expect it and it's an easy fix.
Signed-off-by: NAndreas Ericsson <ae@op5.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

fprintf and die sometimes have missing/excessive "\n" in their arguments,
correct the strings where I think it would be appropriate.
Signed-off-by: NAlex Riesen <raa.lkml@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This changes "pretty_print_string_list()" to show the git commands
alphabetically in column order, which is the normal one.

Ie instead of doing

	git commands available in '/home/torvalds/bin'
	----------------------------------------------
	  add                am                 ...
	  applypatch         archimport         ...
	  cat-file           check-ref-format   ...
	...

it does

	git commands available in '/home/torvalds/bin'
	----------------------------------------------
	  add                diff-tree          ...
	  am                 fetch              ...
	  apply              fetch-pack         ...
	...

where each column is sorted.

This is how "ls" sorts things too, and since visually the columns are much
more distinct than the rows, so it _looks_ more sorted.

The "ls" command has a "-x" option that lists entries by lines (the way
git.c used to): if somebody wants to do that, the new print-out logic
could be easily accomodated to that too. Matter of taste and preference, I
guess.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Currently the git "show commands" function will react to the environment
variable COLUMNS, or just default to a width of 80 characters.

That's just soo eighties. Nobody sane sets COLUMNS any more, unless they
need to support some stone-age software from before the age of steam
engines, SIGWINCH and TIOCGWINSZ.

So get with the new century, and use TIOCGWINSZ to get the terminal size.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This attempts to clean up the way various compatibility
functions are defined and used.

 - A new header file, git-compat-util.h, is introduced.  This
   looks at various NO_XXX and does necessary function name
   replacements, equivalent of -Dstrcasestr=gitstrcasestr in the
   Makefile.

 - Those function name replacements are removed from the Makefile.

 - Common features such as usage(), die(), xmalloc() are moved
   from cache.h to git-compat-util.h; cache.h includes
   git-compat-util.h itself.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When the given command name was too long, we exited with a
message with the number of bytes of the final command name
inside parentheses, without saying what that number is.  It was
only meant as a debugging aid while development, so remove it.
Signed-off-by: NJunio C Hamano <junkio@cox.net>