On Mon, 01 Jan 2007 23:45:08 -0800, Junio C Hamano wrote: > This allows "git checkout -d v1.4.3" to detach the HEAD from any > branch but point directly at the named commit. Being able to perform "checkout" with a tag like this, (and no specific branch), is something I've been wanting git to acquire for some time. So, thanks for coding this up! > 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 and know what you are doing. This part I don't understand. I don't see why it's useful to introduce new danger to "git checkout" in that after this change it could cause commits to become dangling. Currently, "git checkout" is entirely safe, as are most git commands. The few commands that create dangling commits require fairly explicit actions from the user, (such as "--hard" for git-reset or -D instead of -d for git-branch). So I'd vote against this aspect. I'd rather see commits to a detached head be disallowed with a message instructing the user to do "git checkout -b new-branch" in order to do the commit. And with that new safer behavior, I think it would be a good idea to just drop the "-d" option from git-checkout. I want this new behavior not for people who know what they are doing, but people who are using git only incidentally, (say they just want to acquire and build the latest version of some software). So I'd like the sequence to work along the lines of your earlier post, (as quoted by another reply). Specifically, I wouldn't want to see any warning about a "missing branch" until a commit was attempted. This would allow a sequence like this to proceed without git ever telling the user they were doing something "wrong": $ git clone git://git.kernel.org/pub/scm/git/git.git $ cd git $ git checkout v1.4.3 $ make With the recent improvements to the git-checkout error message (thanks!) this sequence is at least successful eventually after the user reads and responds to the following: git checkout: provided reference cannot be checked out directly You need -b to associate a new branch with the wanted checkout. Example: git checkout -b <new_branch_name> v1.4.3 But the user is required to invent a name and deal with its existence later. For example, after some time, imagine the same user wanting to update to the latest and build again: git pull origin git checkout v1.5.0 Now the user has to invent _another_ unique branch name, (or learn "git branch -d" or "git reset --hard" or ...), while this branch concept and these other commands aren't actually helping the user with the task at hand, (just tracking the code and building the most recent version). Similarly, I think this use case of "just tracking" should support branches disappearing from the remote repository without the user having to edit any config file. If there are entries that are automatically added by git-clone that should be removed later, that should happen automatically. A recent thread suggested adding an error message instructing the user to delete the entries. That's again unkind to a user who doesn't really want to learn git, but just wants to get at the most recent version of some code that happens to be available through git. That disappearing branches cause problems requiring manual cleanup of configuration files is one of the reasons that we are not using any feature branches in the "central" cairo repository, for example, (we do have branches for release maintenance). I'd really like to be able to put some feature branches there for shared work, (rather than forcing that work out to separate personal repositories as we do know). Maybe the configuration file entries added by git-clone need to be marked in some way to distinguish them from manually added entries, so that we would feel more comfortable automatically removing them when a remote branch has disappeared. -Carl
Attachment:
pgp7SD3ocSf8W.pgp
Description: PGP signature