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

> Alban Gruin <alban.gruin@gmail.com> writes:
> 
> > 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."