Re: Avoiding broken Gitweb links and deleted objects

From: Junio C Hamano <gitster@pobox.com>
Date: May 10, 2013, 06:37 UTC
Message-ID: <7vzjw349y0.fsf@alter.siamese.dyndns.org>
In-Reply-To: <518C8EAC.6000106@viscovery.net>

Johannes Sixt <j.sixt@viscovery.net> writes:

Show 20 quoted lines

> Am 5/8/2013 18:16, schrieb Matt McClure:
>> That begs a follow-up question. It sounds as though Git will typically 
>> delete unreachable objects. My team often shares links like 
>> https://git.example.com/foo.git/log/d59051721bb0a3758f7c6ea0452bac122a377645?hp=0055e0959cd13780494fe33832bae9bcf91e4a90
>>
>> . If I later rebase the branch containing those commits and d590517
>> becomes unreachable, do I risk that link breaking when Git deletes 
>> d590517?
>
> Yes.
>
> When we explain 'rebase', we usually say "you make the life hard for
> people who build on (published) history that you later rebase". But you
> inconvenience not only people who build their own history on top of your
> outdated history, but also those who operate with (web) links into that
> history.
>
>> What's a good strategy for avoiding breaking those links?
>
> Do not rebase published history.

All true, but I think we could do a bit "better", although I am still on the fence if what I am going to suggest in this message is truly "better".

Let me idly speculate and think aloud, "what if".

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.

The history transfer will not break, as there is a true ancestry that preserves the superseded history leading to X, while in the daily use and inspection of the history, such a superseded history will not bother the user by default. When the user really wants to see it (e.g. following a stale gitweb link, or with "git log $X"), such a superseded side history is still there.

Private history rewriting lets us pretend to be perfect, which is a major plus in the distributed workflow Git gives us, and such a mode of operation will defeat that in a big way, which might turn out to be a major downside, of course.

Also, rebases and filter branches that are done in order to excise unwanted objects from the history (committed a password in a file, anybody?) need a way to turn it off.