Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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 >> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html