From: Jonathan Watt <jwatt@jwatt.org>
To: Johan Herland <johan@herland.net>
Cc: git@vger.kernel.org,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Elijah Newren <newren@gmail.com>
Subject: Re: Working copy revision and push pain
Date: Sun, 23 Mar 2008 18:24:14 +0100 [thread overview]
Message-ID: <47E6923E.1050904@jwatt.org> (raw)
In-Reply-To: <200803231720.44320.johan@herland.net>
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...
next prev parent reply other threads:[~2008-03-23 17:25 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-23 12:39 Working copy revision and push pain Jonathan Watt
2008-03-23 13:02 ` Johannes Schindelin
2008-03-23 13:19 ` Jonathan Watt
2008-03-23 13:45 ` Elijah Newren
2008-03-23 13:54 ` Jonathan Watt
2008-03-23 14:06 ` Elijah Newren
2008-03-23 14:22 ` Johannes Schindelin
2008-03-23 14:48 ` Jonathan Watt
2008-03-23 14:56 ` Johannes Schindelin
2008-03-23 15:25 ` Jonathan Watt
2008-03-23 16:00 ` Johannes Schindelin
2008-03-25 19:25 ` Auto detaching head options (Re: Working copy revision and push pain) Jan Hudec
2008-03-25 19:58 ` Johannes Schindelin
2008-03-25 23:24 ` Jeff King
2008-03-26 18:49 ` Junio C Hamano
2008-03-29 8:27 ` Auto detaching head options (update) " Jan Hudec
2008-03-29 8:47 ` Jeff King
2008-03-31 1:53 ` Junio C Hamano
2008-03-31 1:59 ` Jeff King
2008-03-31 2:09 ` Jeff King
2008-03-23 19:48 ` Working copy revision and push pain Elijah Newren
2008-03-23 14:27 ` Jonathan Watt
2008-03-23 14:34 ` Johannes Schindelin
2008-03-23 16:20 ` Johan Herland
2008-03-23 17:24 ` Jonathan Watt [this message]
2008-03-23 18:21 ` Junio C Hamano
2008-03-23 19:42 ` Junio C Hamano
2008-03-23 18:23 ` Johannes Schindelin
2008-03-24 15:22 ` Johannes Schindelin
2008-03-24 18:00 ` Johan Herland
2008-03-23 14:11 ` Johannes Schindelin
2008-03-23 14:35 ` Jonathan Watt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47E6923E.1050904@jwatt.org \
--to=jwatt@jwatt.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=johan@herland.net \
--cc=newren@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).