ephemeral-branches instead of detached-head?

Has there ever been any any discussion of creating an ephemeral-branch name mechanism, instead of using detached HEADs?

By ephemeral, I mean that a branch-name could be created which would live only so long as it is the only named way to reach a ref or the ref is in the working directory. Ephemeral branch names would be local-only and would never be pushed.

For example, if one performed "git checkout 2c29d...", one would not get a detached head-state, but instead would get an ephemeral branch name similar to "etmp/2c29d...". If no changes were checked into this ephemeral branch, it would disappear as soon as it was no longer in the working directory. If any changes were checked in on this branch, it would survive until (a) the ref is given a non-ephemeral branch name, (b) the changes are merged, (c) the ephemeral branch is deleted/discarded.

I'm asking about (and proposing) this mechanism, because it would prevent refs from ever being "accidentally lost", such as occurs in the following scenerios..

1) forgetting to branch a detached head before checkin
2) forgetting a head is detached before moving away from it
3) forgetting about checkins before a submodule update

Also, these "etmp/####" branches would serve as an obvious visible reminder in the branch list that a change was checked in that should either be merged, named, or discarded.

David Jeske wrote:

That's how normal branch names behave (local branch names and remote branch names live in different namespaces). How would the proposed detached HEAD replacement compare to them? 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 point later?

Curious, Jonathan

David Jeske <davidj@gmail.com> writes:

As Jonathan mentioned, your local branch namespace _is_ ephemeral in the larger picture, and you can and should use your regular branches as such.

I do not think any of the above will be helped by truly epheral branch that are not consciously named by the end user.

(1) is not a problem at all by itself with detached HEAD. You can commit all you want, and the true problem people perceive that comes from (1) is (2), as they think they would lose commit that way. But the thing is, the commits are not lost---they are recoverable from the reflog of the HEAD itself. 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 the reflog of the HEAD, so you didn't solve any problem here.

I am not sure what you are trying to improve with (3) but I suspect it is just the same issue between (1) and (2) in the submodule working tree. After running a submodule update in the superproject, you will get into the detached HEAD state in the submodule, and that state by itself is not a problem at all, but after committing and then switching to other branch (or to another commit), the history leading to the tip commit will not be at the tip of any meaningfully named branch. That is different from a commit getting lost, and I do not see how ephemerally created branches with random names would help people discover these commits better compared to reflog for the HEAD.

Yes, as I stated in my example, the ephemeral branch created from checking out a random commit would be automatically deleted anytime there was another downstream name for the ref (and the ref was no longer in the working-directory). Another way to think of the proposal is to allowed detached-HEADs, but automatically create ephemeral branch-names when checking into a detached head.

On Mon, Aug 12, 2013 at 12:55 AM, Junio C Hamano <gitster@pobox.com> wrote:

This is not the case. To me "ephemeral" means that the branch name automatically disappears if nothing gets checked into it. The local branch names definitely do not operate this way.

It is not a matter of a commit being destroyed, as I know they are not destroyed, it is a matter of "losing" as in it being a pain-in-the-a-s-s to find the darn thing.

The reflog is only really useful for a short time. If you don't notice until later, it's too late for this to be a reasonable way to find the missing commit.. and this assumes you noticed at all.

For as long as I've used git, I simplu don't understand why I should be able to commit something, and have it go "missing" in the branch namespace without an explicit action on my part.

This is simply not true.

The reflog is filled with every reflog action. Any checkout, push, pull, existing commits, etc. The ephemeral space would *only* contain dangling refs that were not named, merged, or discarded.

Is there currently any way to say "hey, git, show me what commits are dangling that might be lost in the reflog?"

I'm not aware of one. This is the difference. It's making the action of throwing away a dangling ref more explicit.

@Junio - to put the issue in the context of your previous comments on the topic... way back when you made a comment about warnings during commits to detached heads..

http://git.661346.n2.nabble.com/RFC-Detached-HEAD-reminder-on-commit-td834710.html#a834959

The reason this rationale doesn't ring true for me, is that it is *very* common for me to checkout a detached-head and there is nothing odd or dangerous about it. I do this when using checkout to move around the history to inspect, build, and test different revisions. As a result, it's very easy to just start ignoring this (usually meaningless) message.

The dangerous situation only occurs when something is committed onto a detached-head, and at this point there is no warning. The "# Not currently on any branch" message that appears during "git status" easily blends in with boilerplate text there.

IMO, the current warning during checkout of a detached-head is misplaced. It should be removed, and instead there should only be a warning after detached-head commit, since this is the only time there is a danger of losing something.

With my proposed "ephemeral branch" concept, there is no warning necessary in either case, since any check-ins left dangling would get names in the branch space you could see and take a look at. If that dangling head was temporary and was named or rebased, the ephemeral branch name would disappear automatically, leaving the expert-user with no warnings and no annoyance, while the novice user with a simple tool to help them not lose track of changes they made.

