Re: Keeping reflogs on branch deletion
- From
Jeff King <peff@peff.net>
- Date
- Feb 14, 2008, 17:57 UTC
- Message-ID
- <20080214175724.GA30689@coredump.intra.peff.net>
- In-Reply-To
- <alpine.LFD.1.00.0802141147200.2732@xanadu.home>
On Thu, Feb 14, 2008 at 12:32:07PM -0500, Nicolas Pitre wrote:
Show 7 quoted lines
> I typically have lots of branches. Many of those are fairly dynamic -- > they come and go. Keeping reflogs for them would only clutter the > reflog space, especially when the same names are reused. I prefer to > have a clean reflog for the currently alive branch of a given name > rather than having a log of anything that occurred under that name. And > if I really want to find out about that old branch then there is always > the HEAD reflog.
OK, that is a fair argument. I totally disagree, but this is a question of "what users would want" and you and I happen to want different behavior. I suspect it has to do with how you name your branches.
Show 5 quoted lines
> > For one thing, just because a modification wasn't _yours_ doesn't mean > > it isn't valuable. It entered your repository, and therefore it may be > > of interest. > > And if you delete it then you can retrieve it again from its origin.
In a system which touts totally independent operation of separate repositories, saying "oh, you can just ask some other repository for it again" seems silly. Who is to say the other repo still exists? Or that it contains the information you're looking for (e.g., a git push from an arbitrary commit at one repo may enter your branch at a specific point. the information that is useful to you is where and when it landed in your branch, which was never in the other repo in the first place).
Show 7 quoted lines
> > Secondly, you _can_ change a ref without it being the HEAD. Try > > > > git branch -f foo bar > > Sure. And what information would become unreachable if you delete 'foo' > at that point? The 'bar' commit is not lost, and likely to still exist > in some other reflog.
The fact that 'foo' was set to a particular sha1 at a particular point in time? Isn't that the point of a reflog?
Of course the 'bar' commit is not lost. My point is not that you are losing commits this way, it is that finding the commit you wanted becomes more difficult (e.g., asking "what was at the tip of the branch when it was deleted").
Show 5 quoted lines
> This is trivial.
>
> $ git log -g HEAD | grep -C2 "^Reflog.*moving from branch to"
>
> If the first hit is HEAD@{x} then your branch@{0} is just HEAD@{x+1}.That isn't too bad. But it really works only for branch@{0}, and it doesn't handle any of the non-HEAD cases I mentioned above.
> The naming of deleted reflogs when new branches with same name are > created, or the concatenation of entries for unrelated branches that > might happen to have existed under the same name.
It seems like there are only 3 options: clear the log upon deletion, clear the log upon making the new branch of the same name, or appending to the old log. I think the third makes the most sense, but there is probably room for a config option.
> And because the relevant entries are already in the HEAD reflog anyway, > and trivially retrieved as demonstrated above, I don't think it is worth > adding any additional complexity for what is only a convenience feature > that is not supposed to be used many times a day after all.
Fair enough. I actually also don't think it is personally worth my time to implement, which I suppose means I agree with you. But I don't think it's a bad idea, and I would have no objection if somebody else implemented it (which I guess that you do). I was mainly responding to Brian's post about whether it is a reasonable idea; I think it is.
-Peff