[m-dev.] Merge commits

[Paul Bone]

On Sat, Jan 12, 2013 at 01:14:27PM +1100, Matt Giuca wrote:
> [I don't do development on Mercury, so take this advice with a grain of
> salt.]
> 
> Is this advice just for people who are doing local commits to master and
> then pushing them, or also for people working with branches? I can see the
> appeal of trying to rebase remote changes onto a few short local commits,
> and keeping the history clean. But this will end up pretty chaotic for
> anyone who is either a) working on a feature branch long-term, or b) has
> made quite a lot of local commits to master without pushing them for awhile.
> 

A bit of both.  I don't want to introduce people to git too suddenly as it
can be very complicated.  It's important that we understand the basic stuff
and then move onto the advanced stuff.  So developers who arn't certain what
my e-mail is about are free to disregard it.  The same goes for people who
don't feel like reading all the man pages (as I assume they would want to in
order to really 'get it').

Your concerns are completely valid and are likly to come up.  I'll summarize
them and provide some comments.  Your e-mail was long, I noticed two
concerns, I'm sorry if I missed any.

    1) Rebase merging is more complicated since you merge each of your local
       changes with HEAD, not just your changes in one big patch.

       Persionally I find this easier as each change is smaller.  But others
       may find it harder as there are more changes.  So I'll accept that
       this may make things 'harder'.

    2) Rebased commits (eg C1-rebased) may not compile and no-one may
       notice.
       
       <devil's advocate>No one will notice, so who cares?</da>
       
       Seriously though, I don't like this either.  The reason I'm
       seperating C1 and C2 (rather than writing one big C1&2) change is
       that I think there is some value in seperating them, so they should
       work seperately.  I agree that they should perhaps be tested
       independently, and this is a good idea, especially if there was value
       in seperating them.
       
       If two developers are working on the same subsystem then rebasing may
       ge4 arkward quickly.  Developers can do other things with their
       history (rebase some changes, merge others, stow yet other changes
       for later etc).  But a normal merge may be easiest in these cases.

       When changes arn't related, they are less likly to cause errors
       (either textual or semantic) for each other.  So rebasing is probably
       safe.

I don't want to perscribe what standard we adopt as a project.  Peter and I
have been using git for a while (Peter longer than I).  While I suspect that
Julien and Zoltan have not used git much before.  So our main considertation
is finding a solution as a group.  It is certainly unfair if I where to make
the learning experinece for others more complicated than necessary.  So some
of this will be a decision as a group (Maybe an agenda item for our
Meeting?)

In other ways this can be subjective/personal taste.  For example, if we
stipulate that a branching history is okay, then some developers may still
choose to rebase (and test their rebased changes).  I find that this can
make merging easier, so I will probably do this myself, but it will also
depend on circumstance. 

Thanks Matt for your interesting and insightful discussion, it's great to
hear from you.  Would you consider joining our Google+ group (for
users/community, not just developers).

All the best.


-- 
Paul Bone
http://www.bone.id.au