summaryrefslogtreecommitdiff
path: root/t/t3203-branch-output.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-07-26ref-filter: add %(rest) atomLibravatar ZheNing Hu1-0/+4
%(rest) is a atom used for cat-file batch mode, which can split the input lines at the first whitespace boundary, all characters before that whitespace are considered to be the object name; characters after that first run of whitespace (i.e., the "rest" of the line) are output in place of the %(rest) atom. In order to let "cat-file --batch=%(rest)" use the ref-filter interface, add %(rest) atom for ref-filter. Introduce the reject_atom() to reject the atom %(rest) for "git for-each-ref", "git branch", "git tag" and "git verify-tag". Reviewed-by: Jacob Keller <jacob.keller@gmail.com> Suggected-by: Jacob Keller <jacob.keller@gmail.com> Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Hariom Verma <hariom18599@gmail.com> Signed-off-by: ZheNing Hu <adlternative@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-10tests: remove most uses of test_i18ncmpLibravatar Ævar Arnfjörð Bjarmason1-14/+14
As a follow-up to d162b25f956 (tests: remove support for GIT_TEST_GETTEXT_POISON, 2021-01-20) remove most uses of test_i18ncmp via a simple s/test_i18ncmp/test_cmp/g search-replacement. I'm leaving t6300-for-each-ref.sh out due to a conflict with in-flight changes between "master" and "seen", as well as the prerequisite itself due to other changes between "master" and "next/seen" which add new test_i18ncmp uses. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-25Merge branch 'js/default-branch-name-tests-final-stretch'Libravatar Junio C Hamano1-0/+3
Prepare tests not to be affected by the name of the default branch "git init" creates. * js/default-branch-name-tests-final-stretch: (28 commits) tests: drop prereq `PREPARE_FOR_MAIN_BRANCH` where no longer needed t99*: adjust the references to the default branch name "main" tests(git-p4): transition to the default branch name `main` t9[5-7]*: adjust the references to the default branch name "main" t9[0-4]*: adjust the references to the default branch name "main" t8*: adjust the references to the default branch name "main" t7[5-9]*: adjust the references to the default branch name "main" t7[0-4]*: adjust the references to the default branch name "main" t6[4-9]*: adjust the references to the default branch name "main" t64*: preemptively adjust alignment to prepare for `master` -> `main` t6[0-3]*: adjust the references to the default branch name "main" t5[6-9]*: adjust the references to the default branch name "main" t55[4-9]*: adjust the references to the default branch name "main" t55[23]*: adjust the references to the default branch name "main" t551*: adjust the references to the default branch name "main" t550*: adjust the references to the default branch name "main" t5503: prepare aligned comment for replacing `master` with `main` t5[0-4]*: adjust the references to the default branch name "main" t5323: prepare centered comment for `master` -> `main` t4*: adjust the references to the default branch name "main" ...
2021-01-07branch: show "HEAD detached" first under reverse sortLibravatar Ævar Arnfjörð Bjarmason1-3/+3
Change the output of the likes of "git branch -l --sort=-objectsize" to show the "(HEAD detached at <hash>)" message at the start of the output. Before the compare_detached_head() function added in a preceding commit we'd emit this output as an emergent effect. It doesn't make any sense to consider the objectsize, type or other non-attribute of the "(HEAD detached at <hash>)" message for the purposes of sorting. Let's always emit it at the top instead. The only reason it was sorted in the first place is because we're injecting it into the ref-filter machinery so builtin/branch.c doesn't need to do its own "am I detached?" detection. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-07branch: sort detached HEAD based on a flagLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Change the ref-filter sorting of detached HEAD to check the FILTER_REFS_DETACHED_HEAD flag, instead of relying on the ref description filled-in by get_head_description() to start with "(", which in turn we expect to ASCII-sort before any other reference. For context, we'd like the detached line to appear first at the start of "git branch -l", e.g.: $ git branch -l * (HEAD detached at <hash>) master This doesn't change that, but improves on a fix made in 28438e84e04 (ref-filter: sort detached HEAD lines firstly, 2019-06-18) and gives the Chinese translation the ability to use its preferred punctuation marks again. In Chinese the fullwidth versions of punctuation like "()" are typically written as (U+FF08 fullwidth left parenthesis), (U+FF09 fullwidth right parenthesis) instead[1]. This form is used in both po/zh_{CN,TW}.po in most cases where "()" is translated in a string. Aside from that improvement to the Chinese translation, it also just makes for cleaner code that we mark any special cases in the ref_array we're sorting with flags and make the sort function aware of them, instead of piggy-backing on the general-case of strcmp() doing the right thing. As seen in the amended tests this made reverse sorting a bit more consistent. Before this we'd sometimes sort this message in the middle, now it's consistently at the beginning or end, depending on whether we're doing a normal or reverse sort. Having it at the end doesn't make much sense either, but at least it behaves consistently now. A follow-up commit will make this behavior under reverse sorting even better. I'm removing the "TRANSLATORS" comments that were in the old code while I'm at it. Those were added in d4919bb288e (ref-filter: move get_head_description() from branch.c, 2017-01-10). I think it's obvious from context, string and translation memory in typical translation tools that these are the same or similar string. 1. https://en.wikipedia.org/wiki/Chinese_punctuation#Marks_similar_to_European_punctuation Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-06branch tests: add to --sort testsLibravatar Ævar Arnfjörð Bjarmason1-1/+50
Further stress the --sort callback in ref-filter.c. The implementation uses certain short-circuiting logic, let's make sure it behaves the same way on e.g. name & version sort. Improves a test added in aedcb7dc75e (branch.c: use 'ref-filter' APIs, 2015-09-23). I don't think all of this output makes sense, but let's test for the behavior as-is, we can fix bugs in it in a later commit. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-16t3203: complete the transition to using the branch name `main`Libravatar Johannes Schindelin1-21/+22
In 66713e84e71 (tests: prepare aligned mentions of the default branch name, 2020-10-23), we started that transition, trying to prepare for a time when `git init` would use that name for the initial branch. Even if that time has not arrived, we can complete the transition by making the test script independent of the default branch name. This also allows us to drop the `PREPARE_FOR_MAIN_BRANCH` prereq from one test case. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19tests: drop prereq `PREPARE_FOR_MAIN_BRANCH` where no longer neededLibravatar Johannes Schindelin1-1/+1
We introduced the `PREPARE_FOR_MAIN_BRANCH` prereq for the sole purpose of allowing us to perform the non-trivial adjustments regarding the `master` -> `main` rename before the automatable ones. Now that the transition is almost complete, we can stop using it in most instances. The only two exceptions are t5526 and t9902: at the time of writing, there are other patches in flight that touch these test scripts, therefore their transition to `main` is postponed to a later date. This patch is the result of this command: sed -i 's/PREPARE_FOR_MAIN_BRANCH[ ,]//' t/t[0-9]*.sh && git checkout HEAD -- t/t5526\* t/t9902\* Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19t3[0-3]*: adjust the references to the default branch name "main"Libravatar Johannes Schindelin1-20/+20
Carefully excluding t3040, which sees independent development elsewhere at the time of writing, we transition above-mentioned tests to the default branch name `main`. This trick was performed via $ (cd t && sed -i -e 's/master/main/g' -e 's/MASTER/MAIN/g' \ -e 's/Master/Main/g' -- t3[0-3]*.sh t3206/* && git checkout HEAD -- t3040\*) This allows us to define `GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main` for those tests. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-19tests: mark tests relying on the current default for `init.defaultBranch`Libravatar Johannes Schindelin1-0/+3
In addition to the manual adjustment to let the `linux-gcc` CI job run the test suite with `master` and then with `main`, this patch makes sure that GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME is set in all test scripts that currently rely on the initial branch name being `master by default. To determine which test scripts to mark up, the first step was to force-set the default branch name to `master` in - all test scripts that contain the keyword `master`, - t4211, which expects `t/t4211/history.export` with a hard-coded ref to initialize the default branch, - t5560 because it sources `t/t556x_common` which uses `master`, - t8002 and t8012 because both source `t/annotate-tests.sh` which also uses `master`) This trick was performed by this command: $ sed -i '/^ *\. \.\/\(test-lib\|lib-\(bash\|cvs\|git-svn\)\|gitweb-lib\)\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' $(git grep -l master t/t[0-9]*.sh) \ t/t4211*.sh t/t5560*.sh t/t8002*.sh t/t8012*.sh After that, careful, manual inspection revealed that some of the test scripts containing the needle `master` do not actually rely on a specific default branch name: either they mention `master` only in a comment, or they initialize that branch specificially, or they do not actually refer to the current default branch. Therefore, the aforementioned modification was undone in those test scripts thusly: $ git checkout HEAD -- \ t/t0027-auto-crlf.sh t/t0060-path-utils.sh \ t/t1011-read-tree-sparse-checkout.sh \ t/t1305-config-include.sh t/t1309-early-config.sh \ t/t1402-check-ref-format.sh t/t1450-fsck.sh \ t/t2024-checkout-dwim.sh \ t/t2106-update-index-assume-unchanged.sh \ t/t3040-subprojects-basic.sh t/t3301-notes.sh \ t/t3308-notes-merge.sh t/t3423-rebase-reword.sh \ t/t3436-rebase-more-options.sh \ t/t4015-diff-whitespace.sh t/t4257-am-interactive.sh \ t/t5323-pack-redundant.sh t/t5401-update-hooks.sh \ t/t5511-refspec.sh t/t5526-fetch-submodules.sh \ t/t5529-push-errors.sh t/t5530-upload-pack-error.sh \ t/t5548-push-porcelain.sh \ t/t5552-skipping-fetch-negotiator.sh \ t/t5572-pull-submodule.sh t/t5608-clone-2gb.sh \ t/t5614-clone-submodules-shallow.sh \ t/t7508-status.sh t/t7606-merge-custom.sh \ t/t9302-fast-import-unpack-limit.sh We excluded one set of test scripts in these commands, though: the range of `git p4` tests. The reason? `git p4` stores the (foreign) remote branch in the branch called `p4/master`, which is obviously not the default branch. Manual analysis revealed that only five of these tests actually require a specific default branch name to pass; They were modified thusly: $ sed -i '/^ *\. \.\/lib-git-p4\.sh$/i\ GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=master\ export GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME\ ' t/t980[0167]*.sh t/t9811*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-23tests: prepare aligned mentions of the default branch nameLibravatar Johannes Schindelin1-2/+2
In some tests, the default branch name is part of aligned output. As we want to change the default branch name to `main`, which is two characters shorter than the old default branch name, we will have to adjust those tests. Since we use the original default branch name until the entire test suite has been adjusted accordingly, the touched test cases need to be guarded by a prereq (that is so far disabled so that they are skipped for now). The test cases that depend on those test cases that are newly guarded by that prereq naturally have to be guarded, too. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-09Merge branch 'nb/branch-show-other-worktrees-head'Libravatar Junio C Hamano1-2/+42
"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-07branch: add worktree info on verbose outputLibravatar Nickolai Belakovski1-0/+19
To display worktree path for refs checked out in a linked worktree Signed-off-by: Nickolai Belakovski <nbelakovski@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-07branch: update output to include worktree infoLibravatar Nickolai Belakovski1-2/+22
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 <nbelakovski@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-26branch: introduce --show-current display optionLibravatar Daniels Umanovskis1-0/+44
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>
2017-10-04t3203: drop "always" color testLibravatar Jeff King1-6/+0
In preparation for the behavior of "always" changing to match "auto", we can simply drop this test. We already check other forms (like "--color") independently. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-04test-terminal: set TERM=vt100Libravatar Jeff King1-1/+1
The point of the test-terminal script is to simulate in the test scripts an environment where output is going to a real terminal. But since test-lib.sh also sets TERM=dumb, the simulation isn't very realistic. The color code will skip auto-coloring for TERM=dumb, leading to us liberally sprinkling test_terminal env TERM=vt100 git ... through the test suite to convince the tests to actually generate colors. Let's set TERM for programs run under test_terminal, which is one less thing for test-writers to remember. In most cases the callers can be simplified, but note there is one interesting case in t4202. It uses test_terminal to check the auto-enabling of --decorate, but the expected output _doesn't_ contain colors (because TERM=dumb suppresses them). Using TERM=vt100 is closer to what the real world looks like; adjust the expected output to match. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13ref-filter: consult want_color() before emitting colorsLibravatar Jeff King1-0/+31
When color placeholders like %(color:red) are used in a ref-filter format, we unconditionally output the colors, even if the user has asked us for no colors. This usually isn't a problem when the user is constructing a --format on the command line, but it means we may do the wrong thing when the format is fed from a script or alias. For example: $ git config alias.b 'branch --format=%(color:green)%(refname)' $ git b --no-color should probably omit the green color. Likewise, running: $ git b >branches should probably also omit the color, just as we would for all baked-in coloring (and as we recently started to do for user-specified colors in --pretty formats). This commit makes both of those cases work by teaching the ref-filter code to consult want_color() before outputting any color. The color flag in ref_format defaults to "-1", which means we'll consult color.ui, which in turn defaults to the usual isatty() check on stdout. However, callers like git-branch which support their own color config (and command-line options) can override that. The new tests independently cover all three of the callers of ref-filter (for-each-ref, tag, and branch). Even though these seem redundant, it confirms that we've correctly plumbed through all of the necessary config to make colors work by default. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-11tests: fix tests broken under GETTEXT_POISON=YesPleaseLibravatar Ævar Arnfjörð Bjarmason1-1/+1
The GETTEXT_POISON=YesPlease compile-time testing option added in my bb946bba76 ("i18n: add GETTEXT_POISON to simulate unfriendly translator", 2011-02-22) has been slowly bitrotting as strings have been marked for translation, and new tests have been added without running it. I brought this up on the list ("[BUG] test suite broken with GETTEXT_POISON=YesPlease", [1]) asking whether this mode was useful at all anymore. At least one person occasionally uses it, and Lars Schneider offered to change one of the the Travis builds to run in this mode, so fix up the failing ones. My test setup runs most of the tests, with the notable exception of skipping all the p4 tests, so it's possible that there's still some lurking regressions I haven't fixed. 1. <CACBZZX62+acvi1dpkknadTL827mtCm_QesGSZ=6+UnyeMpg8+Q@mail.gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-01-31branch: implement '--format' optionLibravatar Karthik Nayak1-0/+14
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>
2017-01-31branch: use ref-filter printing APIsLibravatar Karthik Nayak1-1/+1
Port branch.c to use ref-filter APIs for printing. This clears out most of the code used in branch.c for printing and replaces them with calls made to the ref-filter library. Introduce build_format() which gets the format required for printing of refs. Make amendments to print_ref_list() to reflect these changes. The strings included in build_format() may not be safely quoted for inclusion (i.e. it might contain '%' which needs to be escaped with an additional '%'). Introduce quote_literal_for_format() as a helper function which takes a string and returns a version of the string that is safely quoted to be used in the for-each-ref format which is built in build_format(). Change calc_maxwidth() to also account for the length of HEAD ref, by calling ref-filter:get_head_discription(). Also change the test in t6040 to reflect the changes. Before this patch, all cross-prefix symrefs weren't shortened. Since we're using ref-filter APIs, we shorten all symrefs by default. We also allow the user to change the format if needed with the introduction of the '--format' option in the next patch. Mentored-by: Christian Couder <christian.couder@gmail.com> Mentored-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Helped-by: Ramsay Jones <ramsay@ramsayjones.plus.com> 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/+29
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-04-04branch: fix shortening of non-remote symrefsLibravatar Jeff King1-0/+12
Commit aedcb7d (branch.c: use 'ref-filter' APIs, 2015-09-23) adjusted the symref-printing code to look like this: if (item->symref) { skip_prefix(item->symref, "refs/remotes/", &desc); strbuf_addf(&out, " -> %s", desc); } This has three bugs in it: 1. It always skips past "refs/remotes/", instead of skipping past the prefix associated with the branch we are showing (so commonly we see "refs/remotes/" for the refs/remotes/origin/HEAD symref, but the previous code would skip "refs/heads/" when showing a symref it found in refs/heads/. 2. If skip_prefix() does not match, it leaves "desc" untouched, and we show whatever happened to be in it (which is the refname from a call to skip_prefix() earlier in the function). 3. If we do match with skip_prefix(), we stomp on the "desc" variable, which is later passed to add_verbose_info(). We probably want to retain the original refname there (though it likely doesn't matter in practice, since after all, one points to the other). The fix to match the original code is fairly easy: record the prefix to strip based on item->kind, and use it here. However, since we already have a local variable named "prefix", let's give the two prefixes verbose names so we don't confuse them. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26tag: do not show ambiguous tag names as "tags/foo"Libravatar Jeff King1-0/+8
Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11), git-tag has started showing tags with ambiguous names (i.e., when both "heads/foo" and "tags/foo" exists) as "tags/foo" instead of just "foo". This is both: - pointless; the output of "git tag" includes only refs/tags, so we know that "foo" means the one in "refs/tags". and - ambiguous; in the original output, we know that the line "foo" means that "refs/tags/foo" exists. In the new output, it is unclear whether we mean "refs/tags/foo" or "refs/tags/tags/foo". The reason this happens is that commit b7cc53e9 switched git-tag to use ref-filter's "%(refname:short)" output formatting, which was adapted from for-each-ref. This more general code does not know that we care only about tags, and uses shorten_unambiguous_ref to get the short-name. We need to tell it that we care only about "refs/tags/", and it should shorten with respect to that value. In theory, the ref-filter code could figure this out by us passing FILTER_REFS_TAGS. But there are two complications there: 1. The handling of refname:short is deep in formatting code that does not even have our ref_filter struct, let alone the arguments to the filter_ref struct. 2. In git v2.7.0, we expose the formatting language to the user. If we follow this path, it will mean that "%(refname:short)" behaves differently for "tag" versus "for-each-ref" (including "for-each-ref refs/tags/"), which can lead to confusion. Instead, let's add a new modifier to the formatting language, "strip", to remove a specific set of prefix components. This fixes "git tag", and lets users invoke the same behavior from their own custom formats (for "tag" or "for-each-ref") while leaving ":short" with its same consistent meaning in all places. We introduce a test in t7004 for "git tag", which fails without this patch. We also add a similar test in t3203 for "git branch", which does not actually fail. But since it is likely that "branch" will eventually use the same formatting code, the test helps defend against future regressions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-11-03Merge branch 'kn/for-each-branch'Libravatar Junio C Hamano1-1/+1
Using the timestamp based criteria in "git branch --sort" did not tiebreak branches that point at commits with the same timestamp (or the same commit), making the resulting output unstable. * kn/for-each-branch: ref-filter: fallback on alphabetical comparison
2015-10-30ref-filter: fallback on alphabetical comparisonLibravatar Karthik Nayak1-1/+1
In ref-filter.c the comparison of refs while sorting is handled by cmp_ref_sorting() function. When sorting as per numerical values (e.g. --sort=objectsize) there is no fallback comparison when both refs hold the same value. This can cause unexpected results (i.e. the order of listing refs with equal values cannot be pre-determined) as pointed out by Johannes Sixt ($gmane/280117). Hence, fallback to alphabetical comparison based on the refname whenever the other criterion is equal. A test in t3203 was expecting that branch-two sorts before HEAD, which happened to be how qsort(3) on Linux sorted the array, but (1) that outcome was not even guaranteed, and (2) once we start breaking ties with the refname, "HEAD" should sort before "branch-two" so the original expectation was inconsistent with the criterion we now use. Update it to match the new world order, which we can now depend on being stable. Helped-by: Junio C Hamano <gitster@pobox.com> Reported-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Karthik Nayak <Karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-15Merge branch 'mm/detach-at-HEAD-reflog'Libravatar Junio C Hamano1-0/+13
After "git checkout --detach", "git status" reported a fairly useless "HEAD detached at HEAD", instead of saying at which exact commit. * mm/detach-at-HEAD-reflog: status: don't say 'HEAD detached at HEAD' t3203: test 'detached at' after checkout --detach
2015-10-02status: don't say 'HEAD detached at HEAD'Libravatar Matthieu Moy1-1/+1
After using "git checkout --detach", the reflog is left with an entry like checkout: moving from ... to HEAD This message is parsed to generate the 'HEAD detached at' message in 'git branch' and 'git status', which leads to the not-so-useful message 'HEAD detached at HEAD'. Instead, when parsing such reflog entry, resolve HEAD to the corresponding commit in the reflog, so that the message becomes 'HEAD detached at $sha1'. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-02t3203: test 'detached at' after checkout --detachLibravatar Matthieu Moy1-0/+13
This currently fails: the output is 'HEAD detached at HEAD'. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-09-25branch: add '--points-at' optionLibravatar Karthik Nayak1-0/+9
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-0/+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-03-06branch: name detached HEAD analogous to statusLibravatar Michael J Gruber1-1/+38
"git status" carefully names a detached HEAD "at" resp. "from" a rev or ref depending on whether the detached HEAD has moved since. "git branch" always uses "from", which can be confusing, because a status-aware user would interpret this as moved detached HEAD. Make "git branch" use the same logic and wording. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-16branch: show more information when HEAD is detachedLibravatar Nguyễn Thái Ngọc Duy1-3/+3
This prints more helpful info when HEAD is detached: is it detached because of bisect or rebase? What is the original branch name in those cases? Is it detached because the user checks out a remote ref or a tag (and which one)? Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-08branch: -v does not automatically imply --listLibravatar Michael J Gruber1-2/+6
"branch -v" without other options or parameters still works in the list mode, but that is not because there is "-v" but because there is no parameter nor option. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-28branch: allow pattern argumentsLibravatar Michael J Gruber1-0/+19
Allow pattern arguments for the list mode just like for git tag -l. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-28branch: introduce --list optionLibravatar Michael J Gruber1-0/+5
Currently, there is no way to invoke the list mode explicitly, without giving -v to force verbose output. Introduce a --list option which invokes the list mode. This will be beneficial for invoking list mode with pattern matching, which otherwise would be interpreted as branch creation. Along with --list, test also combinations of existing options. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-04-13i18n: use test_i18ncmp and test_i18ngrep in t3203, t3501 and t3507Libravatar Junio C Hamano1-2/+2
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-09i18n: git-branch "(no branch)" messageLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Gettextize the "(no branch)" message that's shown by "git branch" when you're in a detached HEAD. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-09tests: add missing &&Libravatar Jonathan Nieder1-3/+3
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-18add basic branch display testsLibravatar Jeff King1-0/+81
We were not testing the output of "git branch" anywhere. Not only does this not protect us against regressions in the output, but we are not exercising code paths which may have bugs (such as the one fixed by 45e2b61). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>