On Mon, 01 Jan 2007 23:45:08 -0800, Junio C Hamano wrote:
quoted text
> 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!

quoted text
> 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