Re: What's cooking in git.git (Oct 2018, #04; Fri, 19)

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 20, 2018, 23:44 UTC
Message-ID: <xmqqmur8yyi3.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <5f0fb76f-0774-3545-38fc-b86137f747fa@gmail.com>

Alban Gruin <alban.gruin@gmail.com> writes:

Show 7 quoted lines

> The error comes from the call to `git stash apply $stash_id' in
> builtin/rebase.c:261.  When $stash_id only contains decimals and no
> letters, git-stash tries to apply stash@{$stash_id}[0][1].  Thas was not
> a real problem with the shell script, because it did not abbreviate the
> object id of the stashed commit, so it was very unlikely that the oid
> would contain only digits.  builtin/rebase.c shortens the oid[2], making
> this problem more likely to occur.

OK, so make "rebase in C" a faithful conversion of the original, the code that lead to builtin/rebase.c:261 must be fixed not to pass a shortened oid. I suspect that internally it has a full object name, so not shortening would be the right thing anyway, so regaredless of this bug, it probably makes sense to do the fix.

But as you said, even the scripted version that passed the full object name had a (10/16^40) chance of using a 40-hex that only has [0-9] and caused the same breakage, so such a change to "rebase in C" is sweeping the age old bug under the same rug, in the context of discussing this particular bug.

I agree with you that it is a better fix to the problem to allow the caller to say "I am giving an oid---it may (or may not---I do not even bother to check) consist of only digits, but do not treat it as an index to the stash reflog."