Re: VCS comparison table

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

 



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Linus Torvalds wrote:
> 
> On Tue, 17 Oct 2006, Aaron Bentley wrote:
>>> Excuse me? What does that "throws away your local commit ordering" mean?
>> Say this is the ordering in branch A:
>>
>> a
>> |
>> b
>> |
>> c
>>
>> Say this is the ordering in branch B:
>>
>> a
>> |
>> b
>> |\
>> d c
>> |/
>> e
>>
>> When A pulls B, it gets the same ordering as B has.  If B did not have e
>> and c, the pull would fail.
> 
> Sure. But that doesn't throw away any local commit ordering. The original 
> order (a->b->c) is still very much there.

After the pull, it's no longer the mainline ordering for the branch.  c
is represented a revision that was merged into the branch, while d is
represented as a commit on the mainline of the branch.

> The fact that there was a branch 
> off 'b' and there is also (a->b->d) and a merge of the two at 'e' doesn't 
> take away anything from the original local commit ordering.

It means the the order that revisions are shown in log commands changes,
and the revision numbers can change.

> But that's a totally specious "record". It has no meaning in a distributed 
> SCM. There is absolutely zero semantic information in it.

It records the committer, the date, the commit message, the parent
revisions.

> The fact that you _locally_ want to remember where you were is a total 
> non-issue for a true distributed system. You shouldn't force everybody 
> else to see your local view - since it has no relevance to them, and 
> doesn't add any information.

Nobody is forced to use your local view.

> In other words, the empty merge is totally semantically empty even in the 
> bazaar world. Why does it exist?

It exists because it is useful.  Because it makes the behavior of bzr
merge uniform.  Because in some workflows, commits show that a person
has signed off on a change.

It's not something special-- it's just another commit, like regular
commits, and merge commits.  It would be harder to forbid than it is to
permit.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFNXQQ0F+nu1YWqI0RAnxDAJ4hbuLkEK1eBlyoEOz7NAlqLVth9gCfed4w
nfeiR2KVvN+N9zdSrC8MKcY=
=et73
-----END PGP SIGNATURE-----
-
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]