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>
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>
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>
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>
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>
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>
Recent diff_tree_setup_paths() update made it take a second
argument of type "struct diff_options", but we passed another
struct that happenes to have that type at the beginning by
mistake.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I've merged everything I think is ready for 1.3.0, so this is
the final round -- hopefully I can release this with minimum
last-minute fixup as v1.3.0 early next week.
Signed-off-by: Junio 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: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I noticed bisect does not work well without both good and bad.
Running this script in git.git repository would give you quite
different results:
#!/bin/sh
initial=e83c5163316f89bfbde7d9ab23ca2e25604af290
mid0=`git rev-list --bisect ^$initial --all`
git rev-list $mid0 | wc -l
git rev-list ^$mid0 --all | wc -l
mid1=`git rev-list --bisect --all`
git rev-list $mid1 | wc -l
git rev-list ^$mid1 --all | wc -l
The $initial commit is the very first commit you made. The
first midpoint bisects things evenly as designed, but the latter
does not.
The reason I got interested in this was because I was wondering
if something like the following would help people converting a
huge repository from foreign SCM, or preparing a repository to
be fetched over plain dumb HTTP only:
#!/bin/sh
N=4
P=.git/objects/pack
bottom=
while test 0 \< $N
do
N=$((N-1))
if test -z "$bottom"
then
newbottom=`git rev-list --bisect --all`
else
newbottom=`git rev-list --bisect ^$bottom --all`
fi
if test -z "$bottom"
then
rev_list="$newbottom"
elif test 0 = $N
then
rev_list="^$bottom --all"
else
rev_list="^$bottom $newbottom"
fi
p=$(git rev-list --unpacked --objects $rev_list |
git pack-objects $P/pack)
git show-index <$P/pack-$p.idx | wc -l
bottom=$newbottom
done
The idea is to pack older half of the history to one pack, then
older half of the remaining history to another, to continue a
few times, using finer granularity as we get closer to the tip.
This may not matter, since for a truly huge history, running
bisect number of times could be quite time consuming, and we
might be better off running "git rev-list --all" once into a
temporary file, and manually pick cut-off points from the
resulting list of commits. After all we are talking about
"approximately half" for such an usage, and older history does
not matter much.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Partly because we've messed up and now have some commits with trailing
whitespace, but partly because this also just simplifies the code, let's
remove trailing whitespace from the end when pretty-printing commits.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Noticed by Johannes. We do not install it anymore, but still have
been shipping the source, which was crazy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes f4ee3eb689 breakage, which
added an extra trailing blank line after stripping trailing blank lines
by mistake.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Relying on eye-candy progress bar was fragile to begin with.
Run fetch-pack with -k option, and count the objects that are in
the pack that were transferred from the other end.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The regexp on the right hand side of expr : operator somehow was
broken.
expr 'z+pu:refs/tags/ko-pu' : 'z\+\(.*\)'
does not strip '+'; write 'z+\(.*\)' instead.
We probably should switch to shell based substring post 1.3.0;
that's not bashism but just POSIX anyway.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now, you can say "git diff --stat" (to get an idea how many changes are
uncommitted), or "git log --stat".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some words, e.g., `match', are special to expr(1), and cause strange
parsing effects. Track down all uses of expr and mangle the arguments
so that this isn't a problem.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When running t3600-rm test under fakeroot (or as root), we
cannot make a file unremovable with "chmod a-w .". Detect this
case early and skip that test.
Signed-off-by: Junio C Hamano <junkio@cox.net>
