On Feb 3, 2008 11:24 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Please make the next round an in-line patch. Attachments cannot > be commented on, and an RFC patch is all about getting comments, > not about being included. Whitespace breakages do not matter as > much as the final submissions; readability and commentability > matters more. I will post an update in a few days, with a few bug-fixes. > Instead of adding many new sub-strategies at once, I think it > would make it easier to review to split the patch into (1) code > movement without adding any functionality changes to make your > further changes easier, if such a change is needed in your work > (I did not really look at the attachment carefully), (2) add > logic to find out the set of independent parents to remove > redundant parents (perhaps using show-branch --independent? I > dunno) and conditionally use it, (3) add infrastructure to allow > adding different --ff=<what-to-do>, and then finally (4) a > separate patch for each of <what-to-do>. The patch is not easy to read for git-merge.sh. You really need to apply the patch and then review the code. If I follow your suggestion above it might be easier to read the patches. I will do if tthere is a demand for a split. However, it might take some time. What is the time-frame for inclusion in 1.5.5? > I suspect (2) is controversial if made unconditional. Some > people do not even like the fast-forward "merges" we have > traditionally done. --ff=never will turn this off together with fast forward. Maybe we should have --ff=traditional that is the old behavior. -- 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
