Integration-Manager Workflow and merges

Hello.

I am working with the Physics Department of my university, and I convinced them to use Git for our project of particle analysis (all the physicists work whit CVS or things like that, so I am very glad they liked Git and accepted it).

So, I am in charge of defining the workflow we are going to use (we are a team of 6 to 10 developers). We will use two branches, the 'master' branch has stable code, and all the work is done in the 'devel' branch.

I want to use the Integration-Manager workflow, but I have some issues about it. Suppose we have a blessed repository with the following state for the 'devel' branch

         BLESSED (public)

         1--2--3     devel

and some developer (Dev1) has a clone of it, and his 'devel' branch and the 'blessed/devel' branch point to the same commit

         DEVELOPER (private)

         1--2--3     devel

This developer does some work and obtains

         DEVELOPER (private)

         1---2---3             blesed/devel
                  \
                   4---5---6   devel

but in the meantime, other developer works on his own, and pushes their changes to his public repository, and the maintainer accepts them and pushes them to the blessed repository:

         BLESSED (public)

         1---2---3---7---8      devel

Now Dev1 pushes his changes to his public repository and sends a pull request to the maintainer. To this point, everything is fine.

Later, Dev1 wants to continue his works, but he needs the changes made by the other developer. So, he fetches the blessed repository

         DEVELOPER (private)

         1---2---3---7---8      blessed/devel
                  \
                   4---5---6    devel

but the maintainer has not accepted his changes yet, so blessed/devel's tip does not include public devel's tip of Dev1. The developer decides to merge 'blessed/devel', and work from that commit, and obtains

         DEVELOPER (private)

         1---2---3-------7---8                blessed/devel
                  \           \
                   \           9---10---11    devel
                    \         /
                     4---5---6                origin/devel

with the commit 9 being the merge commit. In the meantime, the maintainer sees the pull request of Dev1, and pulls his changes and accepts them, and updates the blessed repository

         BLESSED (public)

         1---2---3---7---8---12    devel
                  \         /
                   4---5---6

with the commit 12 being the maintainer merge commit.

And this is my problem. We have two differents commits (9 and 12) doing the same thing. If Dev1 pushes his changes again, and sends a new pull request, what will be the state of the repository? I think it will look like this at the end

         1---2---3-----7----8--12-----------13   devel
                  \          \/            /
                   \         /\           /
                    4---5---6--9---10---11

but the history is a mess with those two merges doing the same. And this is only with one developer doing a merge. If all the others do the same, it will become a pain.

Can you help me with some guidelines to solve this? We do not want to keep a linear history doing rebase every time. We just want to avoid those duplicated merges. I have been looking for similar workflows but there is no useful information, or at least I have not found it.

I think the solution is to forbid developers doing merges in the 'devel' branch. Only the maintainer merges remotes branches. So the merge is done in a temporal branch, and the work is done in a topic branch

         DEVELOPER (private)

         1---2---3-----7-----8                blessed/devel
                  \           \
                   4---5---6   \              devel
                            \   \
                             ----9            tmpMerge
                                  \
                                   10---11    topic

then, after the maintainer accepted the first pull request, Dev1 fetches the blessed repository, obtaining the merge commit 12. Then he merges the branch 'blessed/devel' into his 'devel' branch (this is just a fast-forward merge)

         DEVELOPER (private)

         1---2---3-----7----8--12             devel -  blessed/devel
                  \          \/
                   \         /\
                    4---5---6--9              tmpMerge
                                \
                                 10---11      topic

and finally he rebases the 'topic' branch onto 'devel'

         DEVELOPER (private)

         1---2---3---7---8---12               blessed/devel
                  \         /  \
                   4---5---6    20---21       devel

and pushes his work and sends a pull request to the maintainer. For both, the maintainer and the developer, the repository looks like this at the end (after the maintainer accepts Dev1's changes)

         1---2---3---7---8---12---20---21   devel
                  \         /
                   4---5---6

This way, there is no duplicated merges. Is this a good workflow? Can anyone using a similar approach give me some comments?

Thanks.

On 1 May 2010 01:02, Sebastian Andres Mancilla Matta <smancill@alumnos.inf.utfsm.cl> wrote:

As far as I know git will not do a second same merge.

I'm not good at these but IMHO commit 10 will be a criss-cross merge of just 9 & (8,12). Git knows that it has commit 7 in the branch with tip 11.

Try out this on the command-line and notice which parents are listed in the $git log or use gitk to see how git merged stuff. Also run gitk on large compex repositories to see how all the different merges get done.

History is a mess by definition =) git doesn't care or assume that any branch is more important than the other ;-)

I don't understand what kind of pain does this cause? doing $ git log devel..HEAD will show you just the outstanding commit Nr11 =)

With regards,

Dmitrijs.

On 1 May 2010 01:02, Sebastian Andres Mancilla Matta <smancill@alumnos.inf.utfsm.cl> wrote:

Don't worry about duplicate merges. Allow everyone to pull from each other =)

The "duplicate" merge will not make you to resolve the same conflicts again if you are worried about that.