Why are commits on detached heads good, again?

* Why are commits on detached heads good, again?
@ 2007-02-07 14:26 linux
  2007-02-07 14:56 ` Nicolas Pitre
  2007-02-07 15:32 ` Johannes Schindelin
  0 siblings, 2 replies; 3+ messages in thread
From: linux @ 2007-02-07 14:26 UTC (permalink / raw)
  To: git; +Cc: linux

I know I made the case for the value of detached heads in a read-only
mode.  Why should I need to think up a branch name to look at v2.6.18?
I *have* a name; it's v2.6.18.

And it got implemented.  But some people said "Hey!  Let's allow
commits on top of detached heads, too!"  Whish has led to a huge thread
about handling the resultant potential confusion.

I agree 100% that it's entirely doable and can be used safely.

But perhaps the confusion is more trouble than it's worth?  If the rules
are hard to implement, is that perhaps a clue that they're hard for the
poor user to understand?

I'd like to agitate for forbidding commits on detached heads as a
simplicity issue.  If I'm going to ask git to *remember* some work for
me, is it terribly unreasonable for me to have to think of a name for it?
I can name it "temp" or "foo" or "test" or "hackhack" or "x" if I want.

Remember, we've survived fine up to now when you can't even *look* at an
old commit without coming up with a name for it (or using git-tar-tree,
or some other tool).  And the pressure to change hasn't been *that*
strong.

Even if it's slightly more stringent than required, why not say
"you're not allowed to commit when you're not on a branch; think
of a name for your work and do 'git checkout -b <name> first'"?

Is it that onerous?  It has the great virtue of being very simple
to explain and remember.  "If you committed without being on a branch,
you're not allowed to switch away until you give that branch a name,
or you accept losing the data" is a lot more complicated.
(Never mind the arguing about the reflog and ORIG_HEAD.)

People are used to the idea that if you want to save your work, you need
to think up a file name.  Postponing that time until you switch away
from the HEAD doesn't actually save any work unless you throw away the
commits, and presumably that's a rare and unusual situation.
(And the extra work is trivial compared to the effort writing
the commits you're discarding.)

Can someone explain why committing on top of a detached head is a
killer feature and thinking up a name sooner rather than later is
a huge inconvenience?

As someone trying to document all this, it would certainly make my
life easier to just forbid it.  I can just say:

git-checkout: You may check out any commit you like.
	However, if the name you specify is in the .git/refs/heads
	directory, you are "on that branch" and can commit to it.
	If you specify the same commit by a tag or raw SHA ID,
	and do not give a name with "git checkout -b <name>", you
	are not on any branch, and a later git-commit will fail.
git-commit: If the last thing you checked out with "git-checkout"
	(with no pathname arguments) was a branch (in .git/refs/heads),
	the commit is made and the head is automatically updated to
	point to the new head.
	If you have checked out a "bare commit", git-commit will refuse
	to make the commit because it has nowhere to record it.
	You can "git checkout -b <name>" to create a new branch
	starting from the current HEAD.  This will not alter the
	contents of the index or the working directory.

I'm willing to be convinced, but could someone please explain the
virtues of committing to a detached HEAD that outweigh the virtue
of simplicity?

^ permalink raw reply	[flat|nested] 3+ messages in thread