On Tue, 2010-07-13 at 09:13 +0200, Clemens Buchacher wrote:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html