summaryrefslogtreecommitdiff
path: root/builtin-branch.c
AgeCommit message (Collapse)AuthorFilesLines
2009-12-31Merge branch 'maint-1.6.0' into maintLibravatar Junio C Hamano1-2/+4
* maint-1.6.0: branch: die explicitly why when calling "git branch [-a|-r] branchname".
2009-12-31branch: die explicitly why when calling "git branch [-a|-r] branchname".Libravatar Matthieu Moy1-2/+4
The -a and -r options used to be silently ignored in such a command. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-12-16Merge branch 'maint' to sync with 1.6.5.7Libravatar Junio C Hamano1-1/+3
* maint: Git 1.6.5.7 worktree: don't segfault with an absolute pathspec without a work tree ignore unknown color configuration help.autocorrect: do not run a command if the command given is junk Illustrate "filter" attribute with an example
2009-12-16ignore unknown color configurationLibravatar Jeff King1-1/+3
When parsing the config file, if there is a value that is syntactically correct but unused, we generally ignore it. This lets non-core porcelains store arbitrary information in the config file, and it means that configuration files can be shared between new and old versions of git (the old versions might simply ignore certain configuration). The one exception to this is color configuration; if we encounter a color.{diff,branch,status}.$slot variable, we die if it is not one of the recognized slots (presumably as a safety valve for user misconfiguration). This behavior has existed since 801235c (diff --color: use $GIT_DIR/config, 2006-06-24), but hasn't yet caused a problem. No porcelain has wanted to store extra colors, and we once a color area (like color.diff) has been introduced, we've never changed the set of color slots. However, that changed recently with the addition of color.diff.func. Now a user with color.diff.func in their config can no longer freely switch between v1.6.6 and older versions; the old versions will complain about the existence of the variable. This patch loosens the check to match the rest of git-config; unknown color slots are simply ignored. This doesn't fix this particular problem, as the older version (without this patch) is the problem, but it at least prevents it from happening again in the future. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-19Refactor pretty_print_commit arguments into a structLibravatar Thomas Rast1-1/+2
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>
2009-08-29UI consistency: allow --force for where -f means forceLibravatar René Scharfe1-1/+1
git branch, checkout, clean, mv and tag all have an option -f to override certain checks. This patch makes them accept the long option --force as a synonym. While we're at it, document that checkout support --quiet as synonym for its short option -q. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-24Merge branch 'maint'Libravatar Junio C Hamano1-27/+39
* maint: SunOS grep does not understand -C<n> nor -e Fix export_marks() error handling. git branch: clean up detached branch handling git branch: avoid unnecessary object lookups git branch: fix performance problem do_one_ref(): null_sha1 check is not about broken ref Conflicts: Makefile
2009-07-23git branch: clean up detached branch handlingLibravatar Linus Torvalds1-15/+23
Make the 'show detached branch info' a routine of its own. And in the process, avoid the object lookup that is unnecessary if the current branch isn't detached. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-23git branch: avoid unnecessary object lookupsLibravatar Linus Torvalds1-10/+14
They can be expensive in the cold-cache case, so don't bother looking up the commits for all branches unless we really need them for some reason. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-07-23git branch: fix performance problemLibravatar Linus Torvalds1-5/+5
'git branch' looks at _all_ the refs, and verifies them. Which means that during cold-cache situations with a slow disk (and lots of tags, for example) it can take several very annoying seconds (7.5s according to a report by Carlos R. Mafra). This avoids most of it by simply doing the filtering before looking up the commits, by using the "raw" version of for_each_ref. Reported-by: Carlos R. Mafra <crmafra2@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-25parse-opts: prepare for OPT_FILENAMELibravatar Stephen Boyd1-1/+2
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>
2009-05-09allow -t abbreviation for --track in git branchLibravatar Sitaram Chamarty1-1/+1
also makes it consistent with git-checkout Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-13shorten_unambiguous_ref(): add strict modeLibravatar Bert Wesarg1-2/+2
Add the strict mode of abbreviation to shorten_unambiguous_ref(), i.e. the resulting ref won't trigger the ambiguous ref warning. All users of shorten_unambiguous_ref() still use the loose mode. Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-07branch: show upstream branch when double verboseLibravatar Jeff King1-6/+17
This information is easily accessible when we are calculating the relationship. The only reason not to print it all the time is that it consumes a fair bit of screen space, and may not be of interest to the user. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-04-06Merge branch 'jc/name-branch'Libravatar Junio C Hamano1-14/+18
* jc/name-branch: Don't permit ref/branch names to end with ".lock" check_ref_format(): tighten refname rules strbuf_check_branch_ref(): a helper to check a refname for a branch Fix branch -m @{-1} newname check-ref-format --branch: give Porcelain a way to grok branch shorthand strbuf_branchname(): a wrapper for branch name shorthands Rename interpret/substitute nth_last_branch functions Conflicts: Documentation/git-check-ref-format.txt
2009-03-26Merge branch 'bc/maint-1.6.1-branch-deleted-was'Libravatar Junio C Hamano1-1/+1
* bc/maint-1.6.1-branch-deleted-was: git-branch: display "was sha1" on branch deletion rather than just "sha1" Conflicts: builtin-branch.c
2009-03-24check_ref_format(): tighten refname rulesLibravatar Junio C Hamano1-2/+14
This changes the rules for refnames to forbid: (1) a refname that contains "@{" in it. Some people and foreign SCM converter may have named their branches as frotz@24 and we still want to keep supporting it. However, "git branch frotz@{24}" is a disaster. It cannot even checked out because "git checkout frotz@{24}" will interpret it as "detach the HEAD at twenty-fourth reflog entry of the frotz branch". (2) a refname that ends with a dot. We already reject a path component that begins with a dot, primarily to avoid ambiguous range interpretation. If we allowed ".B" as a valid ref, it is unclear if "A...B" means "in dot-B but not in A" or "either in A or B but not in both". But for this to be complete, we need also to forbid "A." to avoid "in B but not in A-dot". This was not a problem in the original range notation, but we should have added this restriction when three-dot notation was introduced. Unlike "no dot at the beginning of any path component" rule, this rule does not have to be "no dot at the end of any path component", because you cannot abbreviate the tail end away, similar to you can say "dot-B" to mean "refs/heads/dot-B". For these reasons, it is not likely people created branches with these names on purpose, but we have allowed such names to be used for quite some time, and it is possible that people created such branches by mistake or by accident. To help people with branches with such unfortunate names to recover, we still allow "branch -d 'bad.'" to delete such branches, and also allow "branch -m bad. good" to rename them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22strbuf_check_branch_ref(): a helper to check a refname for a branchLibravatar Junio C Hamano1-6/+2
This allows a common calling sequence strbuf_branchname(&ref, name); strbuf_splice(&ref, 0, 0, "refs/heads/", 11); if (check_ref_format(ref.buf)) die(...); to be refactored into if (strbuf_check_branch_ref(&ref, name)) die(...); Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22Fix branch -m @{-1} newnameLibravatar Junio C Hamano1-7/+7
The command is supposed to rename the branch we were on before switched from to a new name, but was not aware of the short-hand notation we added recently. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22strbuf_branchname(): a wrapper for branch name shorthandsLibravatar Junio C Hamano1-5/+1
The function takes a user-supplied string that is supposed to be a branch name, and puts it in a strbuf after expanding possible shorthand notation. A handful of open coded sequence to do this in the existing code have been changed to use this helper function. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-22Rename interpret/substitute nth_last_branch functionsLibravatar Junio C Hamano1-1/+1
These allow you to say "git checkout @{-2}" to switch to the branch two "branch switching" ago by pretending as if you typed the name of that branch. As it is likely that we will be introducing more short-hands to write the name of a branch without writing it explicitly, rename the functions from "nth_last_branch" to more generic "branch_name", to prepare for different semantics. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-21git-branch: display "was sha1" on branch deletion rather than just "sha1"Libravatar Brandon Casey1-1/+1
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>
2009-03-05Merge branch 'js/branch-symref'Libravatar Junio C Hamano1-32/+79
* js/branch-symref: add basic branch display tests branch: clean up repeated strlen Avoid segfault with 'git branch' when the HEAD is detached builtin-branch: improve output when displaying remote branches Conflicts: builtin-branch.c
2009-03-05Merge branch 'al/ansi-color'Libravatar Junio C Hamano1-21/+21
* al/ansi-color: builtin-branch.c: Rename branch category color names Clean up use of ANSI color sequences
2009-02-18branch: clean up repeated strlenLibravatar Jeff King1-2/+2
Commit 45e2b61 fixed the initialization of a "len" struct parameter via strlen. We can use that to clean up what is now 3 strlens in a 6-line sequence. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-18Avoid segfault with 'git branch' when the HEAD is detachedLibravatar Johannes Schindelin1-0/+2
A recent addition to the ref_item struct was not taken care of, leading to a segmentation fault when accessing the (uninitialized) "dest" member. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-13Teach the "@{-1} syntax to "git branch"Libravatar Junio C Hamano1-12/+19
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>
2009-02-13builtin-branch.c: Rename branch category color namesLibravatar Arjen Laarhoven1-16/+16
The branch color constants have the form COLOR_BRANCH_$category. Rename them to BRANCH_COLOR_$category as this conveys their meaning better. Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-13Clean up use of ANSI color sequencesLibravatar Arjen Laarhoven1-5/+5
Remove the literal ANSI escape sequences and replace them by readable constants. Signed-off-by: Arjen Laarhoven <arjen@yaph.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-13builtin-branch: improve output when displaying remote branchesLibravatar Jay Soffian1-30/+75
When encountering a symref (typically refs/remotes/<remote>/HEAD), display the ref target. When displaying local and remote branches, prefix the remote branch names with "remotes/" to make the remote branches clear from the local branches. If displaying only the remote branches, the prefix is not shown since it would be redundant. Sample output: $ git branch foo -> master * master rather-long-branch-name $ git branch -v foo -> master * master 51cecb2 initial rather-long-branch-name 51cecb2 initial $ git branch -v --no-abbrev foo -> master * master 51cecb2dbb1a1902bb4df79b543c8f951ee59d83 initial rather-long-branch-name 51cecb2dbb1a1902bb4df79b543c8f951ee59d83 initial $ git branch -r frotz/HEAD -> frotz/master frotz/master origin/HEAD -> origin/master origin/UNUSUAL -> refs/heads/master origin/master $ git branch -a foo -> master * master rather-long-branch-name remotes/frotz/HEAD -> frotz/master remotes/frotz/master remotes/origin/HEAD -> origin/master remotes/origin/UNUSUAL -> refs/heads/master remotes/origin/master $ git branch -rv frotz/HEAD -> frotz/master frotz/master e1d8130 added file2 origin/HEAD -> origin/master origin/UNUSUAL -> refs/heads/master origin/master e1d8130 added file2 $ git branch -av foo -> master * master 51cecb2 initial rather-long-branch-name 51cecb2 initial remotes/frotz/HEAD -> frotz/master remotes/frotz/master e1d8130 added file2 remotes/origin/HEAD -> origin/master remotes/origin/UNUSUAL -> refs/heads/master remotes/origin/master e1d8130 added file2 Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-28Make has_commit() non-staticLibravatar Jake Goulding1-17/+3
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>
2009-01-28Make opt_parse_with_commit() non-staticLibravatar Jake Goulding1-18/+2
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>
2008-12-12git-branch: display sha1 on branch deletionLibravatar Brandon Casey1-1/+2
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>
2008-11-18builtin-branch: use strbuf in rename_branch()Libravatar Miklos Vajna1-18/+21
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>
2008-11-18builtin-branch: use strbuf in fill_tracking_info()Libravatar Miklos Vajna1-10/+8
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>
2008-11-18builtin-branch: use strbuf in delete_branches()Libravatar Miklos Vajna1-4/+4
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>
2008-11-05Merge branch 'mv/maint-branch-m-symref'Libravatar Junio C Hamano1-1/+1
* 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.
2008-10-26Fix git branch -m for symrefs.Libravatar Miklos Vajna1-1/+1
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>
2008-10-12Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializerLibravatar Brandon Casey1-2/+1
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>
2008-07-27builtin-branch: fix -v for --[no-]mergedLibravatar Lars Hjemli1-0/+15
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>
2008-07-27builtin-branch: factor out merge_filter matchingLibravatar Lars Hjemli1-5/+13
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>
2008-07-27builtin-branch: remove duplicated codeLibravatar Lars Hjemli1-7/+2
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>
2008-07-23builtin-branch.c: optimize --merged and --no-mergedLibravatar Junio C Hamano1-21/+38
"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>
2008-07-23builtin-branch.c: remove unused code in append_ref() callback functionLibravatar Junio C Hamano1-7/+3
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>
2008-07-16Merge branch 'sb/dashless'Libravatar Junio C Hamano1-4/+4
* 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
2008-07-14Merge branch 'jc/branch-merged'Libravatar Junio C Hamano1-12/+50
* jc/branch-merged: branch --merged/--no-merged: allow specifying arbitrary commit branch --contains: default to HEAD parse-options: add PARSE_OPT_LASTARG_DEFAULT flag Conflicts: Documentation/git-branch.txt
2008-07-13Make usage strings dash-lessLibravatar Stephan Beyer1-4/+4
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>
2008-07-09branch --merged/--no-merged: allow specifying arbitrary commitLibravatar Junio C Hamano1-8/+42
"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>
2008-07-09branch --contains: default to HEADLibravatar Junio C Hamano1-4/+8
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>
2008-07-06branch -r -v: do not spit out garbageLibravatar Junio C Hamano1-3/+2
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>