summaryrefslogtreecommitdiff
path: root/http-fetch.c
diff options
context:
space:
mode:
authorJunio C Hamano <junkio@cox.net>2007-01-01 23:31:08 -0800
committerJunio C Hamano <junkio@cox.net>2007-01-08 03:02:11 -0800
commitc847f537125ceab3425205721fdaaa834e6d8a83 (patch)
treeff9d242fe9d7bd4008f16d7f43e860e0db861981 /http-fetch.c
parent0016a48251abefed11efc919703d980a21c95f2c (diff)
downloadgit-c847f537125ceab3425205721fdaaa834e6d8a83.tar.gz
Detached HEAD (experimental)
This allows "git checkout v1.4.3" to dissociate the HEAD of repository from any branch. After this point, "git branch" starts reporting that you are not on any branch. You can go back to an existing branch by saying "git checkout master", for example. This is still experimental. While I think it makes sense to allow commits on top of detached HEAD, it is rather dangerous unless you are careful in the current form. Next "git checkout master" will obviously lose what you have done, so we might want to require "git checkout -f" out of a detached HEAD if we find that the HEAD commit is not an ancestor of any other branches. There is no such safety valve implemented right now. On the other hand, the reason the user did not start the ad-hoc work on a new branch with "git checkout -b" was probably because the work was of a throw-away nature, so the convenience of not having that safety valve might be even better. The user, after accumulating some commits on top of a detached HEAD, can always create a new branch with "git checkout -b" not to lose useful work done while the HEAD was detached. We'll see. Signed-off-by: Junio C Hamano <junkio@cox.net>
Diffstat (limited to 'http-fetch.c')
0 files changed, 0 insertions, 0 deletions