Hi Peff,
On Tue, 9 Jan 2018, Jeff King wrote:
> On Mon, Jan 08, 2018 at 02:43:00PM +0100, Johannes Schindelin wrote:
>
> > Take the interactive rebase for example. It generates todo lists with
> > abbreviated commit names, for readability (and it is *really* important to
> > keep this readable). As we expect new objects to be introduced by the
> > interactive rebase, we convert that todo list to unabbreviated commit
> > names before executing the interactive rebase.
> >
> > Your idea (to not care about unambiguous abbreviations) would break that.
>
> I think that could be easily worked around for rebase by asking git to
> check ambiguity during the conversion.
Sure.
It also points to a flaw in your reasoning, and you should take my example
further: previously, we guaranteed unique abbreviations, and who is to say
that there is no script out there relying on that guarantee? You?
> But I agree it's a potential problem for other scripts that we might not
> have control over. I hadn't really intended this to be the default
> behavior (my patch was just trying to show the direction). But it does
> make for a pretty awful interface if callers have to opt into it
> manually ("git log --oneline --no-really-go-fast").
Exactly.
> I am a bit curious if there's a bounded probability that people would
> find acceptable for Git to give an ambiguous abbreviation. We already
> accept 1 in 2^160, of course. But would, e.g., one in a million be OK?
What is that going to solve?
I think a better alternative would be to introduce a new abbreviation mode
that is *intended* to stop caring about unique abbreviations.
In web interfaces, for example, it makes tons of sense to show, say, 8
digits in link texts and have the full name in the actual link URL.
Currently, we have no way to tell Git: look, I want to have a short label
for this, but I do not really care that this is unambiguous, I just want
something to talk about.
(And you are correct, of course, that the uniqueness of abbreviations will
no longer be guaranteed for partial clones, and it is already not
guaranteed for shallow clones, and it will only be possible to guarantee
this, ever, for one particular repository at a particular time.)
I am just hesitant to change things that would break existing setups.
Just to throw this out there: --abbrev=8! would be one possible convention
to state "I want exactly 8 hex digits, don't bother checking for
uniqueness".
Not sure how urgent such a feature is.
Ciao,
Dscho
