summaryrefslogtreecommitdiff
path: root/t/t3203-branch-output.sh
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'kn/for-each-branch'Junio C Hamano2015-11-031-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
| * ref-filter: fallback on alphabetical comparisonkn/for-each-branchKarthik Nayak2015-10-301-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>
* | Merge branch 'mm/detach-at-HEAD-reflog'Junio C Hamano2015-10-151-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
| * status: don't say 'HEAD detached at HEAD'mm/detach-at-HEAD-reflogMatthieu Moy2015-10-021-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>
| * t3203: test 'detached at' after checkout --detachMatthieu Moy2015-10-021-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>
* | branch: add '--points-at' optionKarthik Nayak2015-09-251-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>
* | branch.c: use 'ref-filter' APIsKarthik Nayak2015-09-251-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>
* branch: name detached HEAD analogous to statusmg/detached-head-reportMichael J Gruber2015-03-061-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>
* branch: show more information when HEAD is detachedNguyễn Thái Ngọc Duy2013-03-161-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>
* branch: -v does not automatically imply --listMichael J Gruber2011-09-081-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>
* branch: allow pattern argumentsMichael J Gruber2011-08-281-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>
* branch: introduce --list optionMichael J Gruber2011-08-281-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>
* i18n: use test_i18ncmp and test_i18ngrep in t3203, t3501 and t3507Junio C Hamano2011-04-131-2/+2
| | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
* i18n: git-branch "(no branch)" messageÆvar Arnfjörð Bjarmason2011-03-091-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>
* tests: add missing &&Jonathan Nieder2010-11-091-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>
* add basic branch display testsJeff King2009-02-181-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>