path: root/Documentation/git-branch.txt
AgeCommit message (Collapse)Author
2021-02-26Merge branch 'jc/maint-column-doc-typofix'Junio C Hamano
Doc update. * jc/maint-column-doc-typofix: Documentation: typofix --column description
2021-02-20Documentation: typofix --column descriptionJunio C Hamano
f4ed0af6 (Merge branch 'nd/columns', 2012-05-03) brought in three cut-and-pasted copies of malformatted descriptions. Let's fix them all the same way by marking the configuration variable names up as monospace just like the command line option `--column` is typeset. While we are at it, correct a missing space after the full stop that ends the sentence. Signed-off-by: Junio C Hamano <>
2021-02-03doc/git-branch: fix awkward wording for "-c"Jeff King
The description for "-c" is hard to parse. I think the big issue is lack of commas, but I've also reordered the words to keep the main focus point of "instead of renaming, copy" together. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2020-11-04doc: clarify that --abbrev=<n> is about the minimum lengthJunio C Hamano
Early text written in 2006 explains the "--abbrev=<n>" option to "show only a partial prefix", without saying that the length of the partial prefix is not necessarily the number given to the option to ensure that the output names the object uniquely. Update documentation for the diff family of commands, "blame", "branch --verbose", "ls-files" and "ls-tree" to stress that the short prefix must uniquely refer to an object, and <n> is merely the mininum number of hexdigits used in the prefix. Helped-by: Derrick Stolee <> Signed-off-by: Junio C Hamano <>
2020-09-18Doc: prefer more specific file nameAaron Lipman
Change filters.txt to ref-reachability-filters.txt in order to avoid squatting on a file name that might be useful for another purpose. Signed-off-by: Aaron Lipman <> Signed-off-by: Junio C Hamano <>
2020-09-16ref-filter: allow merged and no-merged filtersAaron Lipman
Enable ref-filter to process multiple merged and no-merged filters, and extend functionality to git branch, git tag and git for-each-ref. This provides an easy way to check for branches that are "graduation candidates:" $ git branch --no-merged master --merged next If passed more than one merged (or more than one no-merged) filter, refs must be reachable from any one of the merged commits, and reachable from none of the no-merged commits. Signed-off-by: Aaron Lipman <> Signed-off-by: Junio C Hamano <>
2020-09-16Doc: cover multiple contains/no-contains filtersAaron Lipman
Update documentation for "git branch", "git for-each-ref" and "git tag" with notes explaining what happens when passed multiple --contains or --no-contains filters. This behavior is useful to document prior to enabling multiple merged/no-merged filters, in order to demonstrate consistent behavior between merged/no-merged and contains/no-contains filters. Signed-off-by: Aaron Lipman <> Signed-off-by: Junio C Hamano <>
2020-06-24docs: add missing diamond bracketsJohannes Schindelin
There were a couple of instances in our manual pages that had an opening diamond bracket without a corresponding closing one. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2019-07-09Merge branch 'nd/switch-and-restore'Junio C Hamano
Two new commands "git switch" and "git restore" are introduced to split "checking out a branch to work on advancing its history" and "checking out paths out of the index and/or a tree-ish to work on advancing the current history" out of the single "git checkout" command. * nd/switch-and-restore: (46 commits) completion: disable dwim on "git switch -d" switch: allow to switch in the middle of bisect t2027: use test_must_be_empty Declare both git-switch and git-restore experimental help: move git-diff and git-reset to different groups doc: promote "git restore" user-manual.txt: prefer 'merge --abort' over 'reset --hard' completion: support restore t: add tests for restore restore: support --patch restore: replace --force with --ignore-unmerged restore: default to --source=HEAD when only --staged is specified restore: reject invalid combinations with --staged restore: add --worktree and --staged checkout: factor out worktree checkout code restore: disable overlay mode by default restore: make pathspec mandatory restore: take tree-ish from --source option instead checkout: split part of it to new command 'restore' doc: promote "git switch" ...
2019-07-09Merge branch 'po/doc-branch'Junio C Hamano
Doc update. * po/doc-branch: doc branch: provide examples for listing remote tracking branches
2019-07-09Merge branch 'nb/branch-show-other-worktrees-head'Junio C Hamano
"git branch --list" learned to show branches that are checked out in other worktrees connected to the same repository prefixed with '+', similar to the way the currently checked out branch is shown with '*' in front. * nb/branch-show-other-worktrees-head: branch: add worktree info on verbose output branch: update output to include worktree info ref-filter: add worktreepath atom
2019-05-29doc branch: provide examples for listing remote tracking branchesPhilip Oakley
The availability of these pattern selections is not obvious from the man pages, as per mail thread <>. Provide examples. Re-order the `git branch` synopsis to emphasise the `--list <pattern>` pairing. Also expand and reposition the `all/remotes` options. Split the over-long description into three parts so that the <pattern> description can be seen. Clarify that the `all/remotes` options require the --list if patterns are to be used. Add examples of listing remote tracking branches that match a pattern, including `git for-each-ref` which has more options. Improve the -a/-r warning message. The message confused this author as the combined -a and -r options had not been given, though a pattern had. Specifically guide the user that maybe they needed the --list option to enable a remote branch pattern selection. Signed-off-by: Philip Oakley <> Signed-off-by: Junio C Hamano <>
2019-05-19Merge branch 'dl/branch-from-3dot-merge-base'Junio C Hamano
"git branch new A...B" and "git checkout -b new A...B" have been taught that in their contexts, the notation A...B means "the merge base between these two commits", just like "git checkout A...B" detaches HEAD at that commit. * dl/branch-from-3dot-merge-base: branch: make create_branch accept a merge base rev t2018: cleanup in current test
2019-05-07branch: add worktree info on verbose outputNickolai Belakovski
To display worktree path for refs checked out in a linked worktree Signed-off-by: Nickolai Belakovski <> Signed-off-by: Junio C Hamano <>
2019-05-07branch: update output to include worktree infoNickolai Belakovski
The output of git branch is modified to mark branches checked out in a linked worktree with a "+" and color them in cyan (in contrast to the current branch, which will still be denoted with a "*" and colored in green) This is meant to communicate to the user that the branches that are marked or colored will behave differently from other branches if the user attempts to check them out or delete them, since branches checked out in another worktree cannot be checked out or deleted. Signed-off-by: Nickolai Belakovski <> Signed-off-by: Junio C Hamano <>
2019-05-07branch: make create_branch accept a merge base revDenton Liu
When we ran something like $ git checkout -b test master... it would fail with the message fatal: Not a valid object name: 'master...'. This was caused by the call to `create_branch` where `start_name` is expected to be a valid rev. However, git-checkout allows the branch to be a valid _merge base_ rev (i.e. with a "...") so it was possible for an invalid rev to be passed in. Make `create_branch` accept a merge base rev so that this case does not error out. As a side-effect, teach git-branch how to handle merge base revs as well. Helped-by: Junio C Hamano <> Signed-off-by: Denton Liu <> Signed-off-by: Junio C Hamano <>
2019-04-02doc: promote "git switch"Nguyễn Thái Ngọc Duy
The new command "git switch" is added to avoid the confusion of one-command-do-all "git checkout" for new users. They are also helpful to avoid ambiguation context. For these reasons, promote it everywhere possible. This includes documentation, suggestions/advice from other commands... The "Checking out files" progress line in unpack-trees.c is also updated to "Updating files" to be neutral to both git-checkout and git-switch. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2019-03-07Merge branch 'du/branch-show-current'Junio C Hamano
"git branch" learned a new subcommand "--show-current". * du/branch-show-current: branch: introduce --show-current display option
2019-01-23doc: tidy asciidoc styleJean-Noël Avila
This mainly refers to enforcing indentation on additional lines of items of lists. Signed-off-by: Jean-Noël Avila <> Signed-off-by: Junio C Hamano <>
2018-10-26branch: introduce --show-current display optionDaniels Umanovskis
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 <> Signed-off-by: Junio C Hamano <>
2018-09-17Merge branch 'jk/branch-l-1-repurpose'Junio C Hamano
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" referencesJeff King
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 <> Signed-off-by: Junio C Hamano <>
2018-08-16branch: support configuring --sort via .gitconfigSamuel Maftoul
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 <> Signed-off-by: Junio C Hamano <>
2018-06-22branch: make "-l" a synonym for "--list"Jeff King
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 <> Signed-off-by: Junio C Hamano <>
2018-06-22branch: deprecate "-l" optionJeff King
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 <> Signed-off-by: Junio C Hamano <>
2018-05-02doc: keep first level section header in upper caseNguyễn Thái Ngọc Duy
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 <> Signed-off-by: Junio C Hamano <>
2017-12-06Merge branch 'tz/branch-doc-remove-set-upstream'Junio C Hamano
"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'Junio C Hamano
"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"Martin Ågren
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 <> Signed-off-by: Junio C Hamano <>
2017-11-20branch: respect `pager.branch` in list-mode onlyMartin Ågren
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 <> Signed-off-by: Junio C Hamano <>
2017-11-17branch doc: remove --set-upstream from synopsisTodd Zullinger
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 <> Signed-off-by: Junio C Hamano <>
2017-10-19Merge branch 'jc/branch-force-doc-readability-fix'Junio C Hamano
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 readabilityJunio C Hamano
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 <> Helped-by: Jeff King <> Helped-by: Andreas Schwab <> Signed-off-by: Junio C Hamano <>
2017-10-03Merge branch 'sd/branch-copy'Junio C Hamano
"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'Junio C Hamano
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 readabilityKaartic Sivaraam
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 <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2017-09-06Merge branch 'ks/branch-set-upstream'Junio C Hamano
"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 stringsMichael J Gruber
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 <> Signed-off-by: Junio C Hamano <>
2017-08-17builtin/branch: stop supporting the "--set-upstream" optionKaartic Sivaraam
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 <> Signed-off-by: Junio C Hamano <>
2017-06-19branch: add a --copy (-c) option to go with --move (-m)Sahil Dua
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 <> Signed-off-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Sahil Dua <> Signed-off-by: Junio C Hamano <>
2017-04-11Merge branch 'ab/ref-filter-no-contains'Junio C Hamano
"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'Junio C Hamano
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 docsÆvar Arnfjörð Bjarmason
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 <> Signed-off-by: Junio C Hamano <>
2017-03-24ref-filter: add --no-contains option to tag/branch/for-each-refÆvar Arnfjörð Bjarmason
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 (<>). 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 <> Signed-off-by: Junio C Hamano <>
2017-03-24branch doc: update description for `--list`Junio C Hamano
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 <> Reviewed-by: Jonathan Nieder <> Reviewed-by: Ævar Arnfjörð Bjarmason <> Signed-off-by: Junio C Hamano <>
2017-03-24branch doc: change `git branch <pattern>` to use `<branchname>`Ævar Arnfjörð Bjarmason
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 <> Signed-off-by: Junio C Hamano <>
2017-03-21ref-filter: make combining --merged & --no-merged an errorÆvar Arnfjörð Bjarmason
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 <> Signed-off-by: Junio C Hamano <>
2017-02-27Merge branch 'kn/ref-filter-branch-list'Junio C Hamano
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'Cornelius Weig
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 <> Helped-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2017-01-31branch: implement '--format' optionKarthik Nayak
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 <> Mentored-by: Matthieu Moy <> Signed-off-by: Karthik Nayak <> Signed-off-by: Junio C Hamano <>