Duy Nguyen <pclouds@xxxxxxxxx> writes: > On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Johannes Sixt <j.sixt@xxxxxxxxxxxxx> writes: >> Imagine that a user runs "git rebase" on a history leading to commit >> X to create an alternate, improved history that leads to commit Y. >> What if we teach "git rebase" to record, perhaps by default, an >> "ours" merge on top of Y that takes the tree state of Y but has X as >> its second parent, and "git log" and its family to ignore such an >> artificial "ours" merge that records a tree that is identical to one >> of its parents, again perhaps by default? "git log" works more or >> less in such a way already, but we might want to teach other modes >> like --full-history and --simplify-merges to ignore "ours" to hide >> such an artificial merge by default, with an audit option to >> unignore them. > > What about git-merge? Will it be fooled by these merges while looking > for merge bases? I thought it was obvious that we should ignore the side branches that were superseded this way, as by definition they did not contribute to the end result at all. But there must be something huge that I missed; otherwise you wouldn't be asking such a question. It is already late and my brain is no longer quite working, so I cannot figure out what it is X-<. Other things that I thought were obvious include format-patch (side branch and the capping merge did not exist), another rebase (just rebase the primary history ignoring the side branch and the capping merge, and then cap the result with another artificial merge), and shortlog (it should pretend that the side branch and the capping merge never happened). Of course, there should be a way for any of these to take the side branch into account as if they are normal side branches as an option. -- 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