Johannes Schindelin wrote: > 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. > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
