summaryrefslogtreecommitdiff
path: root/t/t1508-at-combinations.sh
AgeCommit message (Collapse)AuthorFilesLines
2013-09-12Add new @ shortcut for HEADLibravatar Felipe Contreras1-0/+8
Typing 'HEAD' is tedious, especially when we can use '@' instead. The reason for choosing '@' is that it follows naturally from the ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no operation, and when we don't have those, it makes sens to assume 'HEAD'. So now we can use 'git show @~1', and all that goody goodness. Until now '@' was a valid name, but it conflicts with this idea, so let's make it invalid. Probably very few people, if any, used this name. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-14Revert "Add new @ shortcut for HEAD"Libravatar Junio C Hamano1-2/+0
This reverts commit cdfd94837b27c220f70f032b596ea993d195488f, as it does not just apply to "@" (and forms with modifiers like @{u} applied to it), but also affects e.g. "refs/heads/@/foo", which it shouldn't. The basic idea of giving a short-hand might be good, and the topic can be retried later, but let's revert to avoid affecting existing use cases for now for the upcoming release.
2013-05-08Add new @ shortcut for HEADLibravatar Felipe Contreras1-0/+2
Typing 'HEAD' is tedious, especially when we can use '@' instead. The reason for choosing '@' is that it follows naturally from the ref@op syntax (e.g. HEAD@{u}), except we have no ref, and no operation, and when we don't have those, it makes sens to assume 'HEAD'. So now we can use 'git show @~1', and all that goody goodness. Until now '@' was a valid name, but it conflicts with this idea, so let's make it invalid. Probably very few people, if any, used this name. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08tests: at-combinations: @{N} versus HEAD@{N}Libravatar Ramkumar Ramachandra1-0/+13
All the tests so far check that @{N} is the same as HEAD@{N} (for positive N). However, this is not always the case; write a couple of tests for this. [fc: simplify some wording] Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08tests: at-combinations: increase coverageLibravatar Ramkumar Ramachandra1-0/+8
Add more tests exercising documented functionality. [fc: commit message and extra tests] Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08tests: at-combinations: improve nonsense()Libravatar Felipe Contreras1-1/+1
In some circumstances 'git log' might fail, but not because the @ parsing failed. For example: 'git rev-parse' might succeed and return a bad object, and then 'git log' would fail. The layer we want to test is revision parsing, so let's test that directly. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-08tests: at-combinations: check ref names directlyLibravatar Felipe Contreras1-16/+23
Some committishes might point to the same commit, but through a different ref, that's why it's better to check directly for the ref, rather than the commit message. We can do that by calling rev-parse --symbolic-full-name, and to differentiate the old from the new behavior we add an extra argument to the check() helper. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-05-07tests: at-combinations: simplify setupLibravatar Felipe Contreras1-4/+2
The test is setting up an upstream branch, but there's a much simpler way of doing that: git branch -u. Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-28reject @{-1} not at beginning of object nameLibravatar Jeff King1-1/+1
Something like foo@{-1} is nonsensical, as the @{-N} syntax is reserved for "the Nth last branch", and is not an actual reflog selector. We should not feed such nonsense to approxidate at all. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-28fix parsing of @{-1}@{u} combinationLibravatar Jeff King1-2/+2
Previously interpret_branch_name would see @{-1} and stop parsing, leaving the @{u} as cruft that provoked an error. Instead, we should recurse if there is more to parse. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-01-28test combinations of @{} syntaxLibravatar Jeff King1-0/+51
Now that we have several different types of @{} syntax, it is a good idea to test them together, which reveals some failures. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>