Aaron Bentley wrote:
> 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.
Well, that is another example while generation number is/can be global,
any numbering of branches must be local-only.
> > 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,
That doesn't matter...
> and the revision numbers can change.
...but that means that revision numers are totally, absolutely useless.
Unless by some miracle of engineering, or adding namespace, they can be
made unchangeable.
> > 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.
All totally empty information. What should be commit message? I have
fetched changes from remote repository? You can remove one of parents
(the one of pointing to before fast-forward "merge") without changing
reachability.
---------
/ \
*--*---x---*---*---y---*
> > 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.
But if you record "fast-forward merge", you force all people pulling
from your repository to have this purely local and without any significant
information "I have fetched then" marker.
> > 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.
Signing off the fact of fetching changes? For true merge you are signing
off the fact that there were no conflicts, or you sign off your conflict
resolution.
> 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.
Actualy the check is very easy. And you have to do similar check when
fetchin/pushing to ensure that you don't clobber your changes.
--
Jakub Narebski
Poland
-
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