Re: Question about 'branch -d' safety
- From
Will Palmer <wmpalmer@gmail.com>
- Date
- Jul 13, 2010, 08:00 UTC
- Message-ID
- <1279008023.2030.11.camel@wpalmer.simply-domain>
- In-Reply-To
- <20100713071317.GA26348@localhost>
On Tue, 2010-07-13 at 09:13 +0200, Clemens Buchacher wrote:
Show 13 quoted lines
> Why would we need that? Even now, it is not enough to do "git > branch -D frotz; git gc --prune". You need to expire the reflog, > since HEAD may still have a reference to it. So instead you would > need > > git branch -D frotz > git reflog expire --expire=now HEAD frotz > git gc --prune > > Purging a branch becomes just a special case of purging anything > from history. > > Clemens
With that in mind, would it not be enough to simply remove the ref, but not the reflog, and change the logic to let the reflog live on until either pruned or all of its entries have expired normally? On branch creation, if a reflog already exists, it would remain untouched. Reflog entries would ALWAYS expire using the same expire-time rules, regardless of whether or not the ref itself exists, and everything just makes sense. Simple to follow, simple to prune, branch -d becomes just as safe as any other operation. I like this.
I understand the argument for "but you may wind up creating an unrelated branch with the same name", but I can't really think of any cases where it would matter, and it would be impossible to guess whether or not a new branch were related to the old one. If we'd really want to take care of that sort of thing, we'd need to move into two-dimensional reflog territory, with something like somebranch@{3,5} to mean "3 reflogs ago, 5 states ago", which goes too far and looks ugly.