Junio C Hamano <gitster@xxxxxxxxx> writes: > 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... I think what I missed is that the same logic to ignore side branches whose history gets cauterised with such an "ours" merge may apply to an "ours" merge that people already make, but the latter may want to take both histories into account. So I guess it is not such a great idea. -- 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