On Fri, May 10, 2013 at 2:16 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Duy Nguyen <pclo...@gmail.com> writes:
>> On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano <gits...@pobox.com> wrote:
>>> Johannes Sixt <j.s...@viscovery.net> 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

Although I think this is an abuse of merge commits. Maybe git-notes is
a better way to publish rebase history.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to