{"thread":{"id":"33753","subject":"Avoiding broken Gitweb links and deleted objects","startedAt":"2013-05-08T16:16:14Z","lastAt":"2013-05-22T17:39:49Z","messageCount":14,"participants":["Matt McClure","Johannes Sixt","Junio C Hamano","Duy Nguyen","William Swanson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"216716","messageId":"CAJELnLFrfY=-gOFEe0cJHuyT4UNjbTm8hXMxAmzmQHVbz4iEbg@mail.gmail.com","threadId":"33753","inReplyTo":null,"subject":"Avoiding broken Gitweb links and deleted objects","fromName":"Matt McClure","fromEmail":"matthewlmcclure@gmail.com","sentAt":"2013-05-08T16:16:14Z","receivedAt":"2013-05-08T16:16:14Z","isPatch":false,"sender":{"key":"matthewlmcclure@gmail.com","avatar":"https://gravatar.com/avatar/a8cde96b0594204c8d4c48baa51c983af37dedfa2b7a846e27547b8d63d46e7c?d=mp&s=160"},"body":"On Wed, May 8, 2013 at 12:05 PM, Matt McClure wrote:\n> On Wed, May 8, 2013 at 10:41 AM, Johannes Sixt wrote:\n>> git gc moves unreachable objects that were packed before to the loose\n>> object store, from where they can be pruned.\n>\n> Thanks. That was the piece I was missing. I assumed `git gc` did the opposite.\n\nThat begs a follow-up question. It sounds as though Git will typically\ndelete unreachable objects. My team often shares links like\nhttps://git.example.com/foo.git/log/d59051721bb0a3758f7c6ea0452bac122a377645?hp=0055e0959cd13780494fe33832bae9bcf91e4a90\n. If I later rebase the branch containing those commits and d590517\nbecomes unreachable, do I risk that link breaking when Git deletes\nd590517?\n\nWhat's a good strategy for avoiding breaking those links?\n\n-- \nMatt McClure\nhttp://matthewlmcclure.com\nhttp://www.mapmyfitness.com/profile/matthewlmcclure\n"},{"id":"216811","messageId":"1912835977933437557@unknownmsgid","threadId":"33753","inReplyTo":"CAJELnLFrfY=-gOFEe0cJHuyT4UNjbTm8hXMxAmzmQHVbz4iEbg@mail.gmail.com","subject":"Re: Avoiding broken Gitweb links and deleted objects","fromName":"Matt McClure","fromEmail":"matthewlmcclure@gmail.com","sentAt":"2013-05-09T20:04:18Z","receivedAt":"2013-05-09T20:04:18Z","isPatch":false,"sender":{"key":"matthewlmcclure@gmail.com","avatar":"https://gravatar.com/avatar/a8cde96b0594204c8d4c48baa51c983af37dedfa2b7a846e27547b8d63d46e7c?d=mp&s=160"},"body":"On Wed, May 8, 2013 at 12:05 PM, Matt McClure wrote:\n> On Wed, May 8, 2013 at 10:41 AM, Johannes Sixt wrote:\n>> git gc moves unreachable objects that were packed before to the loose\n>> object store, from where they can be pruned.\n>\n> Thanks. That was the piece I was missing. I assumed `git gc` did the opposite.\n\nThat begs a follow-up question. It sounds as though Git will typically\ndelete unreachable objects. My team often shares links like\nhttps://git.example.com/foo.git/log/d59051721bb0a3758f7c6ea0452bac122a377645?hp=0055e0959cd13780494fe33832bae9bcf91e4a90\n. If I later rebase the branch containing those commits and d590517\nbecomes unreachable, do I risk that link breaking when Git deletes\nd590517?\n\nWhat's a good strategy for avoiding breaking those links?\n\n-- \nMatt McClure\nhttp://matthewlmcclure.com\nhttp://www.mapmyfitness.com/profile/matthewlmcclure\n"},{"id":"216850","messageId":"518C8EAC.6000106@viscovery.net","threadId":"33753","inReplyTo":"CAJELnLFrfY=-gOFEe0cJHuyT4UNjbTm8hXMxAmzmQHVbz4iEbg@mail.gmail.com","subject":"Re: Avoiding broken Gitweb links and deleted objects","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-05-10T06:07:40Z","receivedAt":"2013-05-10T06:07:40Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 5/8/2013 18:16, schrieb Matt McClure:\n> That begs a follow-up question. It sounds as though Git will typically \n> delete unreachable objects. My team often shares links like \n> https://git.example.com/foo.git/log/d59051721bb0a3758f7c6ea0452bac122a377645?hp=0055e0959cd13780494fe33832bae9bcf91e4a90\n>\n> . If I later rebase the branch containing those commits and d590517\n> becomes unreachable, do I risk that link breaking when Git deletes \n> d590517?\n\nYes.\n\nWhen we explain 'rebase', we usually say \"you make the life hard for\npeople who build on (published) history that you later rebase\". But you\ninconvenience not only people who build their own history on top of your\noutdated history, but also those who operate with (web) links into that\nhistory.\n\n> What's a good strategy for avoiding breaking those links?\n\nDo not rebase published history.\n\n-- Hannes\n"},{"id":"216851","messageId":"7vzjw349y0.fsf@alter.siamese.dyndns.org","threadId":"33753","inReplyTo":"518C8EAC.6000106@viscovery.net","subject":"Re: Avoiding broken Gitweb links and deleted objects","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-10T06:37:27Z","receivedAt":"2013-05-10T06:37:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Am 5/8/2013 18:16, schrieb Matt McClure:\n>> That begs a follow-up question. It sounds as though Git will typically \n>> delete unreachable objects. My team often shares links like \n>> https://git.example.com/foo.git/log/d59051721bb0a3758f7c6ea0452bac122a377645?hp=0055e0959cd13780494fe33832bae9bcf91e4a90\n>>\n>> . If I later rebase the branch containing those commits and d590517\n>> becomes unreachable, do I risk that link breaking when Git deletes \n>> d590517?\n>\n> Yes.\n>\n> When we explain 'rebase', we usually say \"you make the life hard for\n> people who build on (published) history that you later rebase\". But you\n> inconvenience not only people who build their own history on top of your\n> outdated history, but also those who operate with (web) links into that\n> history.\n>\n>> What's a good strategy for avoiding breaking those links?\n>\n> Do not rebase published history.\n\nAll true, but I think we could do a bit \"better\", although I am\nstill on the fence if what I am going to suggest in this message is\ntruly \"better\".\n\nLet me idly speculate and think aloud, \"what if\".\n\nImagine that a user runs \"git rebase\" on a history leading to commit\nX to create an alternate, improved history that leads to commit Y.\nWhat if we teach \"git rebase\" to record, perhaps by default, an\n\"ours\" merge on top of Y that takes the tree state of Y but has X as\nits second parent, and \"git log\" and its family to ignore such an\nartificial \"ours\" merge that records a tree that is identical to one\nof its parents, again perhaps by default? \"git log\" works more or\nless in such a way already, but we might want to teach other modes\nlike --full-history and --simplify-merges to ignore \"ours\" to hide\nsuch an artificial merge by default, with an audit option to\nunignore them.\n\nThe history transfer will not break, as there is a true ancestry\nthat preserves the superseded history leading to X, while in the\ndaily use and inspection of the history, such a superseded history\nwill not bother the user by default. When the user really wants to\nsee it (e.g. following a stale gitweb link, or with \"git log $X\"),\nsuch a superseded side history is still there.\n\nPrivate history rewriting lets us pretend to be perfect, which is a\nmajor plus in the distributed workflow Git gives us, and such a mode\nof operation will defeat that in a big way, which might turn out to\nbe a major downside, of course.\n\nAlso, rebases and filter branches that are done in order to excise\nunwanted objects from the history (committed a password in a file,\nanybody?) need a way to turn it off.\n"},{"id":"216853","messageId":"518C9BD8.90508@viscovery.net","threadId":"33753","inReplyTo":"7vzjw349y0.fsf@alter.siamese.dyndns.org","subject":"Re: Avoiding broken Gitweb links and deleted objects","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2013-05-10T07:03:52Z","receivedAt":"2013-05-10T07:03:52Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 5/10/2013 8:37, schrieb Junio C Hamano:\n> What if we teach \"git rebase\" to record, perhaps by default, an\n> \"ours\" merge on top of Y that takes the tree state of Y but has X as\n> its second parent, ...\n\nPlease let's not go that route...\n\n-- Hannes\n"},{"id":"216854","messageId":"CACsJy8CopioiTrEDfuZK=n1DfJ8_chxV9dEObqpVfHHmJvzyqQ@mail.gmail.com","threadId":"33753","inReplyTo":"7vzjw349y0.fsf@alter.siamese.dyndns.org","subject":"Re: Avoiding broken Gitweb links and deleted objects","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-10T07:04:58Z","receivedAt":"2013-05-10T07:04:58Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano wrote:\n> Johannes Sixt writes:\n> Imagine that a user runs \"git rebase\" on a history leading to commit\n> X to create an alternate, improved history that leads to commit Y.\n> What if we teach \"git rebase\" to record, perhaps by default, an\n> \"ours\" merge on top of Y that takes the tree state of Y but has X as\n> its second parent, and \"git log\" and its family to ignore such an\n> artificial \"ours\" merge that records a tree that is identical to one\n> of its parents, again perhaps by default? \"git log\" works more or\n> less in such a way already, but we might want to teach other modes\n> like --full-history and --simplify-merges to ignore \"ours\" to hide\n> such an artificial merge by default, with an audit option to\n> unignore them.\n\nWhat about git-merge? Will it be fooled by these merges while looking\nfor merge bases?\n--\nDuy\n"},{"id":"216856","messageId":"7vvc6r4855.fsf@alter.siamese.dyndns.org","threadId":"33753","inReplyTo":"CACsJy8CopioiTrEDfuZK=n1DfJ8_chxV9dEObqpVfHHmJvzyqQ@mail.gmail.com","subject":"Re: Avoiding broken Gitweb links and deleted objects","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-10T07:16:22Z","receivedAt":"2013-05-10T07:16:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano wrote:\n>> Johannes Sixt writes:\n>> Imagine that a user runs \"git rebase\" on a history leading to commit\n>> X to create an alternate, improved history that leads to commit Y.\n>> What if we teach \"git rebase\" to record, perhaps by default, an\n>> \"ours\" merge on top of Y that takes the tree state of Y but has X as\n>> its second parent, and \"git log\" and its family to ignore such an\n>> artificial \"ours\" merge that records a tree that is identical to one\n>> of its parents, again perhaps by default? \"git log\" works more or\n>> less in such a way already, but we might want to teach other modes\n>> like --full-history and --simplify-merges to ignore \"ours\" to hide\n>> such an artificial merge by default, with an audit option to\n>> unignore them.\n>\n> What about git-merge? Will it be fooled by these merges while looking\n> for merge bases?\n\nI thought it was obvious that we should ignore the side branches\nthat were superseded this way, as by definition they did not\ncontribute to the end result at all.\n\nBut there must be something huge that I missed; otherwise you\nwouldn't be asking such a question. It is already late and my brain\nis no longer quite working, so I cannot figure out what it is X-<.\n\nOther things that I thought were obvious include format-patch (side\nbranch and the capping merge did not exist), another rebase (just\nrebase the primary history ignoring the side branch and the capping\nmerge, and then cap the result with another artificial merge), and\nshortlog (it should pretend that the side branch and the capping\nmerge never happened).\n\nOf course, there should be a way for any of these to take the side\nbranch into account as if they are normal side branches as an\noption.\n"},{"id":"216857","messageId":"CABjHNoT+Kvm5j4W+c2KOd+0mdu8tPCFDcEAWjxp0OcUXf1t4Lg@mail.gmail.com","threadId":"33753","inReplyTo":"7vzjw349y0.fsf@alter.siamese.dyndns.org","subject":"Re: Avoiding broken Gitweb links and deleted objects","fromName":"William Swanson","fromEmail":"swansontec@gmail.com","sentAt":"2013-05-10T07:34:07Z","receivedAt":"2013-05-10T07:34:07Z","isPatch":false,"sender":{"key":"swansontec@gmail.com","avatar":"https://gravatar.com/avatar/c347fab0a8fe77e4159deb7c2b7195ebbee19b091aed98503ad83438e6bea851?d=mp&s=160"},"body":"On Thu, May 9, 2013 at 11:37 PM, Junio C Hamano wrote:\n>>> What's a good strategy for avoiding breaking those links?\n>>\n>> Do not rebase published history.\n>\n> All true, but I think we could do a bit \"better\", although I am\n> still on the fence if what I am going to suggest in this message is\n> truly \"better\".\n>\n> Let me idly speculate and think aloud, \"what if\".\n>\n> Imagine that a user runs \"git rebase\" on a history leading to commit\n> X to create an alternate, improved history that leads to commit Y.\n> What if we teach \"git rebase\" to record, perhaps by default, an\n> \"ours\" merge on top of Y that takes the tree state of Y but has X as\n> its second parent, and \"git log\" and its family to ignore such an\n> artificial \"ours\" merge that records a tree that is identical to one\n> of its parents, again perhaps by default? \"git log\" works more or\n> less in such a way already, but we might want to teach other modes\n> like --full-history and --simplify-merges to ignore \"ours\" to hide\n> such an artificial merge by default, with an audit option to\n> unignore them.\n>\n> The history transfer will not break, as there is a true ancestry\n> that preserves the superseded history leading to X, while in the\n> daily use and inspection of the history, such a superseded history\n> will not bother the user by default. When the user really wants to\n> see it (e.g. following a stale gitweb link, or with \"git log $X\"),\n> such a superseded side history is still there.\n>\n> Private history rewriting lets us pretend to be perfect, which is a\n> major plus in the distributed workflow Git gives us, and such a mode\n> of operation will defeat that in a big way, which might turn out to\n> be a major downside, of course.\n>\n> Also, rebases and filter branches that are done in order to excise\n> unwanted objects from the history (committed a password in a file,\n> anybody?) need a way to turn it off.\n\nI started working on something like this a few weeks ago, but\neventually came to the conclusion that this information does not\nbelong in the commit graph itself. You have already identified some of\nthe same problems I found, so I will not repeat them. In the end, you\neither publish everything (including bad things like passwords or\ndead-ends), or you leave the the rebase history-preservation feature\nturned off all the time and then forget to turn it on when it really\nmatters.\n\nA better approach, I think, would be to enhance the reflogs to the\npoint where they can provide this information in a reliable manner.\nThe Git garbage collector already skips objects mentioned in the\nreflogs, so \"git reflog expire\" just needs to learn how to avoid\ndeleting topologically-interesting entries like rebases. For a shared\nscenario like github, this would prevent the server from expiring\npublished commits and creating broken links.\n\nSince Git maintains reflogs for all heads, including those in\nrefs/remotes, this strategy for preserving history also works in a\ncollaborative environment. Each repository remembers what it has seen,\nincluding rebases from remotes (which appear as \"forced updates\"). On\nthe other hand, work-in-progress commits only appear in the local\nreflogs, and won't appear in other repositories unless someone pulls\nor pushes them.\n\nIf it does become necessary to delete some published historical\ninformation (like passwords), it is still possible to delete reflog\nentries by hand. They are not part of the object database, so doing\nthis doesn't break any hashes.\n\n-William\n"},{"id":"216865","messageId":"CACsJy8AjrPvcSDBm2GZQ_HAEhXKz9d06QxSjBthX2fCU0QNUGA@mail.gmail.com","threadId":"33753","inReplyTo":"7vvc6r4855.fsf@alter.siamese.dyndns.org","subject":"Re: Avoiding broken Gitweb links and deleted objects","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-05-10T10:33:20Z","receivedAt":"2013-05-10T10:33:20Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, May 10, 2013 at 2:16 PM, Junio C Hamano wrote:\n> Duy Nguyen writes:\n>\n>> On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano wrote:\n>>> Johannes Sixt writes:\n>>> Imagine that a user runs \"git rebase\" on a history leading to commit\n>>> X to create an alternate, improved history that leads to commit Y.\n>>> What if we teach \"git rebase\" to record, perhaps by default, an\n>>> \"ours\" merge on top of Y that takes the tree state of Y but has X as\n>>> its second parent, and \"git log\" and its family to ignore such an\n>>> artificial \"ours\" merge that records a tree that is identical to one\n>>> of its parents, again perhaps by default? \"git log\" works more or\n>>> less in such a way already, but we might want to teach other modes\n>>> like --full-history and --simplify-merges to ignore \"ours\" to hide\n>>> such an artificial merge by default, with an audit option to\n>>> unignore them.\n>>\n>> What about git-merge? Will it be fooled by these merges while looking\n>> for merge bases?\n>\n> I thought it was obvious that we should ignore the side branches\n> that were superseded this way, as by definition they did not\n> contribute to the end result at all.\n>\n> But there must be something huge that I missed; otherwise you\n> wouldn't be asking such a question. It is already late and my brain\n> is no longer quite working, so I cannot figure out what it is X-<.\n\nNo, I was at work and could not spend more time thinking about it (I\nasked stupid questions all the time, you should know ;). You were\nright, these multiple parent commits have nothing to do with merge\nbases.\n\nAlthough I think this is an abuse of merge commits. Maybe git-notes is\na better way to publish rebase history.\n--\nDuy\n"},{"id":"216910","messageId":"7vfvxu3ivc.fsf@alter.siamese.dyndns.org","threadId":"33753","inReplyTo":"7vvc6r4855.fsf@alter.siamese.dyndns.org","subject":"Re: Avoiding broken Gitweb links and deleted objects","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-10T16:22:15Z","receivedAt":"2013-05-10T16:22:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Duy Nguyen writes:\n>\n>> On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano wrote:\n>>> Johannes Sixt writes:\n>>> Imagine that a user runs \"git rebase\" on a history leading to commit\n>>> X to create an alternate, improved history that leads to commit Y.\n>>> What if we teach \"git rebase\" to record, perhaps by default, an\n>>> \"ours\" merge on top of Y that takes the tree state of Y but has X as\n>>> its second parent, and \"git log\" and its family to ignore such an\n>>> artificial \"ours\" merge that records a tree that is identical to one\n>>> of its parents, again perhaps by default? \"git log\" works more or\n>>> less in such a way already, but we might want to teach other modes\n>>> like --full-history and --simplify-merges to ignore \"ours\" to hide\n>>> such an artificial merge by default, with an audit option to\n>>> unignore them.\n>>\n>> What about git-merge? Will it be fooled by these merges while looking\n>> for merge bases?\n>\n> I thought it was obvious that we should ignore the side branches\n> that were superseded this way, as by definition they did not\n> contribute to the end result at all.\n>\n> But there must be something huge that I missed...\n\nI think what I missed is that the same logic to ignore side branches\nwhose history gets cauterised with such an \"ours\" merge may apply to\nan \"ours\" merge that people already make, but the latter may want to\ntake both histories into account.\n\nSo I guess it is not such a great idea.\n"},{"id":"218172","messageId":"CAJELnLEOg+D+baAddJvDiYM=ej8PKsgi2MWH25enOijXa+bO_Q@mail.gmail.com","threadId":"33753","inReplyTo":"7vfvxu3ivc.fsf@alter.siamese.dyndns.org","subject":"Re: Avoiding broken Gitweb links and deleted objects","fromName":"Matt McClure","fromEmail":"matthewlmcclure@gmail.com","sentAt":"2013-05-22T13:25:25Z","receivedAt":"2013-05-22T13:25:25Z","isPatch":false,"sender":{"key":"matthewlmcclure@gmail.com","avatar":"https://gravatar.com/avatar/a8cde96b0594204c8d4c48baa51c983af37dedfa2b7a846e27547b8d63d46e7c?d=mp&s=160"},"body":"On Fri, May 10, 2013 at 12:22 PM, Junio C Hamano wrote:\n> I think what I missed is that the same logic to ignore side branches\n> whose history gets cauterised with such an \"ours\" merge may apply to\n> an \"ours\" merge that people already make, but the latter may want to\n> take both histories into account.\n>\n> So I guess it is not such a great idea.\n\nThe particular proposed implementation? Or the broader idea to save\nloose commits more permanently? I'm still interested in a solution for\nthe latter.\n\n-- \nMatt McClure\nhttp://matthewlmcclure.com\nhttp://www.mapmyfitness.com/profile/matthewlmcclure\n"},{"id":"218174","messageId":"CAJELnLEGr7eG9W2WvcVjWi7rT6EUhBDVdtfx6Xjp15duB0E9kw@mail.gmail.com","threadId":"33753","inReplyTo":"CABjHNoT+Kvm5j4W+c2KOd+0mdu8tPCFDcEAWjxp0OcUXf1t4Lg@mail.gmail.com","subject":"Re: Avoiding broken Gitweb links and deleted objects","fromName":"Matt McClure","fromEmail":"matthewlmcclure@gmail.com","sentAt":"2013-05-22T13:32:12Z","receivedAt":"2013-05-22T13:32:12Z","isPatch":false,"sender":{"key":"matthewlmcclure@gmail.com","avatar":"https://gravatar.com/avatar/a8cde96b0594204c8d4c48baa51c983af37dedfa2b7a846e27547b8d63d46e7c?d=mp&s=160"},"body":"On Fri, May 10, 2013 at 3:34 AM, William Swanson wrote:\n> I started working on something like this a few weeks ago, but\n> eventually came to the conclusion that this information does not\n> belong in the commit graph itself.\n>\n> A better approach, I think, would be to enhance the reflogs to the\n> point where they can provide this information in a reliable manner.\n\nIs there a way to push/pull reflogs among different repositories?\n\nIn my original scenario:\n\n1. the commits are created on a developer machine\n2. pushed to a central origin repository running Gitweb\n3. the branch is rebased on the developer machine\n4. the branch is push --force'd to the origin\n\nLater, git push tells me:\n\n warning: There are too many unreachable loose objects; run 'git\nprune' to remove them.\n\nor I want to delete old topic branch HEADs to improve performance.\n\nBut I never want to let Git delete the underlying commit objects since\nthere could be Gitweb links pointing at them.\n\n-- \nMatt McClure\nhttp://matthewlmcclure.com\nhttp://www.mapmyfitness.com/profile/matthewlmcclure\n"},{"id":"218185","messageId":"CABjHNoQEpjE8Da2qiU8o5LRWs7CrUW44XcV7T=tcnB_Z1z+Uvg@mail.gmail.com","threadId":"33753","inReplyTo":"CAJELnLEGr7eG9W2WvcVjWi7rT6EUhBDVdtfx6Xjp15duB0E9kw@mail.gmail.com","subject":"Re: Avoiding broken Gitweb links and deleted objects","fromName":"William Swanson","fromEmail":"swansontec@gmail.com","sentAt":"2013-05-22T15:41:57Z","receivedAt":"2013-05-22T15:41:57Z","isPatch":false,"sender":{"key":"swansontec@gmail.com","avatar":"https://gravatar.com/avatar/c347fab0a8fe77e4159deb7c2b7195ebbee19b091aed98503ad83438e6bea851?d=mp&s=160"},"body":"On Wed, May 22, 2013 at 6:32 AM, Matt McClure wrote:\n> Is there a way to push/pull reflogs among different repositories?\n\nNot that I am aware of, at least not in core git.\n\n> In my original scenario:\n>\n> 1. the commits are created on a developer machine\n> 2. pushed to a central origin repository running Gitweb\n> 3. the branch is rebased on the developer machine\n> 4. the branch is push --force'd to the origin\n>\n> Later, git push tells me:\n>\n> warning: There are too many unreachable loose objects; run 'git\n> prune' to remove them.\n\nYou don't need to share reflogs in this case. Assuming the server were\nto keep logs of its own, the forced update would create a new reflog\nentry showing something like \" Forced\npush\", so the pre-rebase version would still be reachable from the\nreflogs, keeping it around.\n\n> or I want to delete old topic branch HEADs to improve performance.\n>\n> But I never want to let Git delete the underlying commit objects since\n> there could be Gitweb links pointing at them.\n\nThe reflog thing won't help you in this case, since reflogs are\ndeleted when their branches are deleted. it sounds like you never want\nto delete anything, so it would make more sense to just disable\ngarbage collection entirely.\n\n-William\n"},{"id":"218196","messageId":"7vd2sikj6i.fsf@alter.siamese.dyndns.org","threadId":"33753","inReplyTo":"CAJELnLEOg+D+baAddJvDiYM=ej8PKsgi2MWH25enOijXa+bO_Q@mail.gmail.com","subject":"Re: Avoiding broken Gitweb links and deleted objects","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-05-22T17:39:49Z","receivedAt":"2013-05-22T17:39:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matt McClure writes:\n\n> On Fri, May 10, 2013 at 12:22 PM, Junio C Hamano wrote:\n>> I think what I missed is that the same logic to ignore side branches\n>> whose history gets cauterised with such an \"ours\" merge may apply to\n>> an \"ours\" merge that people already make, but the latter may want to\n>> take both histories into account.\n>>\n>> So I guess it is not such a great idea.\n>\n> The particular proposed implementation? Or the broader idea to save\n> loose commits more permanently? I'm still interested in a solution for\n> the latter.\n\nRecording such an \"otherwise should not be recorded as a merge\" side\nhistory as if it were \"-s ours\" merge is what I judged as \"not a\ngreat idea\".\n\nIf you want to keep older commits, either you make sure you point at\nthem with some refs, or not prune the repository. I do not think of\nany other solution offhand.\n"}]}