Re: [PATCH v3 4/8] rebase: store orig_head as a commit

From: Phillip Wood <phillip.wood123@gmail.com>
Date: Oct 13, 2022, 20:49 UTC
Message-ID: <3a234ed2-5540-2109-80d7-dd48fc420841@dunelm.org.uk>
In-Reply-To: <xmqqilknhed6.fsf@gitster.g>

Hi Junio

On 13/10/2022 17:34, Junio C Hamano wrote:

Show 18 quoted lines

> "Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> To avoid changing the behavior of "git rebase <upstream> <branch>" we
>> keep the existing call to read_ref() and use lookup_commit_reference()
>> on the oid returned by that rather than calling
>> lookup_commit_reference_by_name() which applies the ref dwim rules to
>> its argument.
> 
> I agree with the above in that _by_name was an overly broad and
> wrong function to call.  But ...
> 
>> lookup_commit_reference() will dereference tag objects
>> but we do not expect the branch being rebased to be pointing to a tag
>> object.
> 
> ... if we do not expect to see a tag object, why call _reference()
> in the first place?  Does lookup_commit() not work for the purpose
> of this code?

I was wasn't convinced that the tag dereferencing was the only difference between lookup_commit_reference() and lookup_commit(). lookup_commit() calls lookup_object() and if the object is not in the parsed objects hash table it creates a new commit object with the given oid without checking if the object exists. lookup_commit_reference() calls parse_object() which handles replacement objects and checks the object actually exists.

Best Wishes

Phillip