Johannes Sixt <j.s...@viscovery.net> writes:
> 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
>> . If I later rebase the branch containing those commits and d590517
>> becomes unreachable, do I risk that link breaking when Git deletes
> 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
>> 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
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
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.
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