octave-maintainers
[Top][All Lists]
Advanced

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

Re: How to merge and push?


From: John W. Eaton
Subject: Re: How to merge and push?
Date: Tue, 16 Mar 2010 13:14:48 -0400

On 16-Mar-2010, Rik wrote:

| It would also be clearer if Mercurial identified with a symbol whether
| there was a collision during the merge or not.  Nearly 100% of the "merges"
| I checked in were only for the benefit of Mercurial.  I did not actually
| need to make a choice about which code would stay in the repository and
| which would get deleted.

OK, that's good to know.  If mercurial could tell me that, then I
might be more comfortable with a non-linear revision history.  But as
it is now, it is not possible to tell whether this is the case, and
for a merge like the one you made, the merge changeset is large, and
it is difficult to look at that and know whether some of the changes
undid other changes (i.e., the person doing the merge had to decide
which branch to use and selected the wrong one, or made some other
incorrect edit when merging).  If I don't know what happened during
the merge, I have no confidence that it was done correctly.

Yes, it is possible that any given changeset can undo someone elses
changes, or be incorrect in some other way, but typically they are
small, confined to a single concept, and relatively easy to verify.

Do any of the current DVCSs have a feature like you describe, that
will tell if a merge was clean or required conflict resolution?  Does
no one else see a use for a feature like that?  If not, why not?

And, in case it isn't clear, I'm not faulting you for the merge you
made.  I don't think we alerted you to the preference before you did
it, and in any case, it didn't cause any real harm.

| I agree.  It is not too much trouble to use rebase or patch queues right
| now.  But, if you were to put this to a vote it seems that all of the
| really big coding projects have voted to move towards distributed source
| control systems with non-linear commit trees.

I'm open to reconsidering in the future, but I think it is relatively
easy to keep the public archive linear for now, and that makes it
easier to understand what the changes are doing.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]