Johan Herland wrote: > I'm starting to think it's worth changing the default behaviour of push as follows: > > Upon receiving a push into a non-bare repository, if the working copy is on the same branch as is being pushed, then refuse the push with a helpful message describing why the push was refused, and how to resolve this issue (i.e. referring to the tutorials you mention). > > This would: > - Not clobber the working copy > - Tell newbies what happened and why > - Hopefully make this issue pop up less frequently > - Not affect you if you only push into bare repos > - Not affect you if you take care to never push into a checked-out branch The detach-HEAD idea does all these things, but rather: - There's no need to tell newbies anything - It don't just reduce the frequency of the problem, it eliminates it :-) Also, - You eliminate the problem of git thinking the working copy came from a revision it didn't come from, and thus eliminate the "any commit will now overwrite the push" problem - You can still write hooks to update the working copy if you like - It's completely intuitive to anyone coming from Mercurial (and it's these people who are going to be doing the pushing into non-bare repositories, because that's the workflow they're familiar with) It might also be a good idea to print a warning about the working copy needing to be updated or else committing changes will create a branch. That seems obvious, and if you're pushing into a checked out branch, you probably know that though. > Of course, you should be able to set a config option to get the old behaviour, and from there you can write hooks to either update the working copy, or detach HEAD, or whatever you please. > > Is this acceptable to people? >From my perspective it makes things more complicated rather than simpler I'm afraid. Johannes is apparently fed up of trying to explain to me why people want their working copy associated with the wrong revision so that their commits will overwrite the pull. ;-) If anyone else cares to give it ago I'd appreciate it, since I still don't see the utility. Jonathan Hoping Johannes has a sense of humour... -- 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