David Jeske <dav...@gmail.com> 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

> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to