Re: Integration-Manager Workflow and merges

[Dmitrijs Ledkovs <dmitrij.ledkov@ubuntu.com>]

On 1 May 2010 01:02, Sebastian Andres Mancilla Matta
<smancill@alumnos.inf.utfsm.cl> wrote:
> 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.