Re: ephemeral-branches instead of detached-head?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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?


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@xxxxxxxxx> wrote:
> As Jonathan mentioned, your local branch namespace _is_ ephemeral in
> the larger picture, and you can and should use your regular branches
> as such.

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.

> (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.

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.

> 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.

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.

> ...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.

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.
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]