git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: can we prevent reflog deletion when branch is deleted?

From
Luca Milanesio <luca.milanesio@gmail.com>
Date
Nov 14, 2013, 11:17 UTC
Message-ID
<66513F31-CF2E-4327-AEA3-20176C14EEE1@gmail.com>
In-Reply-To
<20131114110937.GA11597@sigill.intra.peff.net>

Would be really useful anyway to have the ability to create a server-side reference based on a SHA-1, using the Git protocol. Alternatively, just fetching a remote repo based on a SHA-1 (not referenced by any ref-spec but still existent) so that you can create a new reference locally and push.

Luca.
On 14 Nov 2013, at 11:09, Jeff King <peff@peff.net> wrote:
Show 37 quoted lines
> On Thu, Nov 14, 2013 at 04:26:46PM +0530, Sitaram Chamarty wrote:
> 
>>> I do not know about any particular debate in git circles, but I assume
>>> Sitaram is referring to this incident:
>>> 
>>>  https://groups.google.com/d/msg/jenkinsci-dev/-myjRIPcVwU/t4nkXONp8qgJ
>>> 
>>> in which a Jenkins dev force-pushed and rewound history on 150 different
>>> repos. In this case the reflog made rollback easy, but if he had pushed
>>> a deletion, it would be harder.
>> 
>> I don't know if they had a reflog on the server side; they used
>> client-side reflogs if I understood correctly.
>> 
>> I'm talking about server side (bare repo), assuming the site has
>> core.logAllRefUpdates set.
> 
> Yes, they did have server-side reflogs (the pushes were to GitHub, and
> we reflog everything). Client-side reflogs would not be sufficient, as
> the client who pushed does not record the history he just rewound (he
> _might_ have it at refs/remotes/origin/master@{1}, but if somebody
> pushed since his last fetch, then he doesn't).
> 
> The "simplest" way to recover is to just have everyone push again
> (without --force). The history will just silently fast-forward to
> whoever has the most recent tip. The downside is that you have to wait
> for that person to actually push. :)
> 
> I think they started with that, and then eventually GitHub support got
> wind of it and pulled the last value for each repo out of the
> server-side reflog for them.
> 
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous: Jeff KingNext: Sitaram Chamarty
Message 15 of 21 in “can we prevent reflog deletion when branch is deleted?”
  1. Sitaram ChamartyJun 1, 2013
  2. Michael HaggertyJun 1, 2013
  3. Jeff KingJun 1, 2013
  4. Ramkumar RamachandraJun 1, 2013
  5. Jeff KingJun 1, 2013
  6. Ramkumar RamachandraJun 1, 2013
  7. Sitaram ChamartyJun 1, 2013
  8. Ramkumar RamachandraJun 1, 2013
  9. Sitaram ChamartyJun 2, 2013
  10. Sitaram ChamartyNov 14, 2013
  11. Thomas RastNov 14, 2013
  12. Jeff KingNov 14, 2013
  13. Sitaram ChamartyNov 14, 2013
  14. Jeff KingNov 14, 2013
  15. Luca MilanesioNov 14, 2013
  16. Sitaram ChamartyNov 14, 2013
  17. Sitaram ChamartyNov 14, 2013
  18. Jeff KingNov 14, 2013
  19. Stephen BashNov 14, 2013
  20. Sitaram ChamartyNov 14, 2013
  21. Sitaram ChamartyNov 14, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.