Re: Should notes handle replace commits?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mike Hommey <mh@xxxxxxxxxxxx> 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").

> 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").

>   $ 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.

>   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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]