David Jeske <davidj@xxxxxxxxx> writes: > 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 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. > 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html