kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Johannes Schindelin	8facec08fe	mingw: skip test in t1508 that fails due to path conversion In Git for Windows, the MSYS2 POSIX emulation layer used by the Bash converts command-line arguments that looks like they refer to a POSIX path containing a file list (i.e. @<absolute-path>) into a Windows path equivalent when calling non-MSYS2 executables, such as git.exe. Let's just skip the test that uses the parameter `@/at-test` that confuses the MSYS2 runtime. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>	9 years ago
Jeff King	8cd4249c4c	interpret_branch_name: always respect "namelen" parameter interpret_branch_name gets passed a "name" buffer to parse, along with a "namelen" parameter representing its length. If "namelen" is zero, we fallback to the NUL-terminated string-length of "name". However, it does not necessarily follow that if we have gotten a non-zero "namelen", it is the NUL-terminated string-length of "name". E.g., when get_sha1() is parsing "foo:bar", we will be asked to operate only on the first three characters. Yet in interpret_branch_name and its helpers, we use string functions like strchr() to operate on "name", looking past the length we were given. This can result in us mis-parsing object names. We should instead be limiting our search to "namelen" bytes. There are three distinct types of object names this patch addresses: - The intrepret_empty_at helper uses strchr to find the next @-expression after our potential empty-at. In an expression like "@:foo@bar", it erroneously thinks that the second "@" is relevant, even if we were asked only to look at the first character. This case is easy to trigger (and we test it in this patch). - When finding the initial @-mark for @{upstream}, we use strchr. This means we might treat "foo:@{upstream}" as the upstream for "foo:", even though we were asked only to look at "foo". We cannot test this one in practice, because it is masked by another bug (which is fixed in the next patch). - The interpret_nth_prior_checkout helper did not receive the name length at all. This turns out not to be a problem in practice, though, because its parsing is so limited: it always starts from the far-left of the string, and will not tolerate a colon (which is currently the only way to get a smaller-than-strlen "namelen"). However, it's still worth fixing to make the code more obviously correct, and to future-proof us against callers with more exotic buffers. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	11 years ago
Felipe Contreras	9ba89f484e	Add new @ shortcut for HEAD 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>	12 years ago
Junio C Hamano	2c2b6646c2	Revert "Add new @ shortcut for HEAD" This reverts commit `cdfd94837b`, 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.	12 years ago
Felipe Contreras	cdfd94837b	Add new @ shortcut for HEAD 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>	12 years ago
Ramkumar Ramachandra	723b74ee3e	tests: at-combinations: @{N} versus HEAD@{N} 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>	12 years ago
Ramkumar Ramachandra	f58dc19e57	tests: at-combinations: increase coverage 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>	12 years ago
Felipe Contreras	89d5dd4e2f	tests: at-combinations: improve nonsense() 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>	12 years ago
Felipe Contreras	c8a81e90ac	tests: at-combinations: check ref names directly 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>	12 years ago
Felipe Contreras	1bc6d022b7	tests: at-combinations: simplify setup 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>	12 years ago
Jeff King	12a258c078	reject @{-1} not at beginning of object name 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>	15 years ago
Jeff King	d46a830193	fix parsing of @{-1}@{u} combination 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>	15 years ago
Jeff King	42cab601cf	test combinations of @{} syntax 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>	15 years ago

13 Commits (a7fbf12f2f31cb5aefb4fe7f467564be32c62968)