Johannes Schindelin wrote:
quoted text
> Hi,
> 
> On Sun, 23 Mar 2008, Jonathan Watt wrote:
> 
>> Would detaching HEAD really be a problem in git workflows?
> 
> If recovering is painful?  Yes.
> 
> If it is not what you want?  Yes.

If you push to the current branch of a non-bare repository, then as things
stand, whatever was pushed to the current branch will be reverted on the next
commit(!). Push hasn't just pushed changesets to the repository, it's
essentially screwed up the working copy. I personally can't see how this
behavior is useful or in any way "right", or why you'd want it that way. On the
other hand detaching HEAD makes sure that all push has done is push changesets,
and you've essentially created a branch. To me that seems like the only correct
thing to do. (It also happens to be the way Mercurial behaves.)

I'd venture that if you're pushing into a non-bare repository then you know the
state of the working copy, and you know if you're going to cause pain. (And it's
probably local.) If it's a shared repository, why is there a working copy? If
it's someone else's repository, the two of you probably know what you're doing.
These two seem like relative edge cases though, and even then, detaching HEAD
seems like the right think to me.

quoted text
> Just to give you a small clue what other people would like: 
> http://utsl.gen.nz/git/post-update
> 
> BTW that was in the link I sent you earlier.

As I said, I don't want to update the files in the working copy. Seems like a
different issue to me.

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html