summaryrefslogtreecommitdiff
path: root/t/t3203-branch-output.sh
AgeCommit message (Collapse)AuthorFilesLines
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>