On Mon, Aug 12, 2013 at 7:14 PM, David Jeske <davidj@gmail.com> wrote:

That would annoy me as I often work on top of detached HEAD on purpose and only create a branch when I want to save something. If the warning is to be moved, it should warn at the next checkout.

Duy Nguyen <pclouds@gmail.com> writes:

$ git checkout master
Warning: you are leaving 1 commit behind, not connected to
any of your branches:

  0e3618e a

Switched to branch 'master'

Andreas.

Duy Nguyen <pclouds@gmail.com> writes:

Don't we already do that?

    Warning: you are leaving N commits behind, not connected to
    any of your branches:

        ... list of commits to be lost ...

    If you want to keep them by creating a new branch, this may be a
    good time
    to do so with:

     git branch new_branch_name xxxxxx

    Switched to branch 'master'

On Mon, Aug 12, 2013 at 10:24 AM, Junio C Hamano <gitster@pobox.com> wrote:

This only shows on checkout... not reset, not submodule-update, nor any other ways you can clobber a detached head.

On Mon, Aug 12, 2013 at 6:23 AM, Duy Nguyen <pclouds@gmail.com> wrote:

Yes, you're absolutely right ...

My point about the current checkout warning is that it's crying wolf, and nullifying the value of the warning. Most of the time I checkout a ref, I'm not doing anything dangerous because I'm not going to check anything in. The warning would be more effective if it warns in as narrow a situation as possible. You're correct that the clobber is even more narrow than the checkin.

The warning on clobber would be similar to (but shorter than) the one which could be removed from checkout..

Clobbered detached HEAD 'cce40d6'!

   git log cce40d6 ^master      # log detached changes vs master
   git branch <name> cc340d6    # name the changes with a branch

Personally, I'd prefer for explicit action to discard a detached head. It's true that this is an explicit step, but for me it generally takes a heck of alot less time to explicitly discard than it did to checkout the detached head, make changes (or apply a patch), and then decide to throw them away.

My "ephemeral branch" idea was a way to make this explicit discard as passive and lazy as possible. Basically, never stop you from doing your work, assume you know what you are doing. If the user names-the-branch it disappears. If the user merges or rebases the detached head, it disappears. The only time the "ephemeral branch" would survive is if the user really clobbered a detached head and then didn't do anything about it. Even if they missed the warning (in the middle of a script or automated process), eventually they would see the ephemeral branch lying around.

Clobbering a detached head with "ephemeral branches" could show no warning at all, or a warning like:

Clobbered detached HEAD.

   git log cce40d6 ^master           # log detached changes vs master
   git branch -D tmp/cce40d6         # Discard these changes
   git branch tmp/cce40d6 <newname>  # name this branch

David Jeske <davidj@gmail.com> writes:

You do not have to say that to me _now_ ;-) because after makinng the above ancient comment others have corrected me, I agreed with them, and we no longer rely on that "you are detaching, danger ahead" warning.

With the same line of reasoning, the place where users make commits on detached HEAD is not where the danger arises, either; the real danger is where you switch out of the detached HEAD state, and I think we do give a loud warning there.

On Mon, Aug 12, 2013 at 3:37 PM, David Jeske <davidj@gmail.com> wrote:

