Re: Avoiding broken Gitweb links and deleted objects
- From
Duy Nguyen <pclouds@gmail.com>
- Date
- May 10, 2013, 07:04 UTC
- Message-ID
- <CACsJy8CopioiTrEDfuZK=n1DfJ8_chxV9dEObqpVfHHmJvzyqQ@mail.gmail.com>
- In-Reply-To
- <7vzjw349y0.fsf@alter.siamese.dyndns.org>
On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> 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? -- Duy