Re: [PATCH] describe: make '--always' fallback work after '--exact-match' failed
SZEDER Gábor sze...@ira.uka.de writes: Quoting Junio C Hamano gits...@pobox.com: Well, that can be argued both ways. ... 'git describe' errors out by default if it can't describe the given commit. Yes. describe always fails when it cannot produce an acceptable description. And --always and --exact-match are two incompatible ways for users to change what is considered an acceptable description. - With --exact-match and --always, the definition of acceptable changes: by default, only a name based on some anchor point is acceptable. - --always loosens the definition and also allows an abbreviated commit object name as acceptable. - --exact-match tightens the definition. In addition to only a name based on some anchor point is acceptable, it requires that based on to be 0 distance from the anchor point. The help text says succinctly: *ONLY* output exact matches. If you allow a request with --exact-match to show something that is not an exact match, that no longer is --exact-match. Allowing to mix --always to that option breaks it, as what the command does no longer is to only outputs exact matches. - One option --exact-match says that it is wrong to show anything but exact matches. - The other option --always says it is willing to show a name that is not an exact match. These are competing goals. You give preference to the latter, but that is not the only valid point of view. And that is why I said it can be argued both ways. I think these two are fundamentally incompatible. [Footnote] *1* Other parts of 'describe' only considers a name based on some anchor point as acceptable. are also modified by various options: - With --contains, the definition of based on changes direction: a commit may be described as somewhere ahead of an anchor point by default, but can be described as somewhere behind of an anchor point. - With --all and --tags, the definition of anchor point changes: by default, only annotated tags are possible anchor points. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] describe: make '--always' fallback work after '--exact-match' failed
Quoting Junio C Hamano gits...@pobox.com: SZEDER Gábor sze...@ira.uka.de writes: 'git describe [...] --always' should always show the unique abbreviated object name as a fallback when the given commit cannot be described with the given set of options, see da2478dbb0 (describe --always: fall back to showing an abbreviated object name, 2008-03-02). However, this is not the case when the combination '--exact-match --always' is given and the commit cannot be described, because in such cases 'git describe' errors out, as if '--always' were not given at all. Respect '--always' and print the unique abbreviated object name instead of erroring out when the commit cannot be described with '--exact-match --always'. Signed-off-by: SZEDER Gábor sze...@ira.uka.de Well, that can be argued both ways. Your patch introduces a regression, as --exact-match is an instruction to error out when no tag exactly matches, and you deliberately break that. This patch doesn't break '--exact-match', in fact doesn't modify it at all when it's on its own or combined with other options, but it makes '--exact-match --always' finally work. 'git describe' errors out by default if it can't describe the given commit. So if a user wants an exact match or an error otherwise, then he should not give '--always' at all, because that's the instruction to not error out but give the abbreviated object name instead. Why should '--exact-match' be any different from the other options that tell 'git describe' what to use for the description? Why should '--always' not work with '--exact-match', when it works in the other cases? Consider '--contains': it should find a tag that comes after the given commit or error out if such a tag doesn't exist. Now, in current git.git: $ git describe --contains master fatal: cannot describe 'ff86faf2fa02bc21933c9e1dcc75c8d81b3e104a' $ git describe --contains --always master ff86faf2fa Or the default behavior without any options: it should find a tag reachable from the given commit or error out, but what if we pass in a commit before the first tag? It recommends '--always': $ git describe e83c516 fatal: No tags can describe 'e83c5163316f89bfbde7d9ab23ca2e25604af290'. Try --always, or create some tags. $ git describe --always e83c516 e83c516331 My knee-jerk reaction is that the most sensible way forward is to make --exact-match and --always mutually incompatible. That would be wrong, it's perfectly valid to ask for an exactly matching tag or, if there is no such tag, the abbreviated object name as a fallback. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] describe: make '--always' fallback work after '--exact-match' failed
SZEDER Gábor sze...@ira.uka.de writes: 'git describe [...] --always' should always show the unique abbreviated object name as a fallback when the given commit cannot be described with the given set of options, see da2478dbb0 (describe --always: fall back to showing an abbreviated object name, 2008-03-02). However, this is not the case when the combination '--exact-match --always' is given and the commit cannot be described, because in such cases 'git describe' errors out, as if '--always' were not given at all. Respect '--always' and print the unique abbreviated object name instead of erroring out when the commit cannot be described with '--exact-match --always'. Signed-off-by: SZEDER Gábor sze...@ira.uka.de Well, that can be argued both ways. Your patch introduces a regression, as --exact-match is an instruction to error out when no tag exactly matches, and you deliberately break that. My knee-jerk reaction is that the most sensible way forward is to make --exact-match and --always mutually incompatible. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
