This adds an option to help scripts find out color settings from
the configuration file.
git config --get-colorbool color.diff
inspects color.diff variable, and exits with status 0 (i.e. success) if
color is to be used. It exits with status 1 otherwise.
If a script wants "true"/"false" answer to the standard output of the
command, it can pass an additional boolean parameter to its command
line, telling if its standard output is a terminal, like this:
git config --get-colorbool color.diff true
When called like this, the command outputs "true" to its standard output
if color is to be used (i.e. "color.diff" says "always", "auto", or
"true"), and "false" otherwise.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches git-branch to limit its listing to branches that
are descendants to the named commit.
When you are using many topic branches, you often would want to
see which branch already includes a commit, so that you know
which can and cannot be rewound without disrupting other people.
One thing that sometimes happens to me is:
* Somebody sends a patch that is a good maint material. I
apply it to 'maint':
$ git checkout maint
$ git am -3 -s obvious-fix.patch
* Then somebody else sends another patch that is possibly a
good maint material, but I'd want to cook it in 'next' to be
extra sure. I fork a topic from 'maint' and apply the patch:
$ git checkout -b xx/maint-fix-foo
$ git am -3 -s ,xx-maint-fix-foo.patch
* A minor typo is found in the "obvious-fix.patch".
The above happens without pushing the results out, so I can
freely recover from it by amending 'maint', as long as I do not
forget to rebase the topics that were forked previously.
With this patch, I can do this to find out which topic
branches already contain the faulty commit:
$ git branch --contains=maint^
xx/maint-fix-foo
so I can rebase the xx/maint-fix-foo branch before merging it
to 'next'.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/format-patch-encoding:
test format-patch -s: make sure MIME content type is shown as needed
format-patch -s: add MIME encoding header if signer's name requires so
The term "ancestor" is a bit more intuitive (and more consistent with
the documentation) than the term "strict subset".
Also, remove superfluous "ref", capitalize, and add some carriage
returns, changing:
error: remote 'refs/heads/master' is not a strict subset of local ref 'refs/heads/master'. maybe you are not up-to-date and need to pull first?
error: failed to push to 'ssh://linux-nfs.org/~bfields/exports/git.git'
to:
error: remote 'refs/heads/master' is not an ancestor of
local 'refs/heads/master'.
Maybe you are not up-to-date and need to pull first?
error: failed to push to 'ssh://linux-nfs.org/~bfields/exports/git.git'
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
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>
This patch cleans up some complicated code, and replaces it with a
cleaner version, using code from remote.[ch], which got extended a
little in the process. This also enables us to fix two cases:
The earlier "fix" to setup tracking only when the original ref started
with "refs/remotes" is wrong. You are absolutely allowed to use a
separate layout for your tracking branches. The correct fix, of course,
is to set up tracking information only when there is a matching
remote.<nick>.fetch line containing a colon.
Another corner case was not handled properly. If two remotes write to
the original ref, just warn the user and do not set up tracking.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio noticed that switching on autosetupmerge unilaterally started
cluttering the config for local branches. That is not the original
intention of branch.autosetupmerge, which was meant purely for
convenience when branching off of remote branches, but that semantics
got lost somewhere.
If you still want that "new" behavior, you can switch
branch.autosetupmerge to the value "all". Otherwise, it is interpreted
as a boolean, which triggers setting up defaults _only_ when branching
off of a remote branch, i.e. the originally intended behavior.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git branch --track" will setup config variables when branching from
a remote branch, so that if you say "git pull" while being on that
branch, it automatically fetches the correct remote, and merges the
correct branch.
Often people complain that this is not the default for "git branch".
Make it so.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
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>
The original code did not take hierarchical branch names into account at all.
Tested-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
annotate: make it work from subdirectories.
git-config: Correct asciidoc documentation for --int/--bool
t1300: Add tests for git-config --bool --get
unpack-trees.c: verify_uptodate: remove dead code
Use PATH_MAX instead of TEMPFILE_PATH_LEN
branch: fix segfault when resolving an invalid HEAD
Caused by return value of resolve_ref being passed directly
to xstrdup whereby the sanity checking was never reached.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-checkout is also adapted to make use of this new option
instead of the handcrafted command sequence.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This moves the knowledge about .git/config usage out of refs.c and into
builtin-branch.c instead, which allows git-branch to update HEAD to point
at the moved branch before attempting to update the config file. It also
allows git-branch to exit with an error code if updating the config file
should fail.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds support for a dummy remote '.' to avoid having
to declare a fake remote like
[remote "local"]
url = .
fetch = refs/heads/*:refs/heads/*
Such a builtin remote simplifies the operation of "git-fetch",
which will populate FETCH_HEAD but will not pretend that two
repositories are in use, will not create a thin pack, and will
not perform any useless remapping of names. The speed
improvement is around 20%, and it should improve more if
"git-fetch" is converted to a builtin.
To this end, git-parse-remote is grown with a new kind of
remote, 'builtin'. In git-fetch.sh, we treat the builtin remote
specially in that it needs no pack/store operations. In fact,
doing git-fetch on a builtin remote will simply populate
FETCH_HEAD appropriately.
The patch also improves of the --track/--no-track support,
extending it so that branch.<name>.remote items referring '.'
can be created. Finally, it fixes a typo in git-checkout.sh.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In order to track and build on top of a branch 'topic' you track from
your upstream repository, you often would end up doing this sequence:
git checkout -b mytopic origin/topic
git config --add branch.mytopic.remote origin
git config --add branch.mytopic.merge refs/heads/topic
This would first fork your own 'mytopic' branch from the 'topic'
branch you track from the 'origin' repository; then it would set up two
configuration variables so that 'git pull' without parameters does the
right thing while you are on your own 'mytopic' branch.
This commit adds a --track option to git-branch, so that "git
branch --track mytopic origin/topic" performs the latter two actions
when creating your 'mytopic' branch.
If the configuration variable branch.autosetupmerge is set to true, you
do not have to pass the --track option explicitly; further patches in
this series allow setting the variable with a "git remote add" option.
The configuration variable is off by default, and there is a --no-track
option to countermand it even if the variable is set.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
git-branch has an --abbrev= command line option, but it does
no checking of the input. Take the argument parsing code from
setup_revisions in revisions.c, and also the code for parsing
the --no-abbrev option.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
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>
This is to resolve conflicts early in preparation for possible
inclusion of "reflog on detached HEAD" series by Nico, as having
it in 1.5.0 would really help us remove confusion between
detached and attached states.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Even when -l is not given from the command line, the repository
may have the configuration variable core.logallrefupdates set,
or an old-timer might have done ": >.git/logs/refs/heads/new"
before running "git branch new". In these cases, the code gave
an uninitialized msg[] from the stack to be written out as the
reflog message.
This also passes a different message when '-f' option is used.
Saying "git branch -f branch some-commit" is a moral equilvalent
of doing "git-reset some-commit" while on the branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Back when only handful commands that created commit and tag were
the only users of committer identity information, it made sense
to explicitly call setup_ident() to pre-fill the default value
from the gecos information. But it is much simpler for programs
to make the call automatic when get_ident() is called these days,
since many more programs want to use the information when updating
the reflog.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The internal function in_merge_bases(A, B) is used to make sure
that commit A is an ancestor of commit B. This changes the
signature of it to take an array of B's and updates its current
callers.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows "git checkout v1.4.3" to dissociate the HEAD of
repository from any branch. After this point, "git branch"
starts reporting that you are not on any branch. You can go
back to an existing branch by saying "git checkout master", for
example.
This is still experimental. While I think it makes sense to
allow commits on top of detached HEAD, it is rather dangerous
unless you are careful in the current form. Next "git checkout
master" will obviously lose what you have done, so we might want
to require "git checkout -f" out of a detached HEAD if we find
that the HEAD commit is not an ancestor of any other branches.
There is no such safety valve implemented right now.
On the other hand, the reason the user did not start the ad-hoc
work on a new branch with "git checkout -b" was probably because
the work was of a throw-away nature, so the convenience of not
having that safety valve might be even better. The user, after
accumulating some commits on top of a detached HEAD, can always
create a new branch with "git checkout -b" not to lose useful
work done while the HEAD was detached.
We'll see.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes git-branch show a detached HEAD as '* (no branch)'.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This moves the guts of print_ref_list() into a revamped print_ref_info(),
which at the same time gets renamed to print_ref_item().
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added color.branch and color.branch.<slot> to configuration list.
Style copied from color.status and meanings derived from the code.
Moved the color meanings from color.diff.<slot> to color.branch.<slot>
since the latter comes first alphabetically.
Added --color and --no-color to git-branch's usage and documentation.
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>
If there are more than one branches to be deleted, failure on
one will no longer stop git-branch to process the next ones.
The command still reports failures by exitting non-zero status.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because -r already means "remote" when listing, you can say:
$ git branch -d -r origin/todo origin/html origin/man
I just twisted it not to check fast-forwardness with the current
branch when you are removing a tracking branch. Most likely,
removal of a tracking branch is not because you are "done with"
it (for a local branch, it usually means "you merged it up"),
but because you are not even interested in it. In other words,
remote tracking branches are more like tags than branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* lh/branch-rename:
git-branch: let caller specify logmsg
rename_ref: use lstat(2) when testing for symlink
git-branch: add options and tests for branch renaming
Conflicts:
builtin-branch.c
Showing local and remote branches in green and red was simply
overkill, as all we wanted was to make it easy to tell them
apart (local ones can be built on top by committing, but the
remote tracking ones can't).
Use plain coloring for local branches and paint remotes in red.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I wanted to have a visual indication of which branches are local and
which are remote in git-branch -a output; however Junio was concerned
that someone might be using the output in a script. This patch
addresses the problem by colouring the git-branch output - which in
"auto" mode won't be activated.
I've based it off the colouring code for builtin-diff.c; which means
there is a branch color configuration variable that needs setting to
something before the color will appear.
The colour parameter is "color.branch" rather than "branch.color" to
avoid clashing with the default namespace for default branch merge
definitions.
This patch chooses green for local, red for remote and bold green for
current.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the signature of rename_ref() in refs.[hc] to include a
logmessage for the reflogs.
Also, builtin-branch.c is modified to provide a proper logmessage + call
setup_ident() before any logmessages are written.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Extend git-branch with the following options:
git-branch -m|-M [<oldbranch>] newbranch
The -M variation is required to force renaming over an exsisting
branchname.
This also indroduces $GIT_DIR/RENAME_REF which is a "metabranch"
used when renaming branches. It will always hold the original sha1
for the latest renamed branch.
Additionally, if $GIT_DIR/logs/RENAME_REF exists, all branch rename
events are logged there.
Finally, some testcases are added to verify the new options.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes "git branch -D other_branch" work even when HEAD
points at a yet-to-be-born branch.
Earlier, we checked the HEAD ref for the purpose of "subset"
check even when the deletion was forced (i.e. not -d but -D).
Because of this, you cannot delete a branch even with -D while
on a yet-to-be-born branch.
With this change, the following sequence that now works:
mkdir newdir && cd newdir
git init-db
git fetch -k $other_repo refs/heads/master:refs/heads/othre
# oops, typo
git branch other othre
git branch -D othre
Signed-off-by: Junio C Hamano <junkio@cox.net>
