Re: [PATCH 1/4] rebase -i: demonstrate obscure loose object cache bug
To
Johannes Sixt
Cc
Jeff King
Ævar Arnfjörð Bjarmason
Johannes Schindelin via GitGitGadget
git@vger.kernel.org
Junio C Hamano
From
Johannes Schindelin
See Also
Prev Ref 1 Ref 2 Ref 3 Ref 4
Date
2019-03-14 13:06:31 UTC
Hi Hannes,

On Thu, 14 Mar 2019, Johannes Sixt wrote:

> Am 13.03.19 um 17:35 schrieb Jeff King:
> > On Wed, Mar 13, 2019 at 05:11:44PM +0100, Ævar Arnfjörð Bjarmason wrote:
> >> 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.
> 
> 'pick' needs all the power of revision expressions. Not all too
> infrequently I do insert a pick line with a rev expression argument.
> Assuming that the resolved object is a commit is too strict.

No need to worry. `get_oid_committish()` can resolve all kinds of crazy
expressions. In a way, it is surprising that it will even resolve
"HEAD:Makefile". The only thing (that I know of) that
`get_oid_committish()` does that `get_oid()` does not is when you pass a
short hash which is unambiguous *only* when you exclude blobs and trees
from the disambiguation.

So I think `get_oid_committish()` will serve us really well, as we really
want to parse the given hash name into the `struct todo_item`'s `commit`
field.

Ciao,
Dscho