On Wed, 16 Oct 2013 13:56:10 -0400
[email protected] (Dale R. Worley) wrote:
[...]
> If you checked out commit C1, and then made a new commit, Git has no
> idea which branch you'd like to update. Now I just checked, and you
> *can* create a new commit, but no branch points to it, so you'll have
> a hard time finding it later. Indeed, if you move the working copy to
> some branch, there will be no references pointing to the new commit,
> and it will eventually be garbage collected.
Well, not just bad: in a regular repository, when you move off a
detached HEAD, two things happen:
* (Recent versions of) Git prints a big bold explanatory warning
mentioning the commit you've just left [1].
So it's copy-and-pastable.
* The abandoned HEAD's commit is saved to the reflog and it's
immediately available as HEAD@{1}, so, when you're in a detached
HEAD state, you could do
$ git checkout some_branch
$ git branch recent HEAD@{1}
...to first move away of the "now-lost" line of commits and then
create a branch named "recent" to point to it.
Of course, the reflog entries expire with time but the default
expiration period is very long.
What I intended to highlight is that that detached HEAD state is not
some weird oh-noes-please-get-me-out-of-here state but rather a normal
way to work for some mindsets/workflows. Once the Git's branching
model is understood well (the OP seems to have a common
misunderstanding that HEAD is "the head of a branch" rather than a
self-standing reference), the detached HEAD feels rather natural.
P.S.
In fact, the whole thread [2] is an interesting read.
1. http://article.gmane.org/gmane.comp.version-control.git/232197
2. http://thread.gmane.org/gmane.comp.version-control.git/232163
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
