Re: Should notes handle replace commits?

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

 



Mike Hommey <mh@xxxxxxxxxxxx> writes:

> On Fri, Jan 08, 2016 at 12:09:45PM -0800, Junio C Hamano wrote:
>> > 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's not only about contents, except for a very broad definition of
> contents that includes ancestry.

That is not broad at all.  A Git commit knows about its parents in
exactly the same way as it knows about its tree and its own log
message.  Hashing all of them together, without considering which
part is "broad", gives us the content-addressible filesystem, which
is "stupid content tracker", aka Git.

Perhaps you would see what is going on more clearly if you replace
your "git log" with "git rev-list".

If your pre-graft/pre-replace histories were

	A (first)  <--- B (second)  <--- C (third)	master
	X (rFirst) <--- Y (rSecond) <--- Z (rThird)	old

then your "graft" tells Git "B's parent is Z, not A.  If you run
"rev-list master", it will give you "C B Z Y X".  The discrepancy
(relative to the true history) brought in by "grafting" is that
nowhere in "cat-file commit B" you would find Z, even though "log"
and "rev-list" pretends as if Z is a (and the) parent of B.

Your "replace" tells Git "A records what Z records".  If you run
"rev-list master", it will give you "C B A Y X".

A fake history made by "replace" does not have the same discrepancy
as "grafting"; "cat-file commit B" names A as its parent, and asking
what A is gives what actually is in Z, i.e. "cat-file commit A"
shows what "cat-file commit Z" would give you.  The discrepancy with
the reality "replacing" gives you is that hashing what you got from
"cat-file commit A" does not hash to A (it obviously has to hash to
Z).

> From my POV, replace is more about
> "telling Git that this commit (and its parents) is really that one (and
> its parents)".

Your "POV" does not match reality; replace is about telling Git to
give contents recorded for object Z when anybody asks the contents
recorded for object A.
--
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]