How do you define dangling commits? When you do "git commit --amend", the current commit will become dangling (in the sense that it's not referred by any ref, but the commit exists) and those are just noise in my opinion.

Duy Nguyen <pclouds@gmail.com> writes:

"fsck lost-and-found" would be one way. It would be nice if we had something like (note: the following will _NOT_ work)

	git log -g HEAD --not --branches

to say "walk the reflog of HEAD, but exclude anything that can be reached from the tips of branches".

On 08/13/2013 10:19 PM, Junio C Hamano wrote:

I've been using the following 3 aliases for some time now, to find various dangling stuff. The middle one (d1) seems to do approximately what you want, but will probably fail on repos with lots of activity when the command line length limit is (b)reached.

    # all stashed entries (since they don't chain)
    sk = !gitk --date-order $(git stash list | cut -d: -f1) --not --branches --tags --remotes
    # all reflog entries that are not on a branch, tag, or remote
    d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes
    # all dangling commits not on a branch, tag, or remote
    d2 = !gitk --date-order $(git fsck | grep "dangling.commit" | cut -f3 -d' ') --not --branches --tags --remotes

(Apologies if something like this was already said; I was not following the discussion closely enough to notice)

Sitaram Chamarty <sitaramc@gmail.com> writes:

Yup.

A potential problem is that the output from "log -g --pretty=%H" or "fsck | grep dangling" may turn out to be humongous. Other than that, they correctly compute what you want.

On 08/14/2013 07:14 AM, Junio C Hamano wrote:

I thought I mentioned that but I can't find my email now so maybe I didn't.

In practice though, I find that, bash at least seems happy to take command lines as long as 7+ million characters long, so with the default reflog expire times, that should work out to 10,000 commits *per day*. [Tested with: echo {1000000..1900000} > junk; echo `cat junk` | wc]

Incidentally, am I the only one who thinks the default values for gc.reflogexpire (90 days) and gc.reflogexpireunreachable (30) should be reversed?

In terms of recovering potentially lost commits at least, it seems it would make more sense that something that is UNreachable have a longer expiry, whereas stuff that's reachable... that's only a quick "gitk" browse away.

Design question: is the primary purpose of the reflog "what was I doing X days ago" or is it "I need some code from a commit that got rebased out [or whatever] X days ago"?

I have always only used the reflog for the latter.

On Wed, Aug 14, 2013 at 12:02:24PM +0530, Sitaram Chamarty wrote:

You can also do:

  git log -g --pretty=%H |
  git log --stdin --not --branches --tags --remotes

to avoid any argv limitations.

-Peff

On Wed, Aug 14, 2013 at 2:02 AM, Sitaram Chamarty <sitaramc@gmail.com> wrote:

echo is a builtin in bash, as is the case with other shell implementations

builtins may have different limit's than exec()'s ARG_MAX

$ getconf ARG_MAX
262144
$ perl -e 'print "A" x (262144 * 2)' | wc -c
  524288
$ perl -e 'print "A" x (262144 * 2)' | sh -c 'read v; echo "$v"' | wc -c
  524289
$ perl -e 'print "A" x (262144 * 2)' | sh -c 'read v; /bin/echo "$v"' | wc -c
sh: /bin/echo: Argument list too long
       0

builtin's argument buffer limit tends to be aligned with the implementation's lexer buffer limit

On 08/14/2013 12:40 PM, Andres Perera wrote:

Aah; good catch -- I did not know this.  Thanks!

My systems show 2621440 on CentOS 6 and 2097152 on Fedora 19, so -- dividing by 8 (abbrev SHA + space) then by 90, that's still 2900 commits *per day* to run past this limit though!

(side note: making a single argument that long seems to have a much lower limit than having multiple arguments:

    $ /bin/echo `perl -e 'print "A" x (1000000)'` | wc
    -bash: /bin/echo: Argument list too long
          0       0       0
    $ /bin/echo `perl -e 'print "A " x (1000000)'` | wc
          1 1000000 2000000

notice that the second one is twice as long in terms of bytes, but it's not a single argument).

On Wed, Aug 14, 2013 at 4:35 AM, Sitaram Chamarty <sitaramc@gmail.com> wrote:

ARG_MAX may also include the process environment, which needs to be copied over to the new vm

the limit may also include the argv pointer sizes

those calculations based on SHA string length are just approximates

the behaviour is different in OpenBSD-amd64:

perl -e 'print "A " x ((262144/2)-5)' | env -i sh -c 'unset PATH; read v; /bin/echo $v' | wc -c

a bigger size and i get E2BIG. if i pass the env or let PATH get exported, again, i need to reduce the multiplier

apparently Linux is doing copyin() for each argument. that seems excessive to me :)

On Tue, Aug 13, 2013 at 9:44 PM, David Jeske <davidj@gmail.com> wrote:

So basically everything that is (1) produced by "git commit", (2) not connected to any ref and (3) not an amend. I think (1) and (3) can be achieved with "git log -g --grep-reflog commit: HEAD". We only need to filter out ones that are connected to some ref. Not sure if that can be done with script though. Maybe add "--dangling" to "git log -g" to do such filtering?

On Aug 12, 2013 11:06 PM, "Duy Nguyen" <pclouds@gmail.com> wrote:

Any commit which I did not explicitly do something with. (Merge, rebase, amend, branch name, discard)

Today every one of those actions is explicit except discard.

This is *exactly* my point.

There is no way to distinguish a commit which was accidentally and implicitly dangled due to checkout or submodule update on a detached head, from all those other intentionally dangling refs which were explicitly handled with merge, rebase, amend.

Ephemeral branches would change only the implicit discard.. Turning it into a named branch and requiring an explicit discard.

David Jeske <davidj@gmail.com> writes:

I do not follow. Just like "commit --amend", checking out another branch to leave a detached HEAD _is_ an explicit way to discard what you started experimenting behind, declaring it useless. Otherwise you would have saved it to some named branch.

This of course assumes that, as you said in one of your earlier messages, the user knows what he is doing, though.

Junio C Hamano <gitster@pobox.com> writes:

By the way, by the above I do not mean "checking out a named branch should not be protected". I am saying "treating commits lost by running 'commit --amend' differently does not make sense to me".