Re: [PATCH] logging branch deletion to help recovering from mistakes

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] logging branch deletion to help recovering from mistakes

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:50:12

Jeff King [off-list ref] writes:
On Mon, Dec 06, 2010 at 10:28:53PM -0800, Junio C Hamano wrote:

Yeah, I think this is not _quite_ what people want in this area. A base
requirement from past discussions, I think, is that the whole reflog of
the deleted branch be saved rather than just the tip. And then "reflog
show" would make a lot more sense on such saved reflogs.
I am more worried about stuff in branch.<name>.* that are discarded upon
"branch -d".  Without the config items, you won't have a working:

    $ branch -d frotz
    $ branch --undelete frotz
    $ git checkout frotz
    $ git pull

I would say it is fine to discard old reflog for "frotz" branch and tell
users of --undelete that even though their branch is undeleted, the reflog
for it is already expired when they deleted it the first time, but it is
impossible to implement "branch --undelete" without stashing away stuff
other than reflog.

Re: [PATCH] logging branch deletion to help recovering from mistakes

From: Jeff King <hidden>
Date: 2016-06-15 22:50:12

On Tue, Dec 07, 2010 at 11:21:46AM -0800, Junio C Hamano wrote:
I am more worried about stuff in branch.<name>.* that are discarded upon
"branch -d".  Without the config items, you won't have a working:

    $ branch -d frotz
    $ branch --undelete frotz
    $ git checkout frotz
    $ git pull
Hmm, yeah, I didn't think about that. Two possible solutions:

  1. Just leave it in .git/config. It is not hurting anything if the
     branch does not exist, but it is cruft in a file the user might
     look at.

  2. Drop it into .git/config.dead/<branch_name>. When resurrecting a
     branch, copy it back into .git/config.

In both cases, when the reflog for the deleted branch is pruned to
nothing, we delete the relevant config, too.

In the second case, I think you would have to take special care for
something like:

  $ git branch frotz origin/master
  $ git branch -d frotz
  $ git remote rename origin foo
  $ git branch --undelete frotz

In the non-deleted case, this transparently renames branch.frotz.remote
from "origin" to "foo". In the deleted case, we would need to make sure
the dead config is updated, too.


To be honest, I have never been that interested in a "branch --undelete"
feature. I much more care about leaving the reflogs of deleted branches
around, so I can "git checkout -b foo bar@{1}" later on[1]. That is, to
me branch undeletion is not about bringing a branch back wholesale, but
rather remembering commits so I can start a new branch there.

But I guess others might disagree.

-Peff

[1] Well, that and just piece of mind from knowing that "branch -d" is
    not totally unrecoverable. Specifically, if we kept deleted reflogs
    around, it would be safe(r) to turn on auto-prune on fetch, the lack
    of which is something that seems to confuse new users.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help