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: Junio 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: Junio 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: Junio 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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio 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: Serge E. Hallyn <serue@us.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Config_filename and lockfile are strduped and then leaked in
git_config_set_multivar.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Signed-off-by: Junio 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: Serge E. Hallyn <serue@us.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Mod_type in particular sure looks like it wants to be used, but isn't.
Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Signed-off-by: Junio 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: Serge E. Hallyn <serue@us.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/boundary:
rev-list --boundary: show boundary commits even when limited otherwise.
Makefile fixups.
gitk: Fix bug caused by missing commitlisted elements
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>
It appears the fingerprinting itself is too expensive to be worth doing
for this purpose. A failed experiment.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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: Paul Mackerras <paulus@samba.org>
Previously, if we switched away from a view before we had finished
reading the git-rev-list output for it and laying out the graph, we
would discard the partially-laid-out graph and reread it from
scratch if we switched back to the view. With this, we preserve the
state of the partially-laid-out graph in viewdata($view) and restore
it if we switch back. The pipe to git-rev-list remains open but we
just don't read from it any more until we switch back to that view.
This also makes linesegends a list rather than an array, which turns
out to be slightly faster, as well as being easier to save and restore.
The `update' menu item now kills the git-rev-list process if there is
one still running when we do the update.
Signed-off-by: Paul 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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio 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: Junio C Hamano <junkio@cox.net>
* master:
pager: do not fork a pager if PAGER is set to empty.
diff-options: add --patch-with-stat
diff-files --stat: do not dump core with unmerged index.
Support "git cmd --help" syntax
diff --stat: do not do its own three-dashes.
diff-tree: typefix.
GIT v1.3.0-rc4
xdiff: post-process hunks to make them consistent.
Unless the user has a nonstandard "cat" command that does not
meow like a cat, this should not break anything and would save an
extra pipe.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This skips an extra pipe, and helps debugging tremendously.
[jc: PAGER=cat is a questionable hack and should be done as a separate
patch. ]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio 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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio 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: Junio C Hamano <junkio@cox.net>
The big option parser unification broke rev-list the big way;
this makes it use options from the parsed revs structure.
Signed-off-by: Junio 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: Junio C Hamano <junkio@cox.net>
* js/diffstat:
diff-options: add --patch-with-stat
diff-files --stat: do not dump core with unmerged index.
Support "git cmd --help" syntax
diff --stat: do not do its own three-dashes.
With this option, git prepends a diffstat in front of the patch.
Since I really, really do not know what a diffstat of a combined diff
("merge diff") should look like, the diffstat is not generated for these.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio 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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio 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.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio 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: Junio C Hamano <junkio@cox.net>
* jc/logopt: (37 commits)
1fc70b6
Author: Junio C Hamano <junkio@cox.net>
Date: Sat Apr 15 04:15:07 2006 -0700
Built-in git-whatchanged
Now "git log" is in reusable shape, add "git whatchanged" which
essentially is a synonym with different default for people whose
fingers are already trained.
There is a subtle difference from the shell-script version; the
first line of each entry is now "commit <object name>", instead
of "diff-tree <object name> (from <object name>)." I suspect
that showing the parent name that way is useful, so this may be
something we would want to fix (the user can say --pretty=raw to
get that information but that is a bit ugly).
Signed-off-by: Junio C Hamano <junkio@cox.net>
:100644 100644 22fec3d... 939a34c... M git.c
...
Now "git log" is in reusable shape, add "git whatchanged" which
essentially is a synonym with different default for people whose
fingers are already trained.
There is a subtle difference from the shell-script version; the
first line of each entry is now "commit <object name>", instead
of "diff-tree <object name> (from <object name>)." I suspect
that showing the parent name that way is useful, so this may be
something we would want to fix (the user can say --pretty=raw to
get that information but that is a bit ugly).
Signed-off-by: Junio C Hamano <junkio@cox.net>
We need to have two sets of diff_options structure and abbrev
settings, but there is no point having two separate commit
format setting. Fix the confusion.
Also properly initialize the command options structure.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Merging of the log-tree-opt structure with rev-info structure
did not work out very well and it broke things that did not want
diff options and/or rev options.
This is an alternative approach to define a combined interface
that can be used by commands that wants both. The use of it is
opt-in to reduce the risk of breaking existing programs.
We might want to slurp "setup_revisions() places things in
pending objects list" part from Linus's earlier attempt.
Signed-off-by: Junio C Hamano <junkio@cox.net>
