Thread (4 messages) flat view 4 messages, 2 authors, 2016-06-15

Re: [PATCH] git-describe: Die early if there are no possible descriptions

From: Björn Steinbrink <hidden>
Date: 2016-06-15 22:47:09

On 2009.08.05 08:34:12 -0700, Shawn O. Pearce wrote:
Bj?rn Steinbrink [off-list ref] wrote:
quoted
If we found no refs that may be used for git-describe with the current
options, then die early instead of pointlessly walking the whole history.

Signed-off-by: Bj?rn Steinbrink <redacted>
---
In git.git with all the tags dropped, this makes "git describe" go down
from 0.244 to 0.003 seconds for me. This is especially noticeable with
"git submodule" which calls describe with increasing levels of allowed
refs to be matched. Without tags, this means that it walks the whole
history in the submodule twice (first annotated, then plain tags), just
to find out that it can't describe the thing anyway.

I'm not particularly sure about found_names actually counting the found
names, it was just out of the thought that maybe the walking code could
make use of it, but I didn't actually check that and ran out of time, so
I'm sending this version, hoping that it doesn't suck too much.
This seems reasonable to me.  Really you don't need found_names
to be a counter, but could just always set it to 1 every time the
add_to_known_names function is called.  All you care about is that
add_to_known_names was invoked at least once.
OK.
Also, I really think that first paragraph after the --- should
have been part of the commit message.  The message above doesn't
justify the change, even if it is fairly trivial, without that
additional explanation.
Oh, d'oh, that's even what I intended to do (the original commit message
was written in even more of a hurry than the mail itself), but messed
up. Will re-send (also with found_names turned boolean)

Thanks,
Björn
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help