{"thread":{"id":"12082","subject":"A couple branch questions","startedAt":"2008-02-14T01:39:56Z","lastAt":"2008-02-14T20:17:00Z","messageCount":15,"participants":["Jay Soffian","David Symonds","Bill Lear","Junio C Hamano","Brian Downing","Nicolas Pitre","Johannes Schindelin","Jeff King","Jakub Narebski","Wincent Colaiuta"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"68695","messageId":"76718490802131739n22c56cadn39c1871ea1762dc3@mail.gmail.com","threadId":"12082","inReplyTo":null,"subject":"A couple branch questions","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-02-14T01:39:56Z","receivedAt":"2008-02-14T01:39:56Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"1) git-branch -d complains if hasn't been\nmerged to HEAD. Shouldn't it really only complain if \nhasn't been merged into any local branch? i.e., as long as\n has been merged, why care to which branch?\n\n2) Why does --track work only for remote tracking branches? I think it\nwould be useful for setting up topic branches. I've actually got this\nalias setup, but maybe a --topic option for git-checkout and\ngit-branch would be useful to others (?):\n\ntopic = \"!sh -c 'branch=$(git symbolic-ref HEAD); test -n \\\"$branch\\\"\n&& git co -b \\\"$1\\\" && git config branch.\\\"$1\\\".merge \\\"$branch\\\" &&\ngit config branch.\\\"$1\\\".remote . && git config branch.\\\"$1\\\".rebase\ntrue' -\"\n\nj.\n"},{"id":"68696","messageId":"ee77f5c20802131745p23aa1db3j47207f1e6538b0e@mail.gmail.com","threadId":"12082","inReplyTo":"76718490802131739n22c56cadn39c1871ea1762dc3@mail.gmail.com","subject":"Re: A couple branch questions","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2008-02-14T01:45:16Z","receivedAt":"2008-02-14T01:45:16Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Feb 13, 2008 5:39 PM, Jay Soffian wrote:\n> 1) git-branch -d complains if hasn't been\n> merged to HEAD. Shouldn't it really only complain if \n> hasn't been merged into any local branch? i.e., as long as\n> has been merged, why care to which branch?\n\nIt's easy to mistype branch names, and you typically only delete them\nafter you merge them into your current branch. If you're really sure,\njust pass -D instead of -d.\n\n\nDave.\n"},{"id":"68699","messageId":"18355.42595.377377.433309@lisa.zopyra.com","threadId":"12082","inReplyTo":"ee77f5c20802131745p23aa1db3j47207f1e6538b0e@mail.gmail.com","subject":"Re: A couple branch questions","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2008-02-14T02:24:35Z","receivedAt":"2008-02-14T02:24:35Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Wednesday, February 13, 2008 at 17:45:16 (-0800) David Symonds writes:\n>On Feb 13, 2008 5:39 PM, Jay Soffian wrote:\n>> 1) git-branch -d complains if hasn't been\n>> merged to HEAD. Shouldn't it really only complain if \n>> hasn't been merged into any local branch? i.e., as long as\n>> has been merged, why care to which branch?\n>\n>It's easy to mistype branch names, and you typically only delete them\n>after you merge them into your current branch. If you're really sure,\n>just pass -D instead of -d.\n\nHow does that answer the question posed?\n\n\nBill\n"},{"id":"68701","messageId":"ee77f5c20802131903i45b1629fpcb4a5c6e4f483052@mail.gmail.com","threadId":"12082","inReplyTo":"18355.42595.377377.433309@lisa.zopyra.com","subject":"Re: A couple branch questions","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2008-02-14T03:03:12Z","receivedAt":"2008-02-14T03:03:12Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Feb 13, 2008 6:24 PM, Bill Lear wrote:\n>\n> On Wednesday, February 13, 2008 at 17:45:16 (-0800) David Symonds writes:\n> >On Feb 13, 2008 5:39 PM, Jay Soffian wrote:\n> >> 1) git-branch -d complains if hasn't been\n> >> merged to HEAD. Shouldn't it really only complain if \n> >> hasn't been merged into any local branch? i.e., as long as\n> >> has been merged, why care to which branch?\n> >\n> >It's easy to mistype branch names, and you typically only delete them\n> >after you merge them into your current branch. If you're really sure,\n> >just pass -D instead of -d.\n>\n> How does that answer the question posed?\n\nIf I have four branches, a, b1, b2 and c, and I've merged b2 into c\n(but planning to keep developing on b2), and just merged b1 into a\n(which I have checked out), then I probably only want to delete b1,\nnot b2. The \"current\" branch is a useful notion because it\nsignificantly simplifies merging/rebasing operations.\n\n\nDave.\n"},{"id":"68702","messageId":"7vr6fgkxt2.fsf@gitster.siamese.dyndns.org","threadId":"12082","inReplyTo":"ee77f5c20802131903i45b1629fpcb4a5c6e4f483052@mail.gmail.com","subject":"Re: A couple branch questions","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-14T03:43:21Z","receivedAt":"2008-02-14T03:43:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"David Symonds\" writes:\n\n> If I have four branches, a, b1, b2 and c, and I've merged b2 into c\n> (but planning to keep developing on b2), and just merged b1 into a\n> (which I have checked out), then I probably only want to delete b1,\n> not b2. The \"current\" branch is a useful notion because it\n> significantly simplifies merging/rebasing operations.\n\nNot just \"simplifies\", but it tends to make it much safer.\n\nPeople often mistake that the safety of \"branch -d\" is to not\nlose the commit (i.e. not making it unreachable), but that is\nnot the case. That safety already exists in HEAD reflogs.\n\nThe \"branch -d\" safety is about not losing the particular point.\nThe information we really are trying to protect is \"this branch\npoints at _that commit_\", which is just as important if not\nmore.\n\nAnd immediately after merging that branch into your current\nbranch is where we can be fairly certain that you are truly done\nwith the branch and that did not make a typo, if we hear you say\n\"I do not need that branch anymore, delete it\". \"If it is\nmerged in _some random branch_\" does not give such an assurance\nand an inappropriate test for this purpose.\n\nI should point out that the current protection based on HEAD\npredates the invention of the \"branch --track\". If we were\ndesigning the safety today, it would have taken the form of \"if\nthe branch to be removed is fully merged in the branch that it\nused to be tracking, or the current branch, then it is safe to\nremove it.\".\n"},{"id":"68734","messageId":"20080214140152.GT27535@lavos.net","threadId":"12082","inReplyTo":"7vr6fgkxt2.fsf@gitster.siamese.dyndns.org","subject":"Keeping reflogs on branch deletion","fromName":"Brian Downing","fromEmail":"bdowning@lavos.net","sentAt":"2008-02-14T14:01:52Z","receivedAt":"2008-02-14T14:01:52Z","isPatch":false,"sender":{"key":"bdowning@lavos.net","avatar":"https://avatars.githubusercontent.com/u/366426?v=4"},"body":"On Wed, Feb 13, 2008 at 07:43:21PM -0800, Junio C Hamano wrote:\n> People often mistake that the safety of \"branch -d\" is to not\n> lose the commit (i.e. not making it unreachable), but that is\n> not the case. That safety already exists in HEAD reflogs.\n> \n> The \"branch -d\" safety is about not losing the particular point.\n> The information we really are trying to protect is \"this branch\n> points at _that commit_\", which is just as important if not\n> more.\n\nThis actually brings up something I've been intending to ask.\n\nWhen deleting a branch, is there any reason we can't add a deletion\nentry into the reflog and keep the reflog around? This would seem to be\na lot safer; I know I've been burned by expecting the reflog safety net\nto be there, and surprised that it's not when I've deleted a branch.\n\nI expect that the reflog entry would look something like this:\n\n0000000000000000000000000000000000000000 4685dfedd47683a476e75166b5c273c0269b7e54 Brian Downing 1202996833 -0600 branch: Created from ubuntu-dapper\n4685dfedd47683a476e75166b5c273c0269b7e54 0000000000000000000000000000000000000000 Brian Downing 1202996863 -0600 branch: Deleted\n\nA couple of problems I've noticed that would have to be fixed for this\nto work:\n\n* git log -g (and anything else that can take a reflog) would have to be\n fixed or modified to allow for taking branches that no longer exist:\n\n :; ls .git/logs/refs/heads/foo\n .git/logs/refs/heads/foo\n :; git log -g foo\n fatal: ambiguous argument 'foo': unknown revision or path not in the working tree.\n Use '--' to separate paths from revisions\n\n My uneducated suspicion is that this may be somewhat hard.\n\n* If the above did work, it would be nice for the deletion entry to\n result in a nice \"branch was deleted\" entry in log -g output. Today,\n that entry is missing in its entirety.\n\n-bcd\n"},{"id":"68736","messageId":"alpine.LFD.1.00.0802140945520.2732@xanadu.home","threadId":"12082","inReplyTo":"20080214140152.GT27535@lavos.net","subject":"Re: Keeping reflogs on branch deletion","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-02-14T15:00:58Z","receivedAt":"2008-02-14T15:00:58Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 14 Feb 2008, Brian Downing wrote:\n\n> On Wed, Feb 13, 2008 at 07:43:21PM -0800, Junio C Hamano wrote:\n> > People often mistake that the safety of \"branch -d\" is to not\n> > lose the commit (i.e. not making it unreachable), but that is\n> > not the case. That safety already exists in HEAD reflogs.\n> > \n> > The \"branch -d\" safety is about not losing the particular point.\n> > The information we really are trying to protect is \"this branch\n> > points at _that commit_\", which is just as important if not\n> > more.\n> \n> This actually brings up something I've been intending to ask.\n> \n> When deleting a branch, is there any reason we can't add a deletion\n> entry into the reflog and keep the reflog around? This would seem to be\n> a lot safer; I know I've been burned by expecting the reflog safety net\n> to be there, and surprised that it's not when I've deleted a branch.\n\nNo. That would only accumulate dead reflog files in the repository.\n\nAnd as Junio said above, the \"HEAD\" reflog contains everything you moved \nto, including detached heads, and of course branch heads that might now \nbe deleted. You can easily retrieve a deleted branch head from there.\n\nFor example, in my 'git log -g HEAD' output, I have:\n\n|commit 40aab8119f38c622f58d8e612e7a632eb1f3ded2 \n|Reflog: HEAD@{2} (Nicolas Pitre ) \n|Reflog message: checkout: moving from next to master\n\nIf I accidentally deleted my 'next' branch, I can retrieve it with \nHEAD@{3} which is the position HEAD was pointing to before moving away \nfrom 'next'. So, doing 'git branch next HEAD@{3}' would restore it.\n\n\nNicolas\n"},{"id":"68737","messageId":"alpine.LSU.1.00.0802141505440.30505@racer.site","threadId":"12082","inReplyTo":"alpine.LFD.1.00.0802140945520.2732@xanadu.home","subject":"Re: Keeping reflogs on branch deletion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-14T15:08:35Z","receivedAt":"2008-02-14T15:08:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 14 Feb 2008, Nicolas Pitre wrote:\n\n> On Thu, 14 Feb 2008, Brian Downing wrote:\n> \n> > When deleting a branch, is there any reason we can't add a deletion \n> > entry into the reflog and keep the reflog around? This would seem to \n> > be a lot safer; I know I've been burned by expecting the reflog safety \n> > net to be there, and surprised that it's not when I've deleted a \n> > branch.\n> \n> No. That would only accumulate dead reflog files in the repository.\n> \n> And as Junio said above, the \"HEAD\" reflog contains everything you moved \n> to, including detached heads, and of course branch heads that might now \n> be deleted. You can easily retrieve a deleted branch head from there.\n\nNote that you do not necessarily update branches while they are HEAD:\n\n\t$ git push . to-fast-forward:HEAD\n\nBut that's too fabricated an example, I guess.\n\nSo I agree that HEAD reflog is enough.\n\nCiao,\nDscho\n"},{"id":"68738","messageId":"20080214151752.GB3889@coredump.intra.peff.net","threadId":"12082","inReplyTo":"alpine.LFD.1.00.0802140945520.2732@xanadu.home","subject":"Re: Keeping reflogs on branch deletion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-14T15:17:52Z","receivedAt":"2008-02-14T15:17:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 14, 2008 at 10:00:58AM -0500, Nicolas Pitre wrote:\n\n> > When deleting a branch, is there any reason we can't add a deletion\n> > entry into the reflog and keep the reflog around? This would seem to be\n> > a lot safer; I know I've been burned by expecting the reflog safety net\n> > to be there, and surprised that it's not when I've deleted a branch.\n> \n> No. That would only accumulate dead reflog files in the repository.\n\nHow is that any different than accumulating old entries in reflog files\nfor branches that _do_ exist? In both cases, they should be dealt with\nvia time-based pruning.\n\n> And as Junio said above, the \"HEAD\" reflog contains everything you moved \n> to, including detached heads, and of course branch heads that might now \n> be deleted. You can easily retrieve a deleted branch head from there.\n\nBy that rationale, why do we bother keeping any reflog besides HEAD in\nthe first place? I can think of two reasons:\n\n 1. it's much more convenient to type branch@{1} than to sift through\n HEAD's reflog looking for checkout events and guessing which branch\n we were on\n 2. it's possible to change a ref without it being on the HEAD, in\n which case the HEAD reflog doesn't contain the change.\n\nIn other words, I don't see \"oops, I deleted this branch and its history\nis valuable to me\" as significantly less likely than \"oops, I got rid of\nthis commit and its history is valuable to me.\"\n\n-Peff\n"},{"id":"68740","messageId":"alpine.LFD.1.00.0802141103280.2732@xanadu.home","threadId":"12082","inReplyTo":"20080214151752.GB3889@coredump.intra.peff.net","subject":"Re: Keeping reflogs on branch deletion","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-02-14T16:16:20Z","receivedAt":"2008-02-14T16:16:20Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 14 Feb 2008, Jeff King wrote:\n\n> On Thu, Feb 14, 2008 at 10:00:58AM -0500, Nicolas Pitre wrote:\n> \n> > > When deleting a branch, is there any reason we can't add a deletion\n> > > entry into the reflog and keep the reflog around? This would seem to be\n> > > a lot safer; I know I've been burned by expecting the reflog safety net\n> > > to be there, and surprised that it's not when I've deleted a branch.\n> > \n> > No. That would only accumulate dead reflog files in the repository.\n> \n> How is that any different than accumulating old entries in reflog files\n> for branches that _do_ exist? In both cases, they should be dealt with\n> via time-based pruning.\n\nBranches that do exist are more likely to be interesting to you than \nbranches that, hopefully in 99% of all cases, you willfully deleted.\n\n> > And as Junio said above, the \"HEAD\" reflog contains everything you moved \n> > to, including detached heads, and of course branch heads that might now \n> > be deleted. You can easily retrieve a deleted branch head from there.\n> \n> By that rationale, why do we bother keeping any reflog besides HEAD in\n> the first place? I can think of two reasons:\n> \n> 1. it's much more convenient to type branch@{1} than to sift through\n> HEAD's reflog looking for checkout events and guessing which branch\n> we were on\n\nExact. But that doesn't apply to non existent branches, surely? And \nwhat would you do with the reflog of a deleted branch when a new branch \nis created with the same name?\n\n> 2. it's possible to change a ref without it being on the HEAD, in\n> which case the HEAD reflog doesn't contain the change.\n\nAnd in those cases this can't be due to your own modifications, hence \nnothing valuable is lost if you then delete that branch.\n\n> In other words, I don't see \"oops, I deleted this branch and its history\n> is valuable to me\" as significantly less likely than \"oops, I got rid of\n> this commit and its history is valuable to me.\"\n\nBut you still have it, in the HEAD reflog, at least for your own \nchanges. I therefore don't see the value of having to keep named branch \nreflogs around just for the small convenience, especially with the \nsemantic issues that comes with it.\n\n\nNicolas\n"},{"id":"68742","messageId":"20080214163101.GA24673@coredump.intra.peff.net","threadId":"12082","inReplyTo":"alpine.LFD.1.00.0802141103280.2732@xanadu.home","subject":"Re: Keeping reflogs on branch deletion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-14T16:31:01Z","receivedAt":"2008-02-14T16:31:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 14, 2008 at 11:16:20AM -0500, Nicolas Pitre wrote:\n\n> > How is that any different than accumulating old entries in reflog files\n> > for branches that _do_ exist? In both cases, they should be dealt with\n> > via time-based pruning.\n> \n> Branches that do exist are more likely to be interesting to you than \n> branches that, hopefully in 99% of all cases, you willfully deleted.\n\nI agree that they tend to be more interesting, but the point of reflogs\nis to have a log of operations performed for later examination. We\nalready have a well-defined boundary for \"interesting\": things that are\nolder than N days. Why introduce another such boundary? Are your reflogs\nfor deleted branches so large that you aren't willing to keep them?\n\n(There is actually one reason I can think of to get rid of reflogs for\ndeleted branches. Branch naming rules depend on which branches exist.\nThus I can have \"foo/bar\" only if \"foo\" does not exist, which means that\nI can only have a reflog for \"foo/bar\" if the one for \"foo\" has been\ndeleted. But that is a limitation of the current scheme for storing\nreflogs).\n\n> > 1. it's much more convenient to type branch@{1} than to sift through\n> > HEAD's reflog looking for checkout events and guessing which branch\n> > we were on\n> \n> Exact. But that doesn't apply to non existent branches, surely? And \n> what would you do with the reflog of a deleted branch when a new branch \n> is created with the same name?\n\nI think it does. Reflogs protect against changes in the \"commit\" space\nwithin a ref (things like \"git reset HEAD^\"). But there is no protection\nagainst changes in the \"ref\" space (like \"git branch -D foo\").\n\nAs for the behavior, I would just append. Your reflog would look like:\n\n branch@{0} - commit\n branch@{1} - create branch\n branch@{2} - delete branch\n branch@{3} - commit\n\nThe behavior would be identical for recently logged items. But instead\nof there being no branch@{3}, it would go back into the deleted branch.\n\n> > 2. it's possible to change a ref without it being on the HEAD, in\n> > which case the HEAD reflog doesn't contain the change.\n> \n> And in those cases this can't be due to your own modifications, hence \n> nothing valuable is lost if you then delete that branch.\n\nFor one thing, just because a modification wasn't _yours_ doesn't mean\nit isn't valuable. It entered your repository, and therefore it may be\nof interest.\n\nSecondly, you _can_ change a ref without it being the HEAD. Try\n\n git branch -f foo bar\n\n> > In other words, I don't see \"oops, I deleted this branch and its history\n> > is valuable to me\" as significantly less likely than \"oops, I got rid of\n> > this commit and its history is valuable to me.\"\n> \n> But you still have it, in the HEAD reflog, at least for your own \n> changes. I therefore don't see the value of having to keep named branch \n> reflogs around just for the small convenience, especially with the \n> semantic issues that comes with it.\n\nMy HEAD reflog has almost 1000 items in it. Finding out which commit\nwould have been branch@{0} in there is non-trivial.\n\nI agree that this information is less likely to be interesting than the\nusual use of reflogs. But I don't agree that the semantics are that\ndifficult. What issues are you talking about?\n\n-Peff\n"},{"id":"68743","messageId":"m33arvcx8x.fsf@localhost.localdomain","threadId":"12082","inReplyTo":"20080214140152.GT27535@lavos.net","subject":"Re: Keeping reflogs on branch deletion","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-14T16:35:08Z","receivedAt":"2008-02-14T16:35:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Brian Downing writes:\n\n> When deleting a branch, is there any reason we can't add a deletion\n> entry into the reflog and keep the reflog around? This would seem to be\n> a lot safer; I know I've been burned by expecting the reflog safety net\n> to be there, and surprised that it's not when I've deleted a branch.\n\nThere is techical problem with that, namely possibility of D/F\nconflict. When you delete branch 'foo', you can later create branch\n'foo/bar'. If reflog for 'foo' was not deleted, you couldn't create\nreflog for 'foo/bar' because of directory / file conflict.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"68754","messageId":"alpine.LFD.1.00.0802141147200.2732@xanadu.home","threadId":"12082","inReplyTo":"20080214163101.GA24673@coredump.intra.peff.net","subject":"Re: Keeping reflogs on branch deletion","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-02-14T17:32:07Z","receivedAt":"2008-02-14T17:32:07Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 14 Feb 2008, Jeff King wrote:\n\n> On Thu, Feb 14, 2008 at 11:16:20AM -0500, Nicolas Pitre wrote:\n> \n> > > How is that any different than accumulating old entries in reflog files\n> > > for branches that _do_ exist? In both cases, they should be dealt with\n> > > via time-based pruning.\n> > \n> > Branches that do exist are more likely to be interesting to you than \n> > branches that, hopefully in 99% of all cases, you willfully deleted.\n> \n> I agree that they tend to be more interesting, but the point of reflogs\n> is to have a log of operations performed for later examination. We\n> already have a well-defined boundary for \"interesting\": things that are\n> older than N days. Why introduce another such boundary? Are your reflogs\n> for deleted branches so large that you aren't willing to keep them?\n\nI typically have lots of branches. Many of those are fairly dynamic -- \nthey come and go. Keeping reflogs for them would only clutter the \nreflog space, especially when the same names are reused. I prefer to \nhave a clean reflog for the currently alive branch of a given name \nrather than having a log of anything that occurred under that name. And \nif I really want to find out about that old branch then there is always \nthe HEAD reflog.\n\n> (There is actually one reason I can think of to get rid of reflogs for\n> deleted branches. Branch naming rules depend on which branches exist.\n> Thus I can have \"foo/bar\" only if \"foo\" does not exist, which means that\n> I can only have a reflog for \"foo/bar\" if the one for \"foo\" has been\n> deleted. But that is a limitation of the current scheme for storing\n> reflogs).\n\nSure, and that limitation is IMHO quite sane. I don't think it is worth \nstretching it just for the convenience of having refs for deleted \nbranches elsewhere than from the HEAD reflog.\n\n> For one thing, just because a modification wasn't _yours_ doesn't mean\n> it isn't valuable. It entered your repository, and therefore it may be\n> of interest.\n\nAnd if you delete it then you can retrieve it again from its origin. \nIf, on the other hand, you _checkout_ that branch (it now entered the \nHEAD reflog), and _commit_ to it (which commit would be unreachable \nfrom other sources) then _that_ is a ref worth keeping a log of.\n\n> Secondly, you _can_ change a ref without it being the HEAD. Try\n> \n> git branch -f foo bar\n\nSure. And what information would become unreachable if you delete 'foo' \nat that point? The 'bar' commit is not lost, and likely to still exist \nin some other reflog.\n\n> > > In other words, I don't see \"oops, I deleted this branch and its history\n> > > is valuable to me\" as significantly less likely than \"oops, I got rid of\n> > > this commit and its history is valuable to me.\"\n> > \n> > But you still have it, in the HEAD reflog, at least for your own \n> > changes. I therefore don't see the value of having to keep named branch \n> > reflogs around just for the small convenience, especially with the \n> > semantic issues that comes with it.\n> \n> My HEAD reflog has almost 1000 items in it. Finding out which commit\n> would have been branch@{0} in there is non-trivial.\n\nThis is trivial.\n\n$ git log -g HEAD | grep -C2 \"^Reflog.*moving from branch to\"\n\nIf the first hit is HEAD@{x} then your branch@{0} is just HEAD@{x+1}.\n\n> I agree that this information is less likely to be interesting than the\n> usual use of reflogs. But I don't agree that the semantics are that\n> difficult. What issues are you talking about?\n\nThe naming of deleted reflogs when new branches with same name are \ncreated, or the concatenation of entries for unrelated branches that \nmight happen to have existed under the same name.\n\nAnd because the relevant entries are already in the HEAD reflog anyway, \nand trivially retrieved as demonstrated above, I don't think it is worth \nadding any additional complexity for what is only a convenience feature \nthat is not supposed to be used many times a day after all.\n\n\nNicolas\n"},{"id":"68757","messageId":"20080214175724.GA30689@coredump.intra.peff.net","threadId":"12082","inReplyTo":"alpine.LFD.1.00.0802141147200.2732@xanadu.home","subject":"Re: Keeping reflogs on branch deletion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-02-14T17:57:24Z","receivedAt":"2008-02-14T17:57:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 14, 2008 at 12:32:07PM -0500, Nicolas Pitre wrote:\n\n> I typically have lots of branches. Many of those are fairly dynamic -- \n> they come and go. Keeping reflogs for them would only clutter the \n> reflog space, especially when the same names are reused. I prefer to \n> have a clean reflog for the currently alive branch of a given name \n> rather than having a log of anything that occurred under that name. And \n> if I really want to find out about that old branch then there is always \n> the HEAD reflog.\n\nOK, that is a fair argument. I totally disagree, but this is a question\nof \"what users would want\" and you and I happen to want different\nbehavior. I suspect it has to do with how you name your branches.\n\n> > For one thing, just because a modification wasn't _yours_ doesn't mean\n> > it isn't valuable. It entered your repository, and therefore it may be\n> > of interest.\n> \n> And if you delete it then you can retrieve it again from its origin. \n\nIn a system which touts totally independent operation of separate\nrepositories, saying \"oh, you can just ask some other repository for it\nagain\" seems silly. Who is to say the other repo still exists? Or that\nit contains the information you're looking for (e.g., a git push from an\narbitrary commit at one repo may enter your branch at a specific point.\nthe information that is useful to you is where and when it landed in\nyour branch, which was never in the other repo in the first place).\n\n> > Secondly, you _can_ change a ref without it being the HEAD. Try\n> > \n> > git branch -f foo bar\n> \n> Sure. And what information would become unreachable if you delete 'foo' \n> at that point? The 'bar' commit is not lost, and likely to still exist \n> in some other reflog.\n\nThe fact that 'foo' was set to a particular sha1 at a particular point\nin time? Isn't that the point of a reflog?\n\nOf course the 'bar' commit is not lost. My point is not that you are\nlosing commits this way, it is that finding the commit you wanted\nbecomes more difficult (e.g., asking \"what was at the tip of the branch\nwhen it was deleted\").\n\n> This is trivial.\n> \n> $ git log -g HEAD | grep -C2 \"^Reflog.*moving from branch to\"\n> \n> If the first hit is HEAD@{x} then your branch@{0} is just HEAD@{x+1}.\n\nThat isn't too bad. But it really works only for branch@{0}, and it\ndoesn't handle any of the non-HEAD cases I mentioned above.\n\n> The naming of deleted reflogs when new branches with same name are \n> created, or the concatenation of entries for unrelated branches that \n> might happen to have existed under the same name.\n\nIt seems like there are only 3 options: clear the log upon deletion,\nclear the log upon making the new branch of the same name, or appending\nto the old log. I think the third makes the most sense, but there is\nprobably room for a config option.\n\n> And because the relevant entries are already in the HEAD reflog anyway, \n> and trivially retrieved as demonstrated above, I don't think it is worth \n> adding any additional complexity for what is only a convenience feature \n> that is not supposed to be used many times a day after all.\n\nFair enough. I actually also don't think it is personally worth my time\nto implement, which I suppose means I agree with you. But I don't think\nit's a bad idea, and I would have no objection if somebody else\nimplemented it (which I guess that you do). I was mainly responding to\nBrian's post about whether it is a reasonable idea; I think it is.\n\n-Peff\n"},{"id":"68771","messageId":"238738C7-960C-4847-A7F0-137712F7A7E8@wincent.com","threadId":"12082","inReplyTo":"20080214175724.GA30689@coredump.intra.peff.net","subject":"Re: Keeping reflogs on branch deletion","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-02-14T20:17:00Z","receivedAt":"2008-02-14T20:17:00Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 14/2/2008, a las 18:57, Jeff King escribió:\n\n> Of course the 'bar' commit is not lost. My point is not that you are\n> losing commits this way, it is that finding the commit you wanted\n> becomes more difficult (e.g., asking \"what was at the tip of the \n> branch\n> when it was deleted\").\n\nI agree that keeping around reflogs for deleted branches would be a \nnice convenience, provided they were pruned after an appropriate \ninterval. Space isn't really the concern, but clutter is, and that can \nbe fixed with pruning.\n\nCheers,\nWincent\n"}]}