Re: Avoiding broken Gitweb links and deleted objects

> Duy Nguyen <pclouds@gmail.com> writes:
>
>> On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> Johannes Sixt <j.sixt@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-<.