On 1 May 2010 01:02, Sebastian Andres Mancilla Matta <smancill@xxxxxxxxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html