Make it more pleasant to read about a branch deletion by adding "was".
Jeff King suggested this, and I ignored it. He was right.
Update t3200 test again to match the change in output.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches the new "@{-1} syntax to refer to the previous branch to "git
branch". After looking at somebody's faulty patch series on a topic
branch too long, if you decide it is not worth merging, you can just say:
$ git checkout master
$ git branch -D @{-1}
to get rid of it without having to type the name of the topic you now hate
so much for wasting a lot of your time.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move has_commit() from branch to a common location, in preparation for
using it in "git-tag". Rename it to is_descendant_of() to make it more
unique and descriptive.
Signed-off-by: Jake Goulding <goulding@vivisimo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Moving opt_parse_with_commit() from branch to a common location, in
preparation for using it in tag. Rename it to match naming convention
of other option parsing functions.
Signed-off-by: Jake Goulding <goulding@vivisimo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it easier to recover from a mistaken branch deletion by displaying the
sha1 of the branch's tip commit.
Update t3200 test to match the change in output.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In case the length of branch name is greather then PATH_MAX-11, we write
to unallocated memory otherwise.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is just about using the API, though in case of ~ 10^100 commits,
this would fix the problem of writing to unallocated memory as well. ;-)
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In case the length of branch name is greather then PATH_MAX-7, we write
to unallocated memory otherwise.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mv/maint-branch-m-symref:
update-ref --no-deref -d: handle the case when the pointed ref is packed
git branch -m: forbid renaming of a symref
Fix git update-ref --no-deref -d.
rename_ref(): handle the case when the reflog of a ref does not exist
Fix git branch -m for symrefs.
This had two problems with symrefs. First, it copied the actual sha1
instead of the "pointer", second it failed to remove the old ref after a
successful rename.
Given that till now delete_ref() always dereferenced symrefs, a new
parameters has been introduced to delete_ref() to allow deleting refs
without a dereference.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
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>
After the optimization to --[no-]merged logic, the calculation of the
width of the longest refname to be shown might become inaccurate (since
the matching against merge_filter is performed after adding refs to
ref_list). This patch forces a recalculation of maxwidth when it might
be needed.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The logic for checking commits against merge_filter will be reused
when we recalculate the maxwidth of refnames.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous optimization to --[no-]merged ended up with some duplicated
code which this patch removes.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git branch --no-merged $commit" used to compute the merge base between
the tip of each and every branch with the named $commit, but this was
wasteful when you have many branches. Inside append_ref() we literally
ran has_commit() between the tip of the branch and the merge_filter_ref.
Instead, we can let the revision machinery traverse the history as if we
are running:
$ git rev-list --branches --not $commit
by queueing the tips of branches we encounter as positive refs (this
mimicks the "--branches" option in the above command line) and then
appending the merge_filter_ref commit as a negative one, and finally
calling prepare_revision_walk() to limit the list..
After the traversal is done, branch tips that are reachable from $commit
are painted UNINTERESTING; they are already fully contained in $commit
(i.e. --merged). Tips that are not painted UNINTERESTING still have
commits that are not reachable from $commit, thus "--no-merged" will show
them.
With an artificial repository that has "master" and 1000 test-$i branches
where they were created by "git branch test-$i master~$i":
(with patch)
$ /usr/bin/time git-branch --no-merged master >/dev/null
0.12user 0.02system 0:00.15elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1588minor)pagefaults 0swaps
$ /usr/bin/time git-branch --no-merged test-200 >/dev/null
0.15user 0.03system 0:00.18elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+1711minor)pagefaults 0swaps
(without patch)
$ /usr/bin/time git-branch --no-merged master >/dev/null
0.69user 0.03system 0:00.72elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2229minor)pagefaults 0swaps
$ /usr/bin/time git-branch --no-merged test-200 >/dev/null
0.58user 0.03system 0:00.61elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+2248minor)pagefaults 0swaps
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We let for_each_ref() to feed all refs to append_ref() but we are only
ever interested in local or remote tracking branches.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sb/dashless:
Make usage strings dash-less
t/: Use "test_must_fail git" instead of "! git"
t/test-lib.sh: exit with small negagive int is ok with test_must_fail
Conflicts:
builtin-blame.c
builtin-mailinfo.c
builtin-mailsplit.c
builtin-shortlog.c
git-am.sh
t/t4150-am.sh
t/t4200-rerere.sh
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>
"git-branch --merged" is a handy way to list all the branches that have
already been merged to the current branch, but it did not allow checking
against anything but the current branch. Having to switch branches only
to list the branches that are merged with another branch made the feature
practically useless.
This updates the option parser so that "git branch --merged next" is
accepted when you are on 'master' branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to require the name of the commit to limit the branches shown to
the --contains option, but more recent --merged/--no-meregd defaults to
HEAD (and they do not allow arbitrary commit, which is a separate issue).
This teaches --contains to default to HEAD when no parameter is given.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The codepath to emit relationship between the branch and what it tracks
forgot to initialize a string buffer stat[] to empty when showing a
tracking branch. This moves the emptying so that the buffer starts as
empty and stays so when no information is added to fix this issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches "git branch -v" to insert the remote tracking statistics in
brackets, just before the one-liner commit log message for the branch.
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>
These options filter the output from git branch to only include branches
whose tip is either merged or not merged into HEAD.
The use-case for these options is when working with integration of branches
from many remotes: `git branch --no-merged -a` will show a nice list of merge
candidates while `git branch --merged -a` will show the progress of your
integration work.
Also, a plain `git branch --merged` is a quick way to find local branches
which you might want to delete.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* db/checkout: (21 commits)
checkout: error out when index is unmerged even with -m
checkout: show progress when checkout takes long time while switching branches
Add merge-subtree back
checkout: updates to tracking report
builtin-checkout.c: Remove unused prefix arguments in switch_branches path
checkout: work from a subdirectory
checkout: tone down the "forked status" diagnostic messages
Clean up reporting differences on branch switch
builtin-checkout.c: fix possible usage segfault
checkout: notice when the switched branch is behind or forked
Build in checkout
Move code to clean up after a branch change to branch.c
Library function to check for unmerged index entries
Use diff -u instead of diff in t7201
Move create_branch into a library file
Build-in merge-recursive
Add "skip_unmerged" option to unpack_trees.
Discard "deleted" cache entries after using them to update the working tree
Send unpack-trees debugging output to stderr
Add flag to make unpack_trees() not print errors.
...
Conflicts:
Makefile
This change removes all obvious useless if-before-free tests.
E.g., it replaces code like this:
if (some_expression)
free (some_expression);
with the now-equivalent:
free (some_expression);
It is equivalent not just because POSIX has required free(NULL)
to work for a long time, but simply because it has worked for
so long that no reasonable porting target fails the test.
Here's some evidence from nearly 1.5 years ago:
http://www.winehq.org/pipermail/wine-patches/2006-October/031544.html
FYI, the change below was prepared by running the following:
git ls-files -z | xargs -0 \
perl -0x3b -pi -e \
's/\bif\s*\(\s*(\S+?)(?:\s*!=\s*NULL)?\s*\)\s+(free\s*\(\s*\1\s*\))/$2/s'
Note however, that it doesn't handle brace-enclosed blocks like
"if (x) { free (x); }". But that's ok, since there were none like
that in git sources.
Beware: if you do use the above snippet, note that it can
produce syntactically invalid C code. That happens when the
affected "if"-statement has a matching "else".
E.g., it would transform this
if (x)
free (x);
else
foo ();
into this:
free (x);
else
foo ();
There were none of those here, either.
If you're interested in automating detection of the useless
tests, you might like the useless-if-before-free script in gnulib:
[it *does* detect brace-enclosed free statements, and has a --name=S
option to make it detect free-like functions with different names]
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=blob;f=build-aux/useless-if-before-free
Addendum:
Remove one more (in imap-send.c), spotted by Jean-Luc Herren <jlh@gmx.ch>.
Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git branch" and "git checkout -b" now honor --track option even when
the upstream branch is local. Previously --track was silently ignored
when forking from a local branch. Also the command did not error out
when --track was explicitly asked for but the forked point specified
was not an existing branch (i.e. when there is no way to set up the
tracking configuration), but now it correctly does.
The configuration setting branch.autosetupmerge can now be set to
"always", which is equivalent to using --track from the command line.
Setting branch.autosetupmerge to "true" will retain the former behavior
of only setting up branch.*.merge for remote upstream branches.
Includes test cases for the new functionality.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
You can also create branches, in exactly the same way, with checkout -b.
This introduces branch.{c,h} library files for doing porcelain-level
operations on branches (such as creating them with their appropriate
default configuration).
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
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>
