Re: Working copy revision and push pain

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux