On Fri, May 10, 2013 at 2:16 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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-<. No, I was at work and could not spend more time thinking about it (I asked stupid questions all the time, you should know ;). You were right, these multiple parent commits have nothing to do with merge bases. Although I think this is an abuse of merge commits. Maybe git-notes is a better way to publish rebase history. -- Duy -- 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