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

Re: [PATCH] Remove branch by putting a null sha1 into the ref file.

From
Christian Couder <chriscool@tuxfamily.org>
Date
Sep 23, 2006, 04:45 UTC
Message-ID
<200609230645.37773.chriscool@tuxfamily.org>
In-Reply-To
<7v3baj365g.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
Show 8 quoted lines
> Linus Torvalds <torvalds@osdl.org> writes:
> > It's entirely possible that the proper way to do branch deletion with
> > packed branches is to simply re-pack without the old branch, rather
> > than the negative branch model. I couldn't really decide.
>
> After playing with branch deletion issues for some time, I
> started to think it would be a lot simpler if we do not mark
> a deleted branch with 0{40}.

I also came to the same conclusion and I wonder if we could delete a branch by moving the file ".git/refs/heads/frotz" to ".git/deleted-refs/heads/frotz". If the branch is packed we could perhaps just create ".git/deleted-refs/heads/frotz".

It means everytime we are looking up a ref we have to check in ".git/deleted-refs/" first to see if it exists.

> But the latter falls apart if we use 0{40} convention to mark a
> deleted branch. Removing .git/refs/heads/frotz/nitfol file which
> has 0{40} and creating .git/refs/heads/frotz file resurrects
> frotz/nitfol branch that is still packed.

If we move ".git/refs/heads/frotz/nitfol" to ".git/deleted-refs/heads/frotz/nitfol" when we remove this ref, we only need to try to rmdir all subdirectories under ".git/refs/heads/frotz/" and then ".git/refs/heads/frotz/" to see if we can create ".git/refs/heads/frotz", and if we can, we won't resurect "frotz/nitfol" because ".git/deleted-refs/heads/frotz/nitfol" still exists.

Show 7 quoted lines
> Not allowing frotz 
> branch to be created only because we had deleted frotz/nitfol
> previously is not what we want either, so at that point we need
> to repack without frotz/nitfol anyway.
>
> Which makes me think that we would better repack when removing
> any existing ref.
Yes but it may not be fast and may be corruption prone.
Christian.
Previous: Junio C HamanoNext: Junio C Hamano
Message 7 of 19 in “Remove branch by putting a null sha1 into the ref file.”
  1. Remove branch by putting a null sha1 into the ref file.Christian Couder, Sep 18, 2006
  2. Junio C HamanoSep 18, 2006
  3. Linus TorvaldsSep 18, 2006
  4. Junio C HamanoSep 18, 2006
  5. Christian CouderSep 20, 2006
  6. Junio C HamanoSep 22, 2006
  7. Christian CouderSep 23, 2006
  8. Junio C HamanoSep 23, 2006
  9. Christian CouderSep 23, 2006
  10. Junio C HamanoSep 23, 2006
  11. Christian CouderSep 24, 2006
  12. On ref lockingJunio C Hamano, Sep 25, 2006
  13. Daniel BarkalowSep 25, 2006
  14. Junio C HamanoSep 26, 2006
  15. 1/3 Clean-up lock-ref implementationJunio C Hamano, Sep 26, 2006
  16. 2/3 update-ref: -d flag and ref creation safety.Junio C Hamano, Sep 26, 2006
  17. 3/3 update a few Porcelain-ish for ref lock safety.Junio C Hamano, Sep 26, 2006
  18. Andy WhitcroftSep 26, 2006
  19. Junio C HamanoSep 27, 2006

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.