This shrinks the top-level directory a bit, and makes it much more
pleasant to use auto-completion on the thing. Instead of
[torvalds@nehalem git]$ em buil<tab>
Display all 180 possibilities? (y or n)
[torvalds@nehalem git]$ em builtin-sh
builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c
builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o
[torvalds@nehalem git]$ em builtin-shor<tab>
builtin-shortlog.c builtin-shortlog.o
[torvalds@nehalem git]$ em builtin-shortlog.c
you get
[torvalds@nehalem git]$ em buil<tab> [type]
builtin/ builtin.h
[torvalds@nehalem git]$ em builtin [auto-completes to]
[torvalds@nehalem git]$ em builtin/sh<tab> [type]
shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o
[torvalds@nehalem git]$ em builtin/sho [auto-completes to]
[torvalds@nehalem git]$ em builtin/shor<tab> [type]
shortlog.c shortlog.o
[torvalds@nehalem git]$ em builtin/shortlog.c
which doesn't seem all that different, but not having that annoying
break in "Display all 180 possibilities?" is quite a relief.
NOTE! If you do this in a clean tree (no object files etc), or using an
editor that has auto-completion rules that ignores '*.o' files, you
won't see that annoying 'Display all 180 possibilities?' message - it
will just show the choices instead. I think bash has some cut-off
around 100 choices or something.
So the reason I see this is that I'm using an odd editory, and thus
don't have the rules to cut down on auto-completion. But you can
simulate that by using 'ls' instead, or something similar.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make git-branch, git-show-branch, git-grep, and all the diff-based
programs accept an optional argument <when> for --color. The argument
is a colorbool: "always", "never", or "auto". If no argument is given,
"always" is used; --no-color is an alias for --color=never. This makes
the command-line interface consistent with other GNU tools, such as `ls'
and `grep', and with the git-config color options. Note that, without
an argument, --color and --no-color work exactly as before.
To implement this, two internal changes were made:
1. Allow the first argument of git_config_colorbool() to be NULL,
in which case it returns -1 if the argument isn't "always", "never",
or "auto".
2. Add OPT_COLOR_FLAG(), OPT__COLOR(), and parse_opt_color_flag_cb()
to the option parsing library. The callback uses
git_config_colorbool(), so color.h is now a dependency
of parse-options.c.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty_print_commit() has a bunch of rarely-used arguments, and
introducing more of them requires yet another update of all the call
sites. Refactor most of them into a struct to make future extensions
easier.
The ones that stay "plain" arguments were chosen on the grounds that
all callers put real arguments there, whereas some callers have 0/NULL
for all arguments that were factored into the struct.
We declare the struct 'const' to ensure none of the callers are bitten
by the changed (no longer call-by-value) semantics.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running "git show-branch" without any parameter in a repository that
has showbranch.default defined, we used to rely on the fact that our
handcrafted option parsing loop never looked at av[0].
The array of default strings had the first real command line argument in
default_arg[0], but the option parser wanted to look at the array starting
at av[1], so we assigned the address of -1th element to av to force the
loop start working from default_arg[0].
This no longer worked since 5734365 (show-branch: migrate to parse-options
API, 2009-05-21), as parse_options_start() saved the incoming &av[0] in
its ctx->out and later in parse_options_end() it did memmove to ctx->out
(with ctx->cpidx == 0), overwriting the memory before default_arg[] array.
I am not sure if this is a bug in parse_options(), or a bug in the caller,
and tonight I do not have enough concentration to figure out which. In
any case, this patch works the issue around.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, the documentation suggests that 'git merge-base -a' and 'git
show-branch --merge-base' are equivalent (in fact it claims that the
former cannot handle more than two revs).
Alas, the handling of more than two revs is very different. Document
this by tests and correct the documentation to reflect this.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make sure that usage strings and documentation coincide with each other
and with the actual code.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
5734365 (show-branch: migrate to parse-options API 2009-05-21)
incorrectly set the --more option's flags to be
PARSE_OPT_LASTARG_DEFAULT and PARSE_OPT_OPTARG. These two flags
shouldn't be used together. An option taking a default should just set
the default value desired and parse options will take care of the rest.
Update the header comment to better convey this information.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Acked-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To give OPT_FILENAME the prefix, we pass the prefix to parse_options()
which passes the prefix to parse_options_start() which sets the prefix
member of parse_opts_ctx accordingly. If there isn't a prefix in the
calling context, passing NULL will suffice.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Note that "-g" no longer uses an equals '=' sign for its optional
arguments, but "--reflog" still does. This is normal behavior for parse
options, as arguments to "-g" are put immediately after the option with
no space.
For example
git show-branch -g=4
is now
git show-branch -g4
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 76a44c5 (show-branch --reflog: show the reflog message at the
top, 2007-01-19) introduced parse_reflog_param(). The die() call was
incorrectly passed arg + 9, when it should have been passed arg.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it possible to color the status character ('*' '!' '+' '-') of each
commit corresponding to the branch it's in. This makes it easier to
follow a particular branch, especially if there are larger gaps in the
output.
Add the config option color.showbranch and the command line options
--color and --no-color to control the colored output.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many call sites use strbuf_init(&foo, 0) to initialize local
strbuf variable "foo" which has not been accessed since its
declaration. These can be replaced with a static initialization
using the STRBUF_INIT macro which is just as readable, saves a
function call, and takes up fewer lines.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When you misuse a git command, you are shown the usage string.
But this is currently shown in the dashed form. So if you just
copy what you see, it will not work, when the dashed form
is no longer supported.
This patch makes git commands show the dash-less version.
For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh
generates a dash-less usage string now.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code assumed that there always is the current branch, but the result
from resolve_ref() on detached HEAD does not even start with "refs/heads/".
Originally noticed and fixed by Stephan Beyer.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git_config() only had a function parameter, but no callback data
parameter. This assumes that all callback functions only modify
global variables.
With this patch, every callback gets a void * parameter, and it is hoped
that this will help the libification effort.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the body of the commit log message contains a non-ASCII character,
format-patch correctly emitted the encoding header to mark the resulting
message as such. However, if the original message was fully ASCII, the
command line switch "-s" was given to add a new sign-off, and
the signer's name was not ASCII only, the resulting message would have
contained non-ASCII character but was not marked as such.
This was cherry-picked from the fix in 'master'
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the body of the commit log message contains a non-ASCII character,
format-patch correctly emitted the encoding header to mark the resulting
message as such. However, if the original message was fully ASCII, the
command line switch "-s" was given to add a new sign-off, and
the signer's name was not ASCII only, the resulting message would have
contained non-ASCII character but was not marked as such.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also remove the "len" parameter, as:
(1) it was used as a max boundary, and every caller used ~0u
(2) we check for final NUL no matter what, so it doesn't help for speed.
As a result most of the pp_* function takes 3 arguments less, and we need
a lot less local variables, this makes the code way more readable, and
easier to extend if needed.
This patch also fixes some spacing and cosmetic issues.
This patch also fixes (as a side effect) a memory leak intoruced in
builtin-archive.c at commit df4a394f (fmt was xmalloc'ed and not free'd)
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Traditionally we had 16kB limit when formatting log messages for
output, because it was easier to arrange for the caller to have
a reasonably big buffer and pass it down without ever worrying
about reallocating.
This changes the calling convention of pretty_print_commit() to
lift this limit. Instead of the buffer and remaining length, it
now takes a pointer to the pointer that points at the allocated
buffer, and another pointer to the location that stores the
allocated length, and reallocates the buffer as necessary.
To support the user format, the error return of interpolate()
needed to be changed. It used to return a bool telling "Ok the
result fits", or "Sorry, I had to truncate it". Now it returns
0 on success, and returns the size of the buffer it wants in
order to fit the whole result.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We shouldn't attempt to assign constant strings into char*, as the
string is not writable at runtime. Likewise we should always be
treating unsigned values as unsigned values, not as signed values.
Most of these are very straightforward. The only exception is the
(unnecessary) xstrdup/free in builtin-branch.c for the detached
head case. Since this is a user-level interactive type program
and that particular code path is executed no more than once, I feel
that the extra xstrdup call is well worth the easy elimination of
this warning.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There were instances of strncmp() that were formatted improperly
(e.g. whitespace around parameter before closing parenthesis)
that caused the earlier mechanical conversion step to miss
them. This step cleans them up.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previous step converted use of strncmp() with literal string
mechanically even when the result is only used as a boolean:
if (!strncmp("foo", arg, 3)) ==> if (!(-prefixcmp(arg, "foo")))
This step manually cleans them up to read:
if (!prefixcmp(arg, "foo"))
Signed-off-by: Junio C Hamano <junkio@cox.net>
This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily. Leftover from this will be fixed in a separate step, including
idiotic conversions like
if (!strncmp("foo", arg, 3))
=>
if (!(-prefixcmp(arg, "foo")))
This was done by using this script in px.perl
#!/usr/bin/perl -i.bak -p
if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
}
if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
}
and running:
$ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now we have a separate reflog on HEAD, show-branch -g without an explicit
parameter defaults to the current branch, or HEAD when it is detached
from branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
A short-hand "-g" for "git log --walk-reflogs" and "git
show-branch --reflog" makes it easier to access the reflog
info.
[jc: added -g to show-branch for symmetry]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Branch has "-r" for remote branches and "-a" for local and remote.
It seems logical to mirror that in show-branch. Also removes the
dubiously useful "--tags" option (as part of changing the meaning
for "--all").
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a mechanical clean-up of the way *.c files include
system header files.
(1) sources under compat/, platform sha-1 implementations, and
xdelta code are exempt from the following rules;
(2) the first #include must be "git-compat-util.h" or one of
our own header file that includes it first (e.g. config.h,
builtin.h, pkt-line.h);
(3) system headers that are included in "git-compat-util.h"
need not be included in individual C source files.
(4) "git-compat-util.h" does not have to include subsystem
specific header files (e.g. expat.h).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This was lost in the packed-ref updates. The original test was a bit
dubious, so I cleaned that up, too. It fixes the case when the current HEAD
is refs/heads/bla/master: the original test was true for both bla/master
_and_ master.
However, it shares a hard-to-fix bug with the original test: if the current
HEAD is refs/heads/master, and there is a branch refs/heads/heads/master,
then both are marked active.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds a "int *flag" parameter to resolve_ref() and makes
for_each_ref() family to call callback function with an extra
"int flag" parameter. They are used to give two bits of
information (REF_ISSYMREF and REF_ISPACKED) about the ref.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a long overdue fix to the API for for_each_ref() family
of functions. It allows the callers to specify a callback data
pointer, so that the caller does not have to use static
variables to communicate with the callback funciton.
The updated for_each_ref() family takes a function of type
int (*fn)(const char *, const unsigned char *, void *)
and a void pointer as parameters, and calls the function with
the name of the ref and its SHA-1 with the caller-supplied void
pointer as parameters.
The commit updates two callers, builtin-name-rev.c and
builtin-pack-refs.c as an example.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The old code used to totally mix up the notion of a ref-name and the path
that that ref was associated with. That was not only horribly ugly (a
number of users got the path, and then wanted to try to turn it back into
a ref-name again), but it fundamnetally doesn't work at all once we do any
setup where a ref doesn't have a 1:1 relationship with a particular
pathname.
This fixes things up so that we use the ref-name throughout, and only
turn it into a pathname once we actually look it up in the filesystem.
That makes a lot of things much clearer and more straightforward.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Like xmalloc and xrealloc xstrdup dies with a useful message if
the native strdup() implementation returns NULL rather than a
valid pointer.
I just tried to use xstrdup in new code and found it to be missing.
However I expected it to be present as xmalloc and xrealloc are
already commonly used throughout the code.
[jc: removed the part that deals with last_XXX, which I am
finding more and more dubious these days.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Introduces global inline:
hashcmp(const unsigned char *sha1, const unsigned char *sha2)
Uses memcmp for comparison and returns the result based on the length of
the hash name (a future runtime decision).
Acked-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
[jc: I needed to hand merge the changes to the updated codebase,
so the result needs to be checked.]
Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the calling convention of built-in commands and
passes the "prefix" (i.e. pathname of $PWD relative to the
project root level) down to them.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When naming commits, stop walking the parent chain as soon as we find
a commit that already has a name. The parent chain of that commit will
be walked later on in any case (or may even have been walked already).
This avoids O(n^2) behavior; on a tree where show-branch displays 6800
commits, the total run time drops from 77 seconds to 5 seconds.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The core function used in show-branch, join_revs(), was supposed
to be exactly the same algorithm as merge_bases(), except that
it was a version enhanced for use with more than two heads.
However, it needed to mark and keep a list of all the commits it
has seen, because it needed them for its semi-graphical output.
The function to implement this list, mark_seen(), stupidly used
insert_by_date(), when it did not need to keep the list sorted
during its processing. This made "show-branch --merge-base"
more than 20x slower compared to "merge-base --all" in some
cases (e.g. between b5032a5 and 48ce8b0 in the Linux 2.6 kernel
archive). The performance of "show-branch --independent"
suffered from the same reason.
This patch sorts the resulting list after the list traversal
just once to fix these problems.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Every single user actually wanted this only for commit objects, and we
have no reason to waste space on it for other object types. So just move
the structure member from the low-level "struct object" into the "struct
commit".
This leaves the commit object the same size, and removes one unnecessary
pointer from all other object allocations.
This shrinks memory usage (still at a fairly hefty half-gig, admittedly)
of "git-rev-list --all --objects" on the mozilla repo by another 5% in my
tests.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This shrinks "struct object" by a small amount, by getting rid of the
"struct type *" pointer and replacing it with a 3-bit bitfield instead.
In addition, we merge the bitfields and the "flags" field, which
incidentally should also remove a useless 4-byte padding from the object
when in 64-bit mode.
Now, our "struct object" is still too damn large, but it's now less
obviously bloated, and of the remaining fields, only the "util" (which is
not used by most things) is clearly something that should be eventually
discarded.
This shrinks the "git-rev-list --all" memory use by about 2.5% on the
kernel archive (and, perhaps more importantly, on the larger mozilla
archive). That may not sound like much, but I suspect it's more on a
64-bit platform.
There are other remaining inefficiencies (the parent lists, for example,
probably have horrible malloc overhead), but this was pretty obvious.
Most of the patch is just changing the comparison of the "type" pointer
from one of the constant string pointers to the appropriate new TYPE_xxx
small integer constant.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Tay Ray Chuan