Re: Integration-Manager Workflow and merges

From: Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>
Date: May 1, 2010, 04:40 UTC
Message-ID: <y2g86ecb3c71004302140p43c2a778xe3015192e5227dae@mail.gmail.com>
In-Reply-To: <4BDB6FA1.4070802@alumnos.inf.utfsm.cl>

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

Show 15 quoted lines

> 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.
>
>

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.