{"thread":{"id":"34680","subject":"ephemeral-branches instead of detached-head?","startedAt":"2013-08-12T07:25:44Z","lastAt":"2013-08-14T16:40:49Z","messageCount":24,"participants":["David Jeske","Jonathan Nieder","Junio C Hamano","Duy Nguyen","Andreas Schwab","Sitaram Chamarty","Jeff King","Andres Perera"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"225081","messageId":"CA+CP9O6on2NXo6o4_0NoULnT8sgUD3pvvkFZvCTM5xKb38qOeA@mail.gmail.com","threadId":"34680","inReplyTo":null,"subject":"ephemeral-branches instead of detached-head?","fromName":"David Jeske","fromEmail":"davidj@gmail.com","sentAt":"2013-08-12T07:25:44Z","receivedAt":"2013-08-12T07:25:44Z","isPatch":false,"sender":{"key":"davidj@gmail.com","avatar":"https://gravatar.com/avatar/32edc832138d57a8f9e1aeb3cee801e6e349bebc54b2713b7af2b51c09893cd4?d=mp&s=160"},"body":"Has there ever been any any discussion of creating an ephemeral-branch\nname mechanism, instead of using detached HEADs?\n\nBy ephemeral, I mean that a branch-name could be created which would\nlive only so long as it is the only named way to reach a ref or the\nref is in the working directory. Ephemeral branch names would be\nlocal-only and would never be pushed.\n\nFor example, if one performed \"git checkout 2c29d...\", one would not\nget a detached head-state, but instead would get an ephemeral branch\nname similar to \"etmp/2c29d...\". If no changes were checked into this\nephemeral branch, it would disappear as soon as it was no longer in\nthe working directory. If any changes were checked in on this branch,\nit would survive until (a) the ref is given a non-ephemeral branch\nname, (b) the changes are merged, (c) the ephemeral branch is\ndeleted/discarded.\n\nI'm asking about (and proposing) this mechanism, because it would\nprevent refs from ever being \"accidentally lost\", such as occurs in\nthe following scenerios..\n\n1) forgetting to branch a detached head before checkin\n2) forgetting a head is detached before moving away from it\n3) forgetting about checkins before a submodule update\n\nAlso, these \"etmp/####\" branches would serve as an obvious visible\nreminder in the branch list that a change was checked in that should\neither be merged, named, or discarded.\n"},{"id":"225084","messageId":"20130812073942.GA18948@elie.Belkin","threadId":"34680","inReplyTo":"CA+CP9O6on2NXo6o4_0NoULnT8sgUD3pvvkFZvCTM5xKb38qOeA@mail.gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2013-08-12T07:39:54Z","receivedAt":"2013-08-12T07:39:54Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"David Jeske wrote:\n\n> Ephemeral branch names would be\n> local-only and would never be pushed.\n\nThat's how normal branch names behave (local branch names and remote\nbranch names live in different namespaces). How would the proposed\ndetached HEAD replacement compare to them? Would the temporary branch\ncreated by checking out a random commit be automatically deleted when\nchecking out another branch, or would it be garbage-collected at some\npoint later?\n\nCurious,\nJonathan\n"},{"id":"225089","messageId":"7veh9z1gym.fsf@alter.siamese.dyndns.org","threadId":"34680","inReplyTo":"CA+CP9O6on2NXo6o4_0NoULnT8sgUD3pvvkFZvCTM5xKb38qOeA@mail.gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-12T07:55:13Z","receivedAt":"2013-08-12T07:55:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Jeske writes:\n\n> I'm asking about (and proposing) this mechanism, because it would\n> prevent refs from ever being \"accidentally lost\", such as occurs in\n> the following scenerios..\n>\n> 1) forgetting to branch a detached head before checkin\n> 2) forgetting a head is detached before moving away from it\n> 3) forgetting about checkins before a submodule update\n\nAs Jonathan mentioned, your local branch namespace _is_ ephemeral in\nthe larger picture, and you can and should use your regular branches\nas such.\n\nI do not think any of the above will be helped by truly epheral\nbranch that are not consciously named by the end user.\n\n(1) is not a problem at all by itself with detached HEAD. You can\ncommit all you want, and the true problem people perceive that comes\nfrom (1) is (2), as they think they would lose commit that way. But\nthe thing is, the commits are not lost---they are recoverable from\nthe reflog of the HEAD itself. A truely ephemeral branch that users\ndo not consciously name would be referred to some random string\n(your etmp/4324 below) that is just as discoverable as an entry in\nthe reflog of the HEAD, so you didn't solve any problem here.\n\nI am not sure what you are trying to improve with (3) but I suspect\nit is just the same issue between (1) and (2) in the submodule\nworking tree. After running a submodule update in the superproject,\nyou will get into the detached HEAD state in the submodule, and that\nstate by itself is not a problem at all, but after committing and\nthen switching to other branch (or to another commit), the history\nleading to the tip commit will not be at the tip of any meaningfully\nnamed branch. That is different from a commit getting lost, and I\ndo not see how ephemerally created branches with random names would\nhelp people discover these commits better compared to reflog for the\nHEAD.\n\n> Also, these \"etmp/####\" branches would serve as an obvious visible\n> reminder in the branch list that a change was checked in that should\n> either be merged, named, or discarded.\n"},{"id":"225096","messageId":"CA+CP9O5fhyQrn3SboafocWJjaAywJHC0T-bw+AXk_8RX53hJ6Q@mail.gmail.com","threadId":"34680","inReplyTo":"7veh9z1gym.fsf@alter.siamese.dyndns.org","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"David Jeske","fromEmail":"davidj@gmail.com","sentAt":"2013-08-12T08:37:33Z","receivedAt":"2013-08-12T08:37:33Z","isPatch":false,"sender":{"key":"davidj@gmail.com","avatar":"https://gravatar.com/avatar/32edc832138d57a8f9e1aeb3cee801e6e349bebc54b2713b7af2b51c09893cd4?d=mp&s=160"},"body":"> Would the temporary branch created by checking out a random commit be automatically deleted when checking out another branch, or would it be garbage-collected at some\n> point later?\n\n\nYes, as I stated in my example, the ephemeral branch created from\nchecking out a random commit would be automatically deleted anytime\nthere was another downstream name for the ref (and the ref was no\nlonger in the working-directory). Another way to think of the proposal\nis to allowed detached-HEADs, but automatically create ephemeral\nbranch-names when checking into a detached head.\n\nOn Mon, Aug 12, 2013 at 12:55 AM, Junio C Hamano wrote:\n> As Jonathan mentioned, your local branch namespace _is_ ephemeral in\n> the larger picture, and you can and should use your regular branches\n> as such.\n\nThis is not the case. To me \"ephemeral\" means that the branch name\nautomatically disappears if nothing gets checked into it. The local\nbranch names definitely do not operate this way.\n\n> (1) is not a problem at all by itself with detached HEAD. You can\n> commit all you want, and the true problem people perceive that comes\n> from (1) is (2), as they think they would lose commit that way.\n\nIt is not a matter of a commit being destroyed, as I know they are not\ndestroyed, it is a matter of \"losing\" as in it being a\npain-in-the-a-s-s to find the darn thing.\n\nThe reflog is only really useful for a short time. If you don't notice\nuntil later, it's too late for this to be a reasonable way to find the\nmissing commit.. and this assumes you noticed at all.\n\nFor as long as I've used git, I simplu don't understand why I should\nbe able to commit something, and have it go \"missing\" in the branch\nnamespace without an explicit action on my part.\n\n> A truely ephemeral branch that users do not consciously name would be referred to some random string (your etmp/4324 below) that is just as discoverable as an entry in\n> the reflog of the HEAD, so you didn't solve any problem here.\n\nThis is simply not true.\n\nThe reflog is filled with every reflog action. Any checkout, push,\npull, existing commits, etc. The ephemeral space would *only* contain\ndangling refs that were not named, merged, or discarded.\n\n> ...the history leading to the tip commit will not be at the tip of any meaningfully\n>\n> named branch. That is different from a commit getting lost, and I\n> do not see how ephemerally created branches with random names would\n> help people discover these commits better compared to reflog for the\n> HEAD.\n\nIs there currently any way to say \"hey, git, show me what commits are\ndangling that might be lost in the reflog?\"\n\nI'm not aware of one. This is the difference. It's making the action\nof throwing away a dangling ref more explicit.\n"},{"id":"225103","messageId":"CA+CP9O7--HXQdZXH9MJEh0VqdwpYqb052KYrvZqYhbfajpPG0A@mail.gmail.com","threadId":"34680","inReplyTo":"CA+CP9O5fhyQrn3SboafocWJjaAywJHC0T-bw+AXk_8RX53hJ6Q@mail.gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"David Jeske","fromEmail":"davidj@gmail.com","sentAt":"2013-08-12T12:14:42Z","receivedAt":"2013-08-12T12:14:42Z","isPatch":false,"sender":{"key":"davidj@gmail.com","avatar":"https://gravatar.com/avatar/32edc832138d57a8f9e1aeb3cee801e6e349bebc54b2713b7af2b51c09893cd4?d=mp&s=160"},"body":"@Junio - to put the issue in the context of your previous comments on\nthe topic... way back when you made a comment about warnings during\ncommits to detached heads..\n\nhttp://git.661346.n2.nabble.com/RFC-Detached-HEAD-reminder-on-commit-td834710.html#a834959\n\n> If we _really_ don't want newbies to shoot themselves in the foot, we\n> probably can issue a loud warning when they detach there HEAD.\n> Oh, wait,... we already do that.\n\n\nThe reason this rationale doesn't ring true for me, is that it is\n*very* common for me to checkout a detached-head and there is nothing\nodd or dangerous about it. I do this when using checkout to move\naround the history to inspect, build, and test different revisions. As\na result, it's very easy to just start ignoring this (usually\nmeaningless) message.\n\nThe dangerous situation only occurs when something is committed onto a\ndetached-head, and at this point there is no warning. The \"# Not\ncurrently on any branch\" message that appears during \"git status\"\neasily blends in with boilerplate text there.\n\nIMO, the current warning during checkout of a detached-head is\nmisplaced. It should be removed, and instead there should only be a\nwarning after detached-head commit, since this is the only time there\nis a danger of losing something.\n\nWith my proposed \"ephemeral branch\" concept, there is no warning\nnecessary in either case, since any check-ins left dangling would get\nnames in the branch space you could see and take a look at. If that\ndangling head was temporary and was named or rebased, the ephemeral\nbranch name would disappear automatically, leaving the expert-user\nwith no warnings and no annoyance, while the novice user with a simple\ntool to help them not lose track of changes they made.\n"},{"id":"225109","messageId":"CACsJy8A-aSjNdSkiBUBSH43G_FBMnShfpkcwQqM9-6d41rfCUA@mail.gmail.com","threadId":"34680","inReplyTo":"CA+CP9O7--HXQdZXH9MJEh0VqdwpYqb052KYrvZqYhbfajpPG0A@mail.gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-08-12T13:23:04Z","receivedAt":"2013-08-12T13:23:04Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Aug 12, 2013 at 7:14 PM, David Jeske wrote:\n> IMO, the current warning during checkout of a detached-head is\n> misplaced. It should be removed, and instead there should only be a\n> warning after detached-head commit, since this is the only time there\n> is a danger of losing something.\n\nThat would annoy me as I often work on top of detached HEAD on purpose\nand only create a branch when I want to save something. If the warning\nis to be moved, it should warn at the next checkout.\n-- \nDuy\n"},{"id":"225115","messageId":"877gfqkfhd.fsf@igel.home","threadId":"34680","inReplyTo":"CACsJy8A-aSjNdSkiBUBSH43G_FBMnShfpkcwQqM9-6d41rfCUA@mail.gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2013-08-12T17:04:30Z","receivedAt":"2013-08-12T17:04:30Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"Duy Nguyen writes:\n\n> That would annoy me as I often work on top of detached HEAD on purpose\n> and only create a branch when I want to save something. If the warning\n> is to be moved, it should warn at the next checkout.\n\n$ git checkout master\nWarning: you are leaving 1 commit behind, not connected to\nany of your branches:\n\n 0e3618e a\n\nSwitched to branch 'master'\n\nAndreas.\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5\n\"And now for something completely different.\"\n"},{"id":"225119","messageId":"7vob92zuww.fsf@alter.siamese.dyndns.org","threadId":"34680","inReplyTo":"CA+CP9O7--HXQdZXH9MJEh0VqdwpYqb052KYrvZqYhbfajpPG0A@mail.gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-12T17:22:07Z","receivedAt":"2013-08-12T17:22:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Jeske writes:\n\n> @Junio - to put the issue in the context of your previous comments on\n> the topic... way back when you made a comment about warnings during\n> commits to detached heads..\n>\n> http://git.661346.n2.nabble.com/RFC-Detached-HEAD-reminder-on-commit-td834710.html#a834959\n>\n>> If we _really_ don't want newbies to shoot themselves in the foot, we\n>> probably can issue a loud warning when they detach there HEAD.\n>> Oh, wait,... we already do that.\n>\n> The reason this rationale doesn't ring true for me, is that it is\n> *very* common for me to checkout a detached-head and there is nothing\n> odd or dangerous about it.\n\nYou do not have to say that to me _now_ ;-) because after makinng\nthe above ancient comment others have corrected me, I agreed with\nthem, and we no longer rely on that \"you are detaching, danger\nahead\" warning.\n\nWith the same line of reasoning, the place where users make commits\non detached HEAD is not where the danger arises, either; the real\ndanger is where you switch out of the detached HEAD state, and I\nthink we do give a loud warning there.\n"},{"id":"225120","messageId":"7vk3jqzush.fsf@alter.siamese.dyndns.org","threadId":"34680","inReplyTo":"CACsJy8A-aSjNdSkiBUBSH43G_FBMnShfpkcwQqM9-6d41rfCUA@mail.gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-12T17:24:46Z","receivedAt":"2013-08-12T17:24:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> On Mon, Aug 12, 2013 at 7:14 PM, David Jeske wrote:\n>> IMO, the current warning during checkout of a detached-head is\n>> misplaced. It should be removed, and instead there should only be a\n>> warning after detached-head commit, since this is the only time there\n>> is a danger of losing something.\n>\n> That would annoy me as I often work on top of detached HEAD on purpose\n> and only create a branch when I want to save something. If the warning\n> is to be moved, it should warn at the next checkout.\n\nDon't we already do that?\n\n Warning: you are leaving N commits behind, not connected to\n any of your branches:\n\n ... list of commits to be lost ...\n\n\n If you want to keep them by creating a new branch, this may be a\n good time\n to do so with:\n\n git branch new_branch_name xxxxxx\n\n Switched to branch 'master'\n"},{"id":"225122","messageId":"CA+CP9O6LG-dfeEKOCs48Qv9kSS4NqW1bKY8HrLeJmx2drqqSdg@mail.gmail.com","threadId":"34680","inReplyTo":"CACsJy8A-aSjNdSkiBUBSH43G_FBMnShfpkcwQqM9-6d41rfCUA@mail.gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"David Jeske","fromEmail":"davidj@gmail.com","sentAt":"2013-08-12T19:05:09Z","receivedAt":"2013-08-12T19:05:09Z","isPatch":false,"sender":{"key":"davidj@gmail.com","avatar":"https://gravatar.com/avatar/32edc832138d57a8f9e1aeb3cee801e6e349bebc54b2713b7af2b51c09893cd4?d=mp&s=160"},"body":"On Mon, Aug 12, 2013 at 6:23 AM, Duy Nguyen wrote:\n> That would annoy me as I often work on top of detached HEAD on purpose\n> and only create a branch when I want to save something. If the warning\n> is to be moved, it should warn at the next checkout.\n\nYes, you're absolutely right ...\n\nMy point about the current checkout warning is that it's crying wolf,\nand nullifying the value of the warning. Most of the time I checkout a\nref, I'm not doing anything dangerous because I'm not going to check\nanything in. The warning would be more effective if it warns in as\nnarrow a situation as possible. You're correct that the clobber is\neven more narrow than the checkin.\n\nThe warning on clobber would be similar to (but shorter than) the one\nwhich could be removed from checkout..\n\nClobbered detached HEAD 'cce40d6'!\n\n git log cce40d6 ^master # log detached changes vs master\n git branch cc340d6 # name the changes with a branch\n\nPersonally, I'd prefer for explicit action to discard a detached head.\nIt's true that this is an explicit step, but for me it generally takes\na heck of alot less time to explicitly discard than it did to checkout\nthe detached head, make changes (or apply a patch), and then decide to\nthrow them away.\n\nMy \"ephemeral branch\" idea was a way to make this explicit discard as\npassive and lazy as possible. Basically, never stop you from doing\nyour work, assume you know what you are doing. If the user\nnames-the-branch it disappears. If the user merges or rebases the\ndetached head, it disappears. The only time the \"ephemeral branch\"\nwould survive is if the user really clobbered a detached head and then\ndidn't do anything about it. Even if they missed the warning (in the\nmiddle of a script or automated process), eventually they would see\nthe ephemeral branch lying around.\n\nClobbering a detached head with \"ephemeral branches\" could show no\nwarning at all, or a warning like:\n\nClobbered detached HEAD.\n\n git log cce40d6 ^master # log detached changes vs master\n git branch -D tmp/cce40d6 # Discard these changes\n git branch tmp/cce40d6 # name this branch\n"},{"id":"225123","messageId":"CA+CP9O6KQ8vB1k0necmKx3daekmybx5k11sUw4n+b-9SygM5nQ@mail.gmail.com","threadId":"34680","inReplyTo":"7vk3jqzush.fsf@alter.siamese.dyndns.org","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"David Jeske","fromEmail":"davidj@gmail.com","sentAt":"2013-08-12T19:40:39Z","receivedAt":"2013-08-12T19:40:39Z","isPatch":false,"sender":{"key":"davidj@gmail.com","avatar":"https://gravatar.com/avatar/32edc832138d57a8f9e1aeb3cee801e6e349bebc54b2713b7af2b51c09893cd4?d=mp&s=160"},"body":"On Mon, Aug 12, 2013 at 10:24 AM, Junio C Hamano wrote:\n> Don't we already do that?\n>\n> Warning: you are leaving N commits behind, not connected to\n> any of your branches:\n>\n> ... list of commits to be lost ...\n\nThis only shows on checkout... not reset, not submodule-update, nor\nany other ways you can clobber a detached head.\n"},{"id":"225130","messageId":"CACsJy8Dke6Pezqsdcjzejc_cWCgOGTGs8LifjM2h2TQJy7N4HA@mail.gmail.com","threadId":"34680","inReplyTo":"CA+CP9O5fhyQrn3SboafocWJjaAywJHC0T-bw+AXk_8RX53hJ6Q@mail.gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-08-13T06:05:52Z","receivedAt":"2013-08-13T06:05:52Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Aug 12, 2013 at 3:37 PM, David Jeske wrote:\n> Is there currently any way to say \"hey, git, show me what commits are\n> dangling that might be lost in the reflog?\"\n\nHow do you define dangling commits? When you do \"git commit --amend\",\nthe current commit will become dangling (in the sense that it's not\nreferred by any ref, but the commit exists) and those are just noise\nin my opinion.\n-- \nDuy\n"},{"id":"225144","messageId":"CACsJy8B7PrOr8YX0d05dw75tfCVNWEJ-YPDe414yTzgQe2Ea=w@mail.gmail.com","threadId":"34680","inReplyTo":"CA+CP9O5Ak3YD60--Mj+eLv3qzbZuuwTN-AxY3xb=SciKD=uZoQ@mail.gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2013-08-13T15:13:48Z","receivedAt":"2013-08-13T15:13:48Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Aug 13, 2013 at 9:44 PM, David Jeske wrote:\n> On Aug 12, 2013 11:06 PM, \"Duy Nguyen\" wrote:\n>>\n>> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske wrote:\n>> > Is there currently any way to say \"hey, git, show me what commits are\n>> > dangling that might be lost in the reflog?\"\n>>\n>> How do you define dangling commits?\n>\n> Any commit which I did not explicitly do something with. (Merge, rebase,\n> amend, branch name, discard)\n>\n> Today every one of those actions is explicit except discard.\n\nSo basically everything that is (1) produced by \"git commit\", (2) not\nconnected to any ref and (3) not an amend. I think (1) and (3) can be\nachieved with \"git log -g --grep-reflog commit: HEAD\". We only need to\nfilter out ones that are connected to some ref. Not sure if that can\nbe done with script though. Maybe add \"--dangling\" to \"git log -g\" to\ndo such filtering?\n-- \nDuy\n"},{"id":"225145","messageId":"CA+CP9O5cK_zuRRj6uBdW_H7XO-w=B=vcjQsT1iF70Ce-jc02Ow@mail.gmail.com","threadId":"34680","inReplyTo":"CA+CP9O5Ak3YD60--Mj+eLv3qzbZuuwTN-AxY3xb=SciKD=uZoQ@mail.gmail.com","subject":"Fwd: ephemeral-branches instead of detached-head?","fromName":"David Jeske","fromEmail":"davidj@gmail.com","sentAt":"2013-08-13T15:36:26Z","receivedAt":"2013-08-13T15:36:26Z","isPatch":false,"sender":{"key":"davidj@gmail.com","avatar":"https://gravatar.com/avatar/32edc832138d57a8f9e1aeb3cee801e6e349bebc54b2713b7af2b51c09893cd4?d=mp&s=160"},"body":"On Aug 12, 2013 11:06 PM, \"Duy Nguyen\" wrote:\n\n>\n> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske wrote:\n> > Is there currently any way to say \"hey, git, show me what commits are\n> > dangling that might be lost in the reflog?\"\n>\n> How do you define dangling commits?\n\nAny commit which I did not explicitly do something with. (Merge,\nrebase, amend, branch name, discard)\n\nToday every one of those actions is explicit except discard.\n\n> When you do \"git commit --amend\",\n> the current commit will become dangling (in the sense that it's not\n> referred by any ref, but the commit exists) and those are just noise\n> in my opinion.\n\nThis is *exactly* my point.\n\nThere is no way to distinguish a commit which was accidentally and\nimplicitly dangled due to checkout or submodule update on a detached\nhead, from all those other intentionally dangling refs which were\nexplicitly handled with merge, rebase, amend.\n\nEphemeral branches would change only the implicit discard.. Turning it\ninto a named branch and requiring an explicit discard.\n"},{"id":"225152","messageId":"7vk3jpy1qt.fsf@alter.siamese.dyndns.org","threadId":"34680","inReplyTo":"CACsJy8Dke6Pezqsdcjzejc_cWCgOGTGs8LifjM2h2TQJy7N4HA@mail.gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-13T16:49:46Z","receivedAt":"2013-08-13T16:49:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske wrote:\n>> Is there currently any way to say \"hey, git, show me what commits are\n>> dangling that might be lost in the reflog?\"\n>\n> How do you define dangling commits? When you do \"git commit --amend\",\n> the current commit will become dangling (in the sense that it's not\n> referred by any ref, but the commit exists) and those are just noise\n> in my opinion.\n\n\"fsck lost-and-found\" would be one way. It would be nice if we had\nsomething like (note: the following will _NOT_ work)\n\n\tgit log -g HEAD --not --branches\n\nto say \"walk the reflog of HEAD, but exclude anything that can be\nreached from the tips of branches\".\n"},{"id":"225153","messageId":"7vbo51y1bi.fsf@alter.siamese.dyndns.org","threadId":"34680","inReplyTo":"CA+CP9O5cK_zuRRj6uBdW_H7XO-w=B=vcjQsT1iF70Ce-jc02Ow@mail.gmail.com","subject":"Re: Fwd: ephemeral-branches instead of detached-head?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-13T16:58:57Z","receivedAt":"2013-08-13T16:58:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Jeske writes:\n\n>> When you do \"git commit --amend\",\n>> the current commit will become dangling (in the sense that it's not\n>> referred by any ref, but the commit exists) and those are just noise\n>> in my opinion.\n>\n> This is *exactly* my point.\n>\n> There is no way to distinguish a commit which was accidentally and\n> implicitly dangled due to checkout or submodule update on a detached\n> head, from all those other intentionally dangling refs which were\n> explicitly handled with merge, rebase, amend.\n\nI do not follow. Just like \"commit --amend\", checking out another\nbranch to leave a detached HEAD _is_ an explicit way to discard what\nyou started experimenting behind, declaring it useless. Otherwise\nyou would have saved it to some named branch.\n\nThis of course assumes that, as you said in one of your earlier\nmessages, the user knows what he is doing, though.\n"},{"id":"225155","messageId":"7v38qdy0o2.fsf@alter.siamese.dyndns.org","threadId":"34680","inReplyTo":"7vbo51y1bi.fsf@alter.siamese.dyndns.org","subject":"Re: Fwd: ephemeral-branches instead of detached-head?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-13T17:13:01Z","receivedAt":"2013-08-13T17:13:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> David Jeske writes:\n>\n>>> When you do \"git commit --amend\",\n>>> the current commit will become dangling (in the sense that it's not\n>>> referred by any ref, but the commit exists) and those are just noise\n>>> in my opinion.\n>>\n>> This is *exactly* my point.\n>>\n>> There is no way to distinguish a commit which was accidentally and\n>> implicitly dangled due to checkout or submodule update on a detached\n>> head, from all those other intentionally dangling refs which were\n>> explicitly handled with merge, rebase, amend.\n>\n> I do not follow. Just like \"commit --amend\", checking out another\n> branch to leave a detached HEAD _is_ an explicit way to discard what\n> you started experimenting behind, declaring it useless. Otherwise\n> you would have saved it to some named branch.\n>\n> This of course assumes that, as you said in one of your earlier\n> messages, the user knows what he is doing, though.\n\nBy the way, by the above I do not mean \"checking out a named branch\nshould not be protected\". I am saying \"treating commits lost by\nrunning 'commit --amend' differently does not make sense to me\".\n"},{"id":"225172","messageId":"520AC9A8.4030104@gmail.com","threadId":"34680","inReplyTo":"7vk3jpy1qt.fsf@alter.siamese.dyndns.org","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2013-08-14T00:04:56Z","receivedAt":"2013-08-14T00:04:56Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 08/13/2013 10:19 PM, Junio C Hamano wrote:\n> Duy Nguyen writes:\n> \n>> On Mon, Aug 12, 2013 at 3:37 PM, David Jeske wrote:\n>>> Is there currently any way to say \"hey, git, show me what commits are\n>>> dangling that might be lost in the reflog?\"\n>>\n>> How do you define dangling commits? When you do \"git commit --amend\",\n>> the current commit will become dangling (in the sense that it's not\n>> referred by any ref, but the commit exists) and those are just noise\n>> in my opinion.\n> \n> \"fsck lost-and-found\" would be one way. It would be nice if we had\n> something like (note: the following will _NOT_ work)\n> \n> \tgit log -g HEAD --not --branches\n> \n> to say \"walk the reflog of HEAD, but exclude anything that can be\n> reached from the tips of branches\".\n\nI've been using the following 3 aliases for some time now, to find\nvarious dangling stuff. The middle one (d1) seems to do approximately\nwhat you want, but will probably fail on repos with lots of activity\nwhen the command line length limit is (b)reached.\n\n # all stashed entries (since they don't chain)\n sk = !gitk --date-order $(git stash list | cut -d: -f1) --not --branches --tags --remotes\n # all reflog entries that are not on a branch, tag, or remote\n d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes\n # all dangling commits not on a branch, tag, or remote\n d2 = !gitk --date-order $(git fsck | grep \"dangling.commit\" | cut -f3 -d' ') --not --branches --tags --remotes\n\n(Apologies if something like this was already said; I was not following\nthe discussion closely enough to notice)\n"},{"id":"225174","messageId":"7vmwolujvb.fsf@alter.siamese.dyndns.org","threadId":"34680","inReplyTo":"520AC9A8.4030104@gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-08-14T01:44:08Z","receivedAt":"2013-08-14T01:44:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sitaram Chamarty writes:\n\n> # all reflog entries that are not on a branch, tag, or remote\n> d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes\n> # all dangling commits not on a branch, tag, or remote\n> d2 = !gitk --date-order $(git fsck | grep \"dangling.commit\" | cut -f3 -d' ') --not --branches --tags --remotes\n>\n> (Apologies if something like this was already said; I was not following\n> the discussion closely enough to notice)\n\nYup.\n\nA potential problem is that the output from \"log -g --pretty=%H\" or\n\"fsck | grep dangling\" may turn out to be humongous. Other than\nthat, they correctly compute what you want.\n"},{"id":"225177","messageId":"520B2478.3000100@gmail.com","threadId":"34680","inReplyTo":"7vmwolujvb.fsf@alter.siamese.dyndns.org","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2013-08-14T06:32:24Z","receivedAt":"2013-08-14T06:32:24Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 08/14/2013 07:14 AM, Junio C Hamano wrote:\n> Sitaram Chamarty writes:\n> \n>> # all reflog entries that are not on a branch, tag, or remote\n>> d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes\n>> # all dangling commits not on a branch, tag, or remote\n>> d2 = !gitk --date-order $(git fsck | grep \"dangling.commit\" | cut -f3 -d' ') --not --branches --tags --remotes\n>>\n>> (Apologies if something like this was already said; I was not following\n>> the discussion closely enough to notice)\n> \n> Yup.\n> \n> A potential problem is that the output from \"log -g --pretty=%H\" or\n> \"fsck | grep dangling\" may turn out to be humongous. Other than\n> that, they correctly compute what you want.\n\nI thought I mentioned that but I can't find my email now so maybe I\ndidn't.\n\nIn practice though, I find that, bash at least seems happy to take\ncommand lines as long as 7+ million characters long, so with the default\nreflog expire times, that should work out to 10,000 commits *per day*.\n[Tested with: echo {1000000..1900000} > junk; echo `cat junk` | wc]\n\nIncidentally, am I the only one who thinks the default values for\ngc.reflogexpire (90 days) and gc.reflogexpireunreachable (30) should be\nreversed?\n\nIn terms of recovering potentially lost commits at least, it seems it\nwould make more sense that something that is UNreachable have a longer\nexpiry, whereas stuff that's reachable... that's only a quick \"gitk\"\nbrowse away.\n\nDesign question: is the primary purpose of the reflog \"what was I doing\nX days ago\" or is it \"I need some code from a commit that got rebased\nout [or whatever] X days ago\"?\n\nI have always only used the reflog for the latter.\n"},{"id":"225180","messageId":"20130814065933.GB3744@sigill.intra.peff.net","threadId":"34680","inReplyTo":"520B2478.3000100@gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-08-14T06:59:33Z","receivedAt":"2013-08-14T06:59:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Aug 14, 2013 at 12:02:24PM +0530, Sitaram Chamarty wrote:\n\n> >> # all reflog entries that are not on a branch, tag, or remote\n> >> d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes\n> [...]\n>\n> > A potential problem is that the output from \"log -g --pretty=%H\" or\n> > \"fsck | grep dangling\" may turn out to be humongous. Other than\n> > that, they correctly compute what you want.\n> \n> I thought I mentioned that but I can't find my email now so maybe I\n> didn't.\n> \n> In practice though, I find that, bash at least seems happy to take\n> command lines as long as 7+ million characters long, so with the default\n> reflog expire times, that should work out to 10,000 commits *per day*.\n> [Tested with: echo {1000000..1900000} > junk; echo `cat junk` | wc]\n\nYou can also do:\n\n git log -g --pretty=%H |\n git log --stdin --not --branches --tags --remotes\n\nto avoid any argv limitations.\n\n-Peff\n"},{"id":"225182","messageId":"CAPrKj1ZQL0N7VFfZ3qS14Nhp8O4Kaez9QWK7AvqCXZds1Q=mRw@mail.gmail.com","threadId":"34680","inReplyTo":"520B2478.3000100@gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Andres Perera","fromEmail":"andres.p@zoho.com","sentAt":"2013-08-14T07:10:39Z","receivedAt":"2013-08-14T07:10:39Z","isPatch":false,"sender":{"key":"andres.p@zoho.com","avatar":null},"body":"On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty wrote:\n> On 08/14/2013 07:14 AM, Junio C Hamano wrote:\n>> Sitaram Chamarty writes:\n>>\n>>> # all reflog entries that are not on a branch, tag, or remote\n>>> d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes\n>>> # all dangling commits not on a branch, tag, or remote\n>>> d2 = !gitk --date-order $(git fsck | grep \"dangling.commit\" | cut -f3 -d' ') --not --branches --tags --remotes\n>>>\n>>> (Apologies if something like this was already said; I was not following\n>>> the discussion closely enough to notice)\n>>\n>> Yup.\n>>\n>> A potential problem is that the output from \"log -g --pretty=%H\" or\n>> \"fsck | grep dangling\" may turn out to be humongous. Other than\n>> that, they correctly compute what you want.\n>\n> I thought I mentioned that but I can't find my email now so maybe I\n> didn't.\n>\n> In practice though, I find that, bash at least seems happy to take\n> command lines as long as 7+ million characters long, so with the default\n> reflog expire times, that should work out to 10,000 commits *per day*.\n> [Tested with: echo {1000000..1900000} > junk; echo `cat junk` | wc]\n\necho is a builtin in bash, as is the case with other shell implementations\n\nbuiltins may have different limit's than exec()'s ARG_MAX\n\n$ getconf ARG_MAX\n262144\n$ perl -e 'print \"A\" x (262144 * 2)' | wc -c\n 524288\n$ perl -e 'print \"A\" x (262144 * 2)' | sh -c 'read v; echo \"$v\"' | wc -c\n 524289\n$ perl -e 'print \"A\" x (262144 * 2)' | sh -c 'read v; /bin/echo \"$v\"' | wc -c\nsh: /bin/echo: Argument list too long\n 0\n\nbuiltin's argument buffer limit tends to be aligned with the\nimplementation's lexer buffer limit\n"},{"id":"225191","messageId":"520B486D.1040602@gmail.com","threadId":"34680","inReplyTo":"CAPrKj1ZQL0N7VFfZ3qS14Nhp8O4Kaez9QWK7AvqCXZds1Q=mRw@mail.gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2013-08-14T09:05:49Z","receivedAt":"2013-08-14T09:05:49Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On 08/14/2013 12:40 PM, Andres Perera wrote:\n> On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty wrote:\n>> On 08/14/2013 07:14 AM, Junio C Hamano wrote:\n>>> Sitaram Chamarty writes:\n>>>\n>>>> # all reflog entries that are not on a branch, tag, or remote\n>>>> d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes\n>>>> # all dangling commits not on a branch, tag, or remote\n>>>> d2 = !gitk --date-order $(git fsck | grep \"dangling.commit\" | cut -f3 -d' ') --not --branches --tags --remotes\n>>>>\n>>>> (Apologies if something like this was already said; I was not following\n>>>> the discussion closely enough to notice)\n>>>\n>>> Yup.\n>>>\n>>> A potential problem is that the output from \"log -g --pretty=%H\" or\n>>> \"fsck | grep dangling\" may turn out to be humongous. Other than\n>>> that, they correctly compute what you want.\n>>\n>> I thought I mentioned that but I can't find my email now so maybe I\n>> didn't.\n>>\n>> In practice though, I find that, bash at least seems happy to take\n>> command lines as long as 7+ million characters long, so with the default\n>> reflog expire times, that should work out to 10,000 commits *per day*.\n>> [Tested with: echo {1000000..1900000} > junk; echo `cat junk` | wc]\n> \n> echo is a builtin in bash, as is the case with other shell implementations\n> \n> builtins may have different limit's than exec()'s ARG_MAX\n> \n> $ getconf ARG_MAX\n> 262144\n> $ perl -e 'print \"A\" x (262144 * 2)' | wc -c\n> 524288\n> $ perl -e 'print \"A\" x (262144 * 2)' | sh -c 'read v; echo \"$v\"' | wc -c\n> 524289\n> $ perl -e 'print \"A\" x (262144 * 2)' | sh -c 'read v; /bin/echo \"$v\"' | wc -c\n> sh: /bin/echo: Argument list too long\n> 0\n> \n> builtin's argument buffer limit tends to be aligned with the\n> implementation's lexer buffer limit\n\nAah; good catch -- I did not know this. Thanks!\n\nMy systems show 2621440 on CentOS 6 and 2097152 on Fedora 19, so --\ndividing by 8 (abbrev SHA + space) then by 90, that's still 2900 commits\n*per day* to run past this limit though!\n\n(side note: making a single argument that long seems to have a much\nlower limit than having multiple arguments:\n\n $ /bin/echo `perl -e 'print \"A\" x (1000000)'` | wc\n -bash: /bin/echo: Argument list too long\n 0 0 0\n $ /bin/echo `perl -e 'print \"A \" x (1000000)'` | wc\n 1 1000000 2000000\n\nnotice that the second one is twice as long in terms of bytes, but it's\nnot a single argument).\n"},{"id":"225211","messageId":"CAPrKj1acdFGqkpzSANq_jUst_994e0sFFq+m4Q3wa7qT81uV5A@mail.gmail.com","threadId":"34680","inReplyTo":"520B486D.1040602@gmail.com","subject":"Re: ephemeral-branches instead of detached-head?","fromName":"Andres Perera","fromEmail":"andres.p@zoho.com","sentAt":"2013-08-14T16:40:49Z","receivedAt":"2013-08-14T16:40:49Z","isPatch":false,"sender":{"key":"andres.p@zoho.com","avatar":null},"body":"On Wed, Aug 14, 2013 at 4:35 AM, Sitaram Chamarty wrote:\n> On 08/14/2013 12:40 PM, Andres Perera wrote:\n>> On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty wrote:\n>>> On 08/14/2013 07:14 AM, Junio C Hamano wrote:\n>>>> Sitaram Chamarty writes:\n>>>>\n>>>>> # all reflog entries that are not on a branch, tag, or remote\n>>>>> d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes\n>>>>> # all dangling commits not on a branch, tag, or remote\n>>>>> d2 = !gitk --date-order $(git fsck | grep \"dangling.commit\" | cut -f3 -d' ') --not --branches --tags --remotes\n>>>>>\n>>>>> (Apologies if something like this was already said; I was not following\n>>>>> the discussion closely enough to notice)\n>>>>\n>>>> Yup.\n>>>>\n>>>> A potential problem is that the output from \"log -g --pretty=%H\" or\n>>>> \"fsck | grep dangling\" may turn out to be humongous. Other than\n>>>> that, they correctly compute what you want.\n>>>\n>>> I thought I mentioned that but I can't find my email now so maybe I\n>>> didn't.\n>>>\n>>> In practice though, I find that, bash at least seems happy to take\n>>> command lines as long as 7+ million characters long, so with the default\n>>> reflog expire times, that should work out to 10,000 commits *per day*.\n>>> [Tested with: echo {1000000..1900000} > junk; echo `cat junk` | wc]\n>>\n>> echo is a builtin in bash, as is the case with other shell implementations\n>>\n>> builtins may have different limit's than exec()'s ARG_MAX\n>>\n>> $ getconf ARG_MAX\n>> 262144\n>> $ perl -e 'print \"A\" x (262144 * 2)' | wc -c\n>> 524288\n>> $ perl -e 'print \"A\" x (262144 * 2)' | sh -c 'read v; echo \"$v\"' | wc -c\n>> 524289\n>> $ perl -e 'print \"A\" x (262144 * 2)' | sh -c 'read v; /bin/echo \"$v\"' | wc -c\n>> sh: /bin/echo: Argument list too long\n>> 0\n>>\n>> builtin's argument buffer limit tends to be aligned with the\n>> implementation's lexer buffer limit\n>\n> Aah; good catch -- I did not know this. Thanks!\n>\n> My systems show 2621440 on CentOS 6 and 2097152 on Fedora 19, so --\n> dividing by 8 (abbrev SHA + space) then by 90, that's still 2900 commits\n> *per day* to run past this limit though!\n\nARG_MAX may also include the process environment, which needs to be\ncopied over to the new vm\n\nthe limit may also include the argv pointer sizes\n\nthose calculations based on SHA string length are just approximates\n\n>\n> (side note: making a single argument that long seems to have a much\n> lower limit than having multiple arguments:\n>\n> $ /bin/echo `perl -e 'print \"A\" x (1000000)'` | wc\n> -bash: /bin/echo: Argument list too long\n> 0 0 0\n> $ /bin/echo `perl -e 'print \"A \" x (1000000)'` | wc\n> 1 1000000 2000000\n>\n> notice that the second one is twice as long in terms of bytes, but it's\n> not a single argument).\n\nthe behaviour is different in OpenBSD-amd64:\n\nperl -e 'print \"A \" x ((262144/2)-5)' | env -i sh -c 'unset PATH; read\nv; /bin/echo $v' | wc -c\n\na bigger size and i get E2BIG. if i pass the env or let PATH get\nexported, again, i need to reduce the multiplier\n\napparently Linux is doing copyin() for each argument. that seems\nexcessive to me :)\n"}]}