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-<.
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
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