Re: Should notes handle replace commits?

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 8, 2016, 20:09 UTC
Message-ID: <xmqqh9in25py.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160108012830.GA2110@glandium.org>

Mike Hommey <mh@glandium.org> writes:

> Assuming that the "first" commit on master is the same as the "real
> third" on old, you can graft with:
>
>   $ git rev-parse master~ old | xargs > .git/info/grafts

With "graft", you told Git that the parent of master~1 ("second") is not master~2 ("third") but is old ("real third").

Show 7 quoted lines

> And then:
>   $ git log master --format='%s - %N'
>   third - third note
>
>   second - second note
>
>   real third - real third note

So it is expected that after "second" you see "real third", as you are seeing the "real third" with its notes.

> Now, if you try to do the same with replace:
>
>   $ rm .git/info/grafts
>   $ git replace master~2 old

With "replace", you told Git that the contents (i.e. message, tree, etc.) of master~2 ("first") is not what it really is but is what appears in old ("real third").

Show 6 quoted lines

>   $ git log master --format='%s - %N'
>   third - third note
>
>   second - second note
>
>   real third - first note

Hence Git tries to show master~2, i.e. "first", here; its contents is replaced with that of "real third", but the object name of the commit shown after "second" is shown, as far as Git is concerned, is still that of "first", so it is not surprising that the note that is associated with it is shown here, as the whole point of "notes" is that it is kept outside the contents recorded _in_ the commit.

Show 6 quoted lines

>   real second - real second note
>
>   real first - real first note
>
> Note how "real third" now has "first note", instead of "real third
> note".

So it is not a correct observation that '"real third" now has "first note"'. You are still seeing "first", but its message, together with its tree and its parents, are replaced by those of "real third".

> So the question is, is this the behavior this should have?

The behaviour is a natural consequence of what graft and replace are about (i.e. "telling Git what the parents of a commit are" vs "telling Git what the contents of a commit are"), so the answer to the "should" question is a resounding "yes".

It is a separate issue if the behaviour is useful for the purpose you wanted to use "replace" for.