Hello,
using git describe on Linus' sparse repo results in:
uzeisberger@io:~/gsrc/sparse$ git describe
fatal: cannot describe '62ac6c16058aba8693fd5827379debc5f57b60f5'
The reason is, that there exist no tags at all, so right, there is no
"most recent tag that is reachable from HEAD".
I wonder if it would be sane to assume an implicit tag for the empty
repository, s.t. git describe results in
<empty>-62ac6c16
(whatever name is choosen for <empty>).
Any opinions?
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=1+degree+celsius+in+kelvin
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:17
Uwe Zeisberger [off-list ref] writes:
I wonder if it would be sane to assume an implicit tag for the empty
repository, s.t. git describe results in
<empty>-62ac6c16
(whatever name is choosen for <empty>).
Any opinions?
The value of 'describe' is not in the 62ac6c part, but in the
tag part, which lets us find out that the rev in question is at
least newer than that tag. If the reason you are doing
"describe" is to find out an usable abbreviated name, you could
feed the first few hexdigits to "git rev-parse --verify",
lengthening the prefix longer by one until it says you have a
unique prefix [*1*].
In other words, not particularly interested, although it is
trivial to implement, like this:
[Footnote]
*1* If you do this often, we could introduce
$ git rev-parse --abbrev=<n> HEAD
that quacks like --verify (i.e. makes sure there is a single
"extended SHA1 expression" that evaluates to a valid object
name) but outputs the result abbreviated to at least <n>
hexdigits.
This has an added advantage that it would work on a
non-commit object name.
-- >8 --
[PATCH] rev-parse: --abbrev option.
The new option behaves just like --verify, but outputs an
abbreviated object name that is unique within the repository.
Signed-off-by: Junio C Hamano <redacted>
---
rev-parse.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
3c7c31a913c3c4060e85f2919e2136412928dcec
I wonder if it would be sane to assume an implicit tag for the empty
repository, s.t. git describe results in
<empty>-62ac6c16
(whatever name is choosen for <empty>).
Any opinions?
[...] If the reason you are doing "describe" is to find out an usable
abbreviated name, you could feed the first few hexdigits to "git
rev-parse --verify", lengthening the prefix longer by one until it
says you have a unique prefix [*1*].
Yes, I wrote a script that automatically build git and install it to
${HOME}/usr/stow/git-`git describe HEAD` and then stow(8)s it. Writing
a similar script for sparse cannot use git describe because there are no
tags ...
quoted hunk
In other words, not particularly interested, although it is
trivial to implement, like this:
It's a pity your not particularly interested, I like that patch's idea.
git describe dies with an error here in a situation where there is the
possibility to do something sensible.
BTW, for the sake of consistency, I'd suggest
- die("cannot describe '%s'", sha1_to_hex(cmit->object.sha1));
+ printf("g%s\n", find_unique_abbrev(cmit->object.sha1, abbrev));
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=1+year+divided+by+3+in+seconds
@@ -195,6 +198,17 @@ int main(int argc, char **argv)verify=1;continue;}+if(!strcmp(arg,"--abbrev")||+!strncmp(arg,"--abbrev=",9)){+filter&=~(DO_FLAGS|DO_NOREV);+verify=1;+abbrev=DEFAULT_ABBREV;+if(arg[8]=='=')+abbrev=strtoul(arg+9,NULL,10);+if(abbrev<0||40<=abbrev)+abbrev=DEFAULT_ABBREV;+continue;+}if(!strcmp(arg,"--sq")){output_sq=1;continue;
I see two things to fix in that patch:
1) define DEFAULT_ABBREV (e.g. by moving it to cache.h, where
find_unique_abbrev is defined.)
2) describe.c allows only abbrev >= 4. (Allowing values less than 2
failes, because find_short_object_filename (and maybe others) assume
len to be at least 2.) I think 4 is sensible.
This results in the following patch:
--8<--
[PATCH] rev-parse: --abbrev option.
The new option behaves just like --verify, but outputs an abbreviated object
name that is unique within the repository.
This patch is a modification of a suggestion by Junio C Hamano.
Signed-off-by: Uwe Zeisberger <redacted>
---
cache.h | 2 ++
describe.c | 1 -
rev-parse.c | 14 ++++++++++++++
3 files changed, 16 insertions(+), 1 deletions(-)
0d43ec7461b38d6a1d1563fd7dc2ebf399eabe9e
@@ -11,7 +11,6 @@ static const char describe_usage[] =staticintall=0;/* Default to annotated tags only */staticinttags=0;/* But allow any tags if --tags is specified */-#define DEFAULT_ABBREV 8 /* maybe too many */staticintabbrev=DEFAULT_ABBREV;staticintnames=0,allocs=0;
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:17
Uwe Zeisberger [off-list ref] writes:
I see two things to fix in that patch:
1) define DEFAULT_ABBREV (e.g. by moving it to cache.h, where
find_unique_abbrev is defined.)
Sorry, the patch alone was not compilable since cleaning up the
definition of symbolic constants *_ABBREV comes before the patch
you quoted in the "pu" branch.
2) describe.c allows only abbrev >= 4. (Allowing values less than 2
failes, because find_short_object_filename (and maybe others) assume
len to be at least 2.) I think 4 is sensible.
Thanks. "rev-parse --abbrev=2" would have segfaulted without
your fix. I suspect substituting with MINIMUM instead of
DEFAULT in such a case would be more sensible, so...
-- >8 --
[PATCH] rev-parse --abbrev: do not try abbrev shorter than minimum.
We do not allow abbreviation shorter than 4 letters in other
parts of the system so do not attempt to generate such.
Noticed by Uwe Zeisberger.
Signed-off-by: Junio C Hamano <redacted>
---
rev-parse.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
030d25d271adb2671f560b410d77585d8744acbf