On Wed, Mar 19, 2008 at 1:20 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > +The following shows master and three topic branches. TopicB is based > > +on TopicA, TopicA is previously branched off from master, and TopicC > > +is based on the current `HEAD` of master: > > + > > +------------ > > + o---o---o TopicB > > + / > > + o---o---o TopicA > > + / > > + o---o---o---o---o---o master > > + \ > > + o---o TopicC > > +------------ > > I'd provide first simpler example without 'TopicC'. If we are to explain how this is recorded this is how simple we can make it without leaving anything out. However, I am not sure we should have this in the documentation at all. Most users probably don't care exactly how this is recorded as long as the history down the road is not to complicated. > If I understand correctly you have implemented here always using > "parent" (or "dependent") reduction of merge heads. IMHO this reduction > contradict stated idea of using --ff=never (--no-ff) to always mark > where topic branch has ended. When using --ff=never this reduction will not be done and that is also how current git works (except that you need to say --no-ff). > > + % git co master > > + % git merge TopicA TopicB TopicC > > + > > + o---o---o TopicB > > + / \ > > + o---o---o TopicA \ > > + / \ > > + o---o---o---o---o---o.......o master > > + \ / > > + o---o TopicC > > +------------ > > This... is a bit unexpected. I thought that there should be line where > I have added dotted line. The graph also describes how current git record this. Try the example and see for yourself. The main difference between the patch and current git is that the patch is trying to be smarter about how it selects the merge algorithm, and which commits are passed on to the real merge algorithm. In the example above it makes no difference since octopus is used and whether octopus is getting three or four branches does not matter at all since the octopus merge is able to do this reduction internally. But in the case where we end up with two branches it makes a huge difference since we then can use the more smarter merge algorithms, and more cases will be merged automatically. However, all this does not make much of a difference in most cases. Git rocks whether we decide to do this or not. > I'd really prefer if you would resurrect merge head reduction options > (strategies?) as it was, i.e. as separate patch. And of course talk > about reducing heads, not fast-forward options/strategies... this issue > is IMVHO orthogonal to options for allowing/forcing/denying fast-forward. The first patch had the same features, was implemented slightly differently, but lacked a lot of documentation. -- Sverre Hvammen Johansen -- 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
