Re: [PATCH 1/4] rebase -i: demonstrate obscure loose object cache bug
To
Ævar Arnfjörð Bjarmason
Cc
Johannes Schindelin via GitGitGadget
git@vger.kernel.org
Junio C Hamano
Johannes Schindelin
From
Jeff King
See Also
Prev Ref 1 Ref 2
Date
2019-03-13 16:35:16 UTC
On Wed, Mar 13, 2019 at 05:11:44PM +0100, Ævar Arnfjörð Bjarmason wrote:

> > And this is where the loose object cache interferes with this feature:
> > if *some* loose object was read whose hash shares the same first two
> > digits with a commit that was not yet created when that loose object was
> > created, then we fail to find that new commit by its short name in
> > `get_oid()`, and the interactive rebase fails with an obscure error
> > message like:
> >
> > 	error: invalid line 1: pick 6568fef
> > 	error: please fix this using 'git rebase --edit-todo'.

Are we 100% sure this part is necessary? From my understanding of the
problem, even without any ambiguity get_oid() could fail due to just
plain not finding the object in question.

> As a further improvement, is there a good reason for why we wouldn't
> pass something down to the oid machinery to say "we're only interested
> in commits". I have a WIP series somewhere to generalize that more, but
> e.g.  here locally:

We have get_oid_commit() and get_oid_committish() already. Should rebase
just be using those? (I think we probably want "commit()", because we do
not expect a "pick" line to have a tag, for example.

-Peff