On Wed, 19 Mar 2008, Sverre Hvammen Johansen wrote: > Thanks to you and everyone else for useful input. Some of this input > ended up in the documentation. I will provide an updated patch > tomorrow. I expect to have a final patch for submission some time > next week. > > I have added some more documentation: This updated documentation made it clear that this commit introduces two (or even three accoridng to Junio) independent features, which in my opinion should be split into separate patch. Having separate commits for separate features helps reduce commit size and should help readibility of patch, thus making review process easier. It also makes bisecting easier. First feature is introducing fast forward options (I'd rather not call them "strategies") 'allow', 'never' and new option 'only'. This is independent on the head reduction feature; actually the second feature was sent as separate patch in first draft, I wonder why you have decided to join them. > +If more than one commit are specified for the merge, git will try to > +reduce the number of commits (real parents) by eliminating commits > +than can be reached from other commits. The commit message will > +reflect the actual commits specified but the merge strategy will be > +selected based on the real parents always including `HEAD`. The real > +parents (only including `HEAD` if it is real) are the parents recorded > +in the merge commit object. IMHO this should be (besides having this as separate commit) optional. I'm not sure if always heads reduction is always desirable. > +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 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. > +A merger of master with TopicA, TopicB, and TopicC will select the > +merge strategy based on the three branches master, TopicB, and TopicC > +(TopicA is eliminated since it can be reached from TopicB). TopicB > +and TopicC are the only real parents and are therefore the only > +parents recorded in the merge commit object: > + > +------------ > + % 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 example above mixes fast-forward options with automatic reduction of heads in a merge. 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. > On Tue, Mar 18, 2008 at 8:27 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> >> I'd mention here receive.denyNonFastForward option as a way to set >> this globally for all branches, for public bare publishing >> repositories; AFAIK for push and I think also for fetch. > > The denyNonFastForward option have nothing to do with merges. It only > applies to push on the server side. A merge is not involved when > doing a push. Fact. My mistake. The result might be similar (linear history), but the issue is different. P.S. I think git is now in feature freeze... which is good time for sending patches for discussion, not good for sending patches to be accepted. -- Jakub Narebski Poland -- 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
