"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes:
> Yes, its very useful. If you get two different describes at different
> times from a non-rewinding branch and they both come up with the same
> tag name, you can tell which is the 'newer' one by distance. This is
> rather common in practice, so its incredibly useful.
>
> Signed-off-by: Shawn O. Pearce <spearce@xxxxxxxxxxx>
> ---
> builtin-describe.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-describe.c b/builtin-describe.c
> index e7b8f95..d8ff621 100644
> --- a/builtin-describe.c
> +++ b/builtin-describe.c
> @@ -189,7 +189,8 @@ static void describe(const char *arg, int last_one)
> sha1_to_hex(gave_up_on->object.sha1));
> }
> }
> - printf("%s-g%s\n", all_matches[0].name->path,
> + printf("%s-%i-g%s\n", all_matches[0].name->path,
> + all_matches[0].depth,
> find_unique_abbrev(cmit->object.sha1, abbrev));
>
> if (!last_one)
Two comments.
- This is purely style, but we seem to prefer %d instead of %i
elsewhere in the code (three existing offenders are
builtin-describe.c, receive-pack.c and sha1_file which we may
want to clean up for consistency).
- How much damage are we talking about with this patch to
People's existing scripts? I expect they all extract the
hash from last -g (because they cannot rely on particular
convention in tagnames), but I am also worried if people are
expecting everything that comes before the last -g is the
whole tag.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html