Re: If merging that is really fast forwarding creates new commit

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

 



Rocco Rutte wrote:
Hi,

* Liu Yubao [06-11-06 21:00:07 +0800] wrote:

Then, what bad *logical* problem will happen if a merging that is really a fast forwarding creates a new commit?

I don't know what you expect by "logical" nor if I get you right, but if fast-forward merge a branch to another one, both branches now have exactly the same hash. If you create a commit object for a fast-forward merge, both tip hashes not identical anymore... which is bad.
Not so bad, you can know they point to same tree objects.

Fast forwarding style merge will blow away the *track* of your branch,
and this track is useful, that is why reflog appears.

The identical hash important so that you really know they're identical and for future reference like ancestry.
I guess you have mixed identical commits with identical trees. Trees
is what we really need.

Fake commit doesn't mess the ancestry relation, you can refer to
my previous mail replied to Andreas Ericsson in this topic.

  bye, Rocco

-
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]