Re: Avoiding broken Gitweb links and deleted objects

Duy Nguyen [off-list ref] writes:

On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano [off-list ref] wrote:

quoted

Johannes Sixt [off-list ref] 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
option.

On Fri, May 10, 2013 at 2:16 PM, Junio C Hamano [off-list ref] wrote:

Duy Nguyen [off-list ref] writes:

quoted

On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano [off-list ref] wrote:

quoted

Johannes Sixt [off-list ref] 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