summaryrefslogtreecommitdiff
path: root/Documentation/git-branch.txt
AgeCommit message (Collapse)AuthorFilesLines
2019-03-07Merge branch 'du/branch-show-current'Libravatar Junio C Hamano1-1/+5
"git branch" learned a new subcommand "--show-current". * du/branch-show-current: branch: introduce --show-current display option
2019-01-23doc: tidy asciidoc styleLibravatar Jean-Noël Avila1-4/+4
This mainly refers to enforcing indentation on additional lines of items of lists. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-26branch: introduce --show-current display optionLibravatar Daniels Umanovskis1-1/+5
When called with --show-current, git branch will print the current branch name and terminate. Only the actual name gets printed, without refs/heads. In detached HEAD state, nothing is output. Intended both for scripting and interactive/informative use. Unlike git branch --list, no filtering is needed to just get the branch name. Signed-off-by: Daniels Umanovskis <daniels@umanovskis.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-17Merge branch 'jk/branch-l-1-repurpose'Libravatar Junio C Hamano1-7/+2
Updated plan to repurpose the "-l" option to "git branch". * jk/branch-l-1-repurpose: doc/git-branch: remove obsolete "-l" references branch: make "-l" a synonym for "--list"
2018-08-30doc/git-branch: remove obsolete "-l" referencesLibravatar Jeff King1-5/+1
The previous commit switched "-l" to meaning "--list", but a few vestiges of its prior meaning as "--create-reflog" remained: - the synopsis mentioned "-l" when creating a new branch; we can drop this entirely, as it has been the default for years - the --list command mentions the unfortunate "-l" confusion, but we've now fixed that Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-16branch: support configuring --sort via .gitconfigLibravatar Samuel Maftoul1-2/+3
Add support for configuring default sort ordering for git branches. Command line option will override this configured value, using the exact same syntax. Signed-off-by: Samuel Maftoul <samuel.maftoul@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-22branch: make "-l" a synonym for "--list"Libravatar Jeff King1-2/+1
The other "mode" options of git-branch have short-option aliases that are easy to type (e.g., "-d" and "-m"). Let's give "--list" the same treatment. This also makes it consistent with the similar "git tag -l" option. We didn't do this originally because "--create-reflog" was squatting on the "-l" option. Now that we've deprecated that use for long enough, we can make the switch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-22branch: deprecate "-l" optionLibravatar Jeff King1-1/+2
The "-l" option is short for "--create-reflog". This has caused much confusion over the years. Most people expect it to work as "--list", because that would match the other "mode" options like -d/--delete and -m/--move, as well as the similar -l/--list option of git-tag. Adding to the confusion, using "-l" _appears_ to work as "--list" in some cases: $ git branch -l * master because the branch command defaults to listing (so even trying to specify --list in the command above is redundant). But that may bite the user later when they add a pattern, like: $ git branch -l foo which does not return an empty list, but in fact creates a new branch (with a reflog, naturally) called "foo". It's also probably quite uncommon for people to actually use "-l" to create a reflog. Since 0bee591869 (Enable reflogs by default in any repository with a working directory., 2006-12-14), this is the default in non-bare repositories. So it's rather unfortunate that the feature squats on the short-and-sweet "-l" (which was only added in 3a4b3f269c (Create/delete branch ref logs., 2006-05-19), meaning there were only 7 months where it was actually useful). Let's deprecate "-l" in hopes of eventually re-purposing it to "--list". Note that we issue the warning only when we're not in list mode. This means that people for whom it works as a happy accident, namely: $ git branch -l master won't see the warning at all. And when we eventually switch to it meaning "--list", that will just continue to work. We do the issue the warning for these important cases: - when we are actually creating a branch, in case the user really did mean it as "--create-reflog" - when we are in some _other_ mode, like deletion. There the "-l" is a noop for now, but it will eventually conflict with any other mode request, and the user should be told that this is changing. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-02doc: keep first level section header in upper caseLibravatar Nguyễn Thái Ngọc Duy1-2/+2
When formatted as a man page, 1st section header is always in upper case even if we write it otherwise. Make all 1st section headers uppercase to keep it close to the final output. This does affect html since case is kept there, but I still think it's a good idea to maintain a consistent style for 1st section headers. Some sections perhaps should become second sections instead, where case is kept, and for better organization. I will update if anyone has suggestions about this. While at there I also make some header more consistent (e.g. examples vs example) and fix a couple minor things here and there. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-06Merge branch 'tz/branch-doc-remove-set-upstream'Libravatar Junio C Hamano1-2/+2
"git branch --set-upstream" has been deprecated and (sort of) removed, as "--set-upstream-to" is the preferred one these days. The documentation still had "--set-upstream" listed on its synopsys section, which has been corrected. * tz/branch-doc-remove-set-upstream: branch doc: remove --set-upstream from synopsis
2017-11-28Merge branch 'ma/branch-list-paginate'Libravatar Junio C Hamano1-0/+6
"git branch --list" learned to show its output through the pager by default when the output is going to a terminal, which is controlled by the pager.branch configuration variable. This is similar to a recent change to "git tag --list". * ma/branch-list-paginate: branch: change default of `pager.branch` to "on" branch: respect `pager.branch` in list-mode only t7006: add tests for how git branch paginates
2017-11-20branch: change default of `pager.branch` to "on"Libravatar Martin Ågren1-1/+1
This is similar to ff1e72483 (tag: change default of `pager.tag` to "on", 2017-08-02) and is safe now that we do not consider `pager.branch` at all when we are not listing branches. This change will help with listing many branches, but will not hurt users of `git branch --edit-description` as it would have before the previous commit. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-20branch: respect `pager.branch` in list-mode onlyLibravatar Martin Ågren1-0/+6
Similar to de121ffe5 (tag: respect `pager.tag` in list-mode only, 2017-08-02), use the DELAY_PAGER_CONFIG-mechanism to only respect `pager.branch` when we are listing branches. We have two possibilities of generalizing what that earlier commit made to `git tag`. One is to interpret, e.g., --set-upstream-to as "it does not use an editor, so we should page". Another, the one taken by this commit, is to say "it does not list, so let's not page". That is in line with the approach of the series on `pager.tag` and in particular the wording in Documentation/git-tag.txt, which this commit reuses for git-branch.txt. This fixes the failing test added in the previous commit. Also adapt the test for whether `git branch --set-upstream-to` respects `pager.branch`. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-17branch doc: remove --set-upstream from synopsisLibravatar Todd Zullinger1-2/+2
Support for the --set-upstream option was removed in 52668846ea (builtin/branch: stop supporting the "--set-upstream" option, 2017-08-17), after a long deprecation period. Remove the option from the command synopsis for consistency. Replace another reference to it in the description of `--delete` with `--set-upstream-to`. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-19Merge branch 'jc/branch-force-doc-readability-fix'Libravatar Junio C Hamano1-2/+2
Doc update. * jc/branch-force-doc-readability-fix: branch doc: sprinkle a few commas for readability
2017-10-18branch doc: sprinkle a few commas for readabilityLibravatar Junio C Hamano1-2/+2
The "--force" option can also be used when the named branch does not yet exist, and the point of the option is the user can (re)point the branch to the named commit even if it does. Add 'even' before 'if' to clarify. Also, insert another comma after "Without -f" before "the command refuses..." to make the text easier to parse. Incidentally, this change should help certain versions of docbook-xsl-stylesheets that render the original without any whitespace between "-f" and "git". Noticed-by: Lars Schneider <larsxschneider@gmail.com> Helped-by: Jeff King <peff@peff.net> Helped-by: Andreas Schwab <schwab@suse.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-03Merge branch 'sd/branch-copy'Libravatar Junio C Hamano1-1/+13
"git branch" learned "-c/-C" to create a new branch by copying an existing one. * sd/branch-copy: branch: fix "copy" to never touch HEAD branch: add a --copy (-c) option to go with --move (-m) branch: add test for -m renaming multiple config sections config: create a function to format section headers
2017-09-28Merge branch 'ks/doc-use-camelcase-for-config-name'Libravatar Junio C Hamano1-2/+2
Doc update. * ks/doc-use-camelcase-for-config-name: doc: camelCase the config variables to improve readability
2017-09-25doc: camelCase the config variables to improve readabilityLibravatar Kaartic Sivaraam1-2/+2
References to multi-word configuration variable names in our documentation must consistently use camelCase to highlight where the word boundaries are, even though these are treated case insensitively. Fix a few places that spell them in all lowercase, which makes them harder to read. Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-06Merge branch 'ks/branch-set-upstream'Libravatar Junio C Hamano1-4/+2
"branch --set-upstream" that has been deprecated in Git 1.8 has finally been retired. * ks/branch-set-upstream: branch: quote branch/ref names to improve readability builtin/branch: stop supporting the "--set-upstream" option t3200: cleanup cruft of a test
2017-08-18Documentation: use proper wording for ref format stringsLibravatar Michael J Gruber1-2/+2
Various commands list refs and allow to use a format string for the output that interpolates from the ref as well as the object it points at (for-each-ref; branch and tag in list mode). Currently, the documentation talks about interpolating from the object. This is confusing because a ref points to an object but not vice versa, so the object cannot possible know %(refname), for example. Thus, this is wrong independent of refs being objects (one day, maybe) or not. Change the wording to make this clearer (and distinguish it from formats for the log family). Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-17builtin/branch: stop supporting the "--set-upstream" optionLibravatar Kaartic Sivaraam1-4/+2
The '--set-upstream' option of branch was deprecated in b347d06b ("branch: deprecate --set-upstream and show help if we detect possible mistaken use", 2012-08-30) and has been planned for removal ever since. In order to prevent "--set-upstream" on a command line from being taken as an abbreviated form of "--set-upstream-to", explicitly catch "--set-upstream" option and die, instead of just removing it from the list of options. Before this change, an attempt to use "--set-upstream" resulted in: $ git branch * master $ git branch --set-upstream origin/master The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to Branch origin/master set up to track local branch master. $ echo $? 0 $ git branch * master origin/master With this change, the behaviour becomes like this: $ git branch * master $ git branch --set-upstream origin/master fatal: the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead. $ echo $? 128 $ git branch * master Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-18branch: add a --copy (-c) option to go with --move (-m)Libravatar Sahil Dua1-1/+13
Add the ability to --copy a branch and its reflog and configuration, this uses the same underlying machinery as the --move (-m) option except the reflog and configuration is copied instead of being moved. This is useful for e.g. copying a topic branch to a new version, e.g. work to work-2 after submitting the work topic to the list, while preserving all the tracking info and other configuration that goes with the branch, and unlike --move keeping the other already-submitted branch around for reference. Like --move, when the source branch is the currently checked out branch the HEAD is moved to the destination branch. In the case of --move we don't really have a choice (other than remaining on a detached HEAD) and in order to keep the functionality consistent, we are doing it in similar way for --copy too. The most common usage of this feature is expected to be moving to a new topic branch which is a copy of the current one, in that case moving to the target branch is what the user wants, and doesn't unexpectedly behave differently than --move would. One outstanding caveat of this implementation is that: git checkout maint && git checkout master && git branch -c topic && git checkout - Will check out 'maint' instead of 'master'. This is because the @{-N} feature (or its -1 shorthand "-") relies on HEAD reflogs created by the checkout command, so in this case we'll checkout maint instead of master, as the user might expect. What to do about that is left to a future change. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Sahil Dua <sahildua2305@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-11Merge branch 'ab/ref-filter-no-contains'Libravatar Junio C Hamano1-11/+22
"git tag/branch/for-each-ref" family of commands long allowed to filter the refs by "--contains X" (show only the refs that are descendants of X), "--merged X" (show only the refs that are ancestors of X), "--no-merged X" (show only the refs that are not ancestors of X). One curious omission, "--no-contains X" (show only the refs that are not descendants of X) has been added to them. * ab/ref-filter-no-contains: tag: add tests for --with and --without ref-filter: reflow recently changed branch/tag/for-each-ref docs ref-filter: add --no-contains option to tag/branch/for-each-ref tag: change --point-at to default to HEAD tag: implicitly supply --list given another list-like option tag: change misleading --list <pattern> documentation parse-options: add OPT_NONEG to the "contains" option tag: add more incompatibles mode tests for-each-ref: partly change <object> to <commit> in help tag tests: fix a typo in a test description tag: remove a TODO item from the test suite ref-filter: add test for --contains on a non-commit ref-filter: make combining --merged & --no-merged an error tag doc: reword --[no-]merged to talk about commits, not tips tag doc: split up the --[no-]merged documentation tag doc: move the description of --[no-]merged earlier
2017-03-28Merge branch 'ab/branch-list-doc'Libravatar Junio C Hamano1-2/+7
Doc update. * ab/branch-list-doc: branch doc: update description for `--list` branch doc: change `git branch <pattern>` to use `<branchname>`
2017-03-24ref-filter: reflow recently changed branch/tag/for-each-ref docsLibravatar Ævar Arnfjörð Bjarmason1-7/+8
Reflow the recently changed branch/tag-for-each-ref documentation. This change shows no changes under --word-diff, except the innocuous change of moving git-tag.txt's "[--sort=<key>]" around slightly. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24ref-filter: add --no-contains option to tag/branch/for-each-refLibravatar Ævar Arnfjörð Bjarmason1-4/+12
Change the tag, branch & for-each-ref commands to have a --no-contains option in addition to their longstanding --contains options. This allows for finding the last-good rollout tag given a known-bad <commit>. Given a hypothetically bad commit cf5c7253e0, the git version to revert to can be found with this hacky two-liner: (git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') | sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10 With this new --no-contains option the same can be achieved with: git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10 As the filtering machinery is shared between the tag, branch & for-each-ref commands, implement this for those commands too. A practical use for this with "branch" is e.g. finding branches which were branched off between v2.8.0 and v2.10.0: git branch --contains v2.8.0 --no-contains v2.10.0 The "describe" command also has a --contains option, but its semantics are unrelated to what tag/branch/for-each-ref use --contains for. A --no-contains option for "describe" wouldn't make any sense, other than being exactly equivalent to not supplying --contains at all, which would be confusing at best. Add a --without option to "tag" as an alias for --no-contains, for consistency with --with and --contains. The --with option is undocumented, and possibly the only user of it is Junio (<xmqqefy71iej.fsf@gitster.mtv.corp.google.com>). But it's trivial to support, so let's do that. The additions to the the test suite are inverse copies of the corresponding --contains tests. With this change --no-contains for tag, branch & for-each-ref is just as well tested as the existing --contains option. In addition to those tests, add a test for "tag" which asserts that --no-contains won't find tree/blob tags, which is slightly unintuitive, but consistent with how --contains works & is documented. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24branch doc: update description for `--list`Libravatar Junio C Hamano1-2/+7
The paragraph begins with a sample command line `git branch <name>` that has nothing to do with the option being described. Remove it, but use the space to instead show that multiple patterns can be given. Also mention the unfortunate `-l` that can be easily confused with it. Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23branch doc: change `git branch <pattern>` to use `<branchname>`Libravatar Ævar Arnfjörð Bjarmason1-1/+1
Change an example for `git branch <pattern>` to say `git branch <branchname>` to be consistent with the synopsis. This changes documentation added in d8d33736b5 ("branch: allow pattern arguments", 2011-08-28). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-21ref-filter: make combining --merged & --no-merged an errorLibravatar Ævar Arnfjörð Bjarmason1-2/+4
Change the behavior of specifying --merged & --no-merged to be an error, instead of silently picking the option that was provided last. Subsequent changes of mine add a --no-contains option in addition to the existing --contains. Providing both of those isn't an error, and has actual meaning. Making its cousins have different behavior in this regard would be confusing to the user, especially since we'd be silently disregarding some of their command-line input. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-27Merge branch 'kn/ref-filter-branch-list'Libravatar Junio C Hamano1-1/+6
The code to list branches in "git branch" has been consolidated with the more generic ref-filter API. * kn/ref-filter-branch-list: (21 commits) ref-filter: resurrect "strip" as a synonym to "lstrip" branch: implement '--format' option branch: use ref-filter printing APIs branch, tag: use porcelain output ref-filter: allow porcelain to translate messages in the output ref-filter: add an 'rstrip=<N>' option to atoms which deal with refnames ref-filter: modify the 'lstrip=<N>' option to work with negative '<N>' ref-filter: Do not abruptly die when using the 'lstrip=<N>' option ref-filter: rename the 'strip' option to 'lstrip' ref-filter: make remote_ref_atom_parser() use refname_atom_parser_internal() ref-filter: introduce refname_atom_parser() ref-filter: introduce refname_atom_parser_internal() ref-filter: make "%(symref)" atom work with the ':short' modifier ref-filter: add support for %(upstream:track,nobracket) ref-filter: make %(upstream:track) prints "[gone]" for invalid upstreams ref-filter: introduce format_ref_array_item() ref-filter: move get_head_description() from branch.c ref-filter: modify "%(objectname:short)" to take length ref-filter: implement %(if:equals=<string>) and %(if:notequals=<string>) ref-filter: include reference to 'used_atom' within 'atom_value' ...
2017-02-01doc: add note about ignoring '--no-create-reflog'Libravatar Cornelius Weig1-0/+3
The commands git-branch and git-tag accept the '--create-reflog' option, and create reflog even when core.logallrefupdates configuration is explicitly set not to. On the other hand, the negated form '--no-create-reflog' is accepted as a valid option but has no effect (other than overriding an earlier '--create-reflog' on the command line). This silent noop may puzzle users. To communicate that this is a known limitation, add a short note in the manuals for git-branch and git-tag. Signed-off-by: Cornelius Weig <cornelius.weig@tngtech.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-31branch: implement '--format' optionLibravatar Karthik Nayak1-1/+6
Implement the '--format' option provided by 'ref-filter'. This lets the user list branches as per desired format similar to the implementation in 'git for-each-ref'. Add tests and documentation for the same. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-05tag, branch, for-each-ref: add --ignore-case for sorting and filteringLibravatar Nguyễn Thái Ngọc Duy1-0/+4
This options makes sorting ignore case, which is great when you have branches named bug-12-do-something, Bug-12-do-some-more and BUG-12-do-what and want to group them together. Sorting externally may not be an option because we lose coloring and column layout from git-branch and git-tag. The same could be said for filtering, but it's probably less important because you can always go with the ugly pattern [bB][uU][gG]-* if you're desperate. You can't have case-sensitive filtering and case-insensitive sorting (or the other way around) with this though. For branch and tag, that should be no problem. for-each-ref, as a plumbing, might want finer control. But we can always add --{filter,sort}-ignore-case when there is a need for it. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28doc: typeset HEAD and variants as literalLibravatar Matthieu Moy1-2/+2
This is an application of the newly added CodingGuidelines to HEAD and variants like FETCH_HEAD. It was obtained with: perl -pi -e "s/'([A-Z_]*HEAD)'/\`\$1\`/g" *.txt Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-28doc: typeset long command-line options as literalLibravatar Matthieu Moy1-1/+1
Similarly to the previous commit, use backquotes instead of forward-quotes, for long options. This was obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt and manual tweak to remove false positive in ascii-art (o'--o'--o' to describe rewritten history). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-15Merge branch 'kn/for-each-branch'Libravatar Junio C Hamano1-1/+15
Update "git branch" that list existing branches, using the ref-filter API that is shared with "git tag" and "git for-each-ref". * kn/for-each-branch: branch: add '--points-at' option branch.c: use 'ref-filter' APIs branch.c: use 'ref-filter' data structures branch: drop non-commit error reporting branch: move 'current' check down to the presentation layer branch: roll show_detached HEAD into regular ref_list branch: bump get_head_description() to the top branch: refactor width computation
2015-09-25branch: add '--points-at' optionLibravatar Karthik Nayak1-1/+5
Add the '--points-at' option provided by 'ref-filter'. The option lets the user to list only branches which points at the given object. Add documentation and tests for the same. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25branch.c: use 'ref-filter' APIsLibravatar Karthik Nayak1-1/+11
Make 'branch.c' use 'ref-filter' APIs for iterating through refs sorting. This removes most of the code used in 'branch.c' replacing it with calls to the 'ref-filter' library. Make 'branch.c' use the 'filter_refs()' function provided by 'ref-filter' to filter out tags based on the options set. We provide a sorting option provided for 'branch.c' by using the sorting options provided by 'ref-filter'. Also by default, we sort by 'refname'. Since 'HEAD' is alphabatically before 'refs/...' we end up with an array consisting of the 'HEAD' ref then the local branches and finally the remote-tracking branches. Also remove the 'ignore' variable from ref_array_item as it was previously used for the '--merged' option and now that is handled by ref-filter. Modify some of the tests in t1430 to check the stderr for a warning regarding the broken ref. This is done as ref-filter throws a warning for broken refs rather than directly printing them. Add tests and documentation for the same. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Signed-off-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-17Merge branch 'po/doc-branch-desc'Libravatar Junio C Hamano1-1/+3
The branch descriptions that are set with "git branch --edit-description" option were used in many places but they weren't clearly documented. * po/doc-branch-desc: doc: show usage of branch description
2015-09-14doc: show usage of branch descriptionLibravatar Philip Oakley1-1/+3
The branch description will be included in 'git format-patch --cover-letter' and in 'git pull-request' emails. It can also be used in the automatic merge message. Tell the reader. While here, clarify that the description may be a multi-line explanation of the purpose of the branch's patch series. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-10Merge branch 'mm/branch-doc-updates'Libravatar Junio C Hamano1-2/+6
* mm/branch-doc-updates: Documentation/branch: document -M and -D in terms of --force Documentation/branch: document -d --force and -m --force
2015-07-06Documentation/branch: document -M and -D in terms of --forceLibravatar Matthieu Moy1-2/+2
Now that we have proper documentation for --force's interaction with -d and -m, we can avoid duplication and consider -M and -D as convenience aliases for -m --force and -d --force. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-07-06Documentation/branch: document -d --force and -m --forceLibravatar Matthieu Moy1-0/+4
The --force option was modified in 356e91f (branch: allow -f with -m and -d, 2014-12-08), but the documentation was not updated. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-03-13*config.txt: stick to camelCase naming conventionLibravatar Nguyễn Thái Ngọc Duy1-3/+3
This should improve readability. Compare "thislongname" and "thisLongName". The following keys are left in unchanged. We can decide what to do with them later. - am.keepcr - core.autocrlf .safecrlf .trustctime - diff.dirstat .noprefix - gitcvs.usecrlfattr - gui.blamehistoryctx .trustmtime - pull.twohead - receive.autogc - sendemail.signedoffbycc .smtpsslcertpath .suppresscc Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09Refer to branch.<name>.remote/merge when documenting --trackLibravatar Johan Herland1-2/+4
Make it easier for readers to find the actual config variables that implement the "upstream" relationship. Suggested-by: Per Cederqvist <cederp@opera.com> Signed-off-by: Johan Herland <johan@herland.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-07Merge branch 'nd/branch-error-cases'Libravatar Junio C Hamano1-10/+12
Fix various error messages and conditions in "git branch", e.g. we advertised "branch -d/-D" to remove one or more branches but actually implemented removal of zero or more branches---request to remove no branches was not rejected. * nd/branch-error-cases: branch: let branch filters imply --list docs: clarify git-branch --list behavior branch: mark more strings for translation branch: give a more helpful message on redundant arguments branch: reject -D/-d without branch name
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-1/+1
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-31branch: let branch filters imply --listLibravatar Jeff King1-3/+3
Currently, a branch filter like `--contains`, `--merged`, or `--no-merged` is ignored when we are not in listing mode. For example: git branch --contains=foo bar will create the branch "bar" from the current HEAD, ignoring the `--contains` argument entirely. This is not very helpful. There are two reasonable behaviors for git here: 1. Flag an error; the arguments do not make sense. 2. Implicitly go into `--list` mode This patch chooses the latter, as it is more convenient, and there should not be any ambiguity with attempting to create a branch; using `--contains` and not wanting to list is nonsensical. That leaves the case where an explicit modification option like `-d` is given. We already catch the case where `--list` is given alongside `-d` and flag an error. With this patch, we will also catch the use of `--contains` and other filter options alongside `-d`. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-31docs: clarify git-branch --list behaviorLibravatar Jeff King1-7/+9
It was not clear from the "description" section of git-branch(1) that using a <pattern> meant that you _had_ to use the --list option. Let's clarify that, and while we're at it, reword some clunky and ambiguous sentences. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>