What is our preferred gitorious workflow wrt merges and pushes?

Alexander Dymo alexander.dymo at gmail.com
Sun Oct 10 12:55:49 UTC 2010


Hey,
I'm about to merge some stuff back to kdevelop repository and I'd like to  
clarify our preferred policy wrt merges.

==
Note: pls read this email with fixed-width font. If you can't, same  
properly formatted text is on:
http://www.kdevelop.org/mediawiki/index.php/User:Adymo
==

Question is do I need to rebase my changes on top of kdevelop/master and  
then push to avoid merge commits
or it's ok to merge kdevelop/master into my branches (creating merge  
commits) and then push that.

Detailed explanation:
Say, I have:
- kdevelop repo, master branch
- adymo-kdevelop repo, clone of kdevelop repo, master branch
- mylocal repo, clone of adymo-kdevelop, master branch

Say, kdevelop repo had three commits before clone. And this is how mylocal  
repo looks like:

A - B - C
         |
         master, adymo-kdevelop/master, kdevelop/master

Now I'm going to do some work and create a "mybranch" for that. I do two  
commits (D and E).
I also push this branch to adymo-kdevelop so that other people can look at  
it and try.


         master, adymo-kdevelop/master, kdevelop/master
         |
A - B - C
          \
           D - E
               |
               mybranch, adymo-kdevelop/mybranch


Meanwhile, kdevelop/master changed:

         master, adymo-kdevelop/master
         |   kdevelop/master
         |   |
A - B - C - X
          \
           D - E
               |
               mybranch, adymo-kdevelop/mybranch


My changes are ready and I want to merge them back. And here I have two  
options:


== Option A: use rebase ==
A1) merge kdevelop/master into master, rebase my changes on top of master,  
push them to adymo-kdevelop


             master, adymo-kdevelop/master, kdevelop/master
             |
A - B - C - X
          \   \
           \   D' - E'
            \       |
             \      mybranch
              \
               D - E
                   |
                   adymo-kdevelop/mybranch

Note how adymo-kdevelop/mybranch now looks like. Rebase will change  
commits D and E and
I can't do fast-forward merge from mybranch to adymo-kdevelop/mybranch.
"git push adymo-kdevelop mybranch" will fail.
I'll have to do one of
- "git push --force adymo-kdevelop mybranch" (creating dangling commits  
for git gc to collect)
- "git push --mirror adymo-kdevelop" (rewriting the history of all  
branches in my repo)
- just remove this branch from adymo-kdevelop (only sensible if I'm going  
to push to kdevelop/master soon,
but very bad if I'm not ready yet and just porting my code to recent  
changes in kdevelop/master)


A2) merge mybranch into master, push to kdevelop/master and  
adymo-kdevelop/master,
resulting in the fast-forward merge and linear history:

A - B - C - X
              \
               D' - E'
                    |
                    mybranch, master, adymo-kdevelop/master


== Option B: use merge and merge commits ==

B1) merge kdevelop/master into master

             master, adymo-kdevelop/master, kdevelop/master
             |
A - B - C - X
          \
           D - E
               |
               mybranch, adymo-kdevelop/mybranch

B2) merge master into mybranch, creating a merge commit "F"

                 master, adymo-kdevelop/master, kdevelop/master
                 |
A - B - C ----- X
          \       \
           D - E - F
               |   |
               |   mybranch
               adymo-kdevelop/mybranch

Note, unlike (A1) this doesn't introduce any problems with pushing  
mybranch to adymo-kdevelop,
because that will result in fast-forward from E to F on adymo-kdevelop.  
That's good.

B3) merge mybranch into master, push to kdevelop/master and  
adymo-kdevelop/master

A - B - C ----- X
          \       \
           D - E - F
                   |
                   mybranch, adymo-kdevelop/mybranch, master,  
adymo-kdevelop/master, kdevelop/master

But, unlike (A2), the history of kdevelop/master will no longer be linear,
making it potentially harder to see what and how changed.

==================================================================

So, what scheme do you guys already use? What would you prefer to use?




More information about the KDevelop-devel mailing list