On Thu, Feb 20, 2020 at 7:59 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Matheus Tavares Bernardino <matheus.bernardino@xxxxxx> writes: > > > I now this is just an illustration, but shouldn't this example be "git > > describe --contains v1.0-bob~1"? > > No, none of the patches discussed in this thread would not affect > anything in --contains (as it is a completely different program). Ok, thanks for the clarification. > > Another case that came to my mind is when the user runs `git describe > > --abrev=0 HEAD` and v1.0-bob points to HEAD~. In this case, v1.0 will > > be displayed without suffix,... > > In this case, v1.0-1- is followed by the full object name, I think. I might be doing something wrong, but this is how I tried to test this: First I set the desired scenario with: $ git tag -am "" v1.0 HEAD~ $ mv .git/refs/tags/v1.0 .git/refs/tags/v1.0-bob Then, running git-describe on v1.0-bob^0 I got what we want, which is the forced long output (even with --abbrev=0): $ git describe --abbrev=0 HEAD~ warning: tag 'v1.0-bob' is externally known as 'v1.0' v1.0-0-g310a1f27be54ecf16fd36ff987304c1a2f8524b5 But running on the commit after v1.0-bob^0, I got: $ git describe --abbrev=0 HEAD warning: tag 'v1.0-bob' is externally known as 'v1.0' v1.0 Then we cannot directly use the output. I think we can fix this forcing the long output for this case as well, which can be done with: diff --git a/builtin/describe.c b/builtin/describe.c index 5e8484f654..f71bddff4a 100644 --- a/builtin/describe.c +++ b/builtin/describe.c @@ -452,7 +452,7 @@ static void describe_commit(struct object_id *oid, struct strbuf *dst) } append_name(all_matches[0].name, dst); - if (abbrev) + if (all_matches[0].name->misnamed || abbrev) append_suffix(all_matches[0].depth, &cmit->object.oid, dst); if (suffix) strbuf_addstr(dst, suffix);
