From: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
To: Junio C Hamano <gitster@pobox.com>
Cc: Matthieu Moy <Matthieu.Moy@imag.fr>,
Teemu Likonen <tlikonen@iki.fi>,
git@vger.kernel.org
Subject: [PATCH v2] Re: push: point to 'git pull' and 'git push --force' in case of non-fast forward
Date: Sun, 9 Aug 2009 00:23:33 +0200 [thread overview]
Message-ID: <20090808222333.GA12954@vidovic> (raw)
In-Reply-To: <7vy6pujmsc.fsf@alter.siamese.dyndns.org>
The 08/08/09, Junio C Hamano wrote:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> > Teemu Likonen <tlikonen@iki.fi> writes:
> >
> > Right, but I don't think this error message is the place to discuss
> > that. Anything involving rebasing should be taken with care, and
> > pointing the user to it in a short sentence sounds like "try shooting
> > yourself in the foot, and read the man page if it hurts" ;-).
>
> Instead of saying "Merge in", we could say "Integrate" to cover both
> practices. I also happen to think that the mention of --force falls into
> the same category as "try shooting and then study if it hurgs".
I'd say that everywhere we try to guess what the user should do (and
telling him to do so) falls into this category. Of course, some
operations are really destructive with no way to recover to a previous
state where some other operations aren't destructive at all. But Git can
be used in many various workflows and telling ― in an error/warning
message ― what the user should do may hurt some of the workflows and/or
finally confuse the beginners. Actually, I believe that a message with
only "See the /WONDERFULL/ section in the /LEARN_GIT/ man page" is the
best answer.
Also, I think that mentionning --force is the worst thing to do because
the beginner will immediatly run it without thinking of all the
consequences at all: "Oh, we could do that, let's try".
> So how about phrasing it like this?
>
> Non-fast forward pushes were rejected because you would discard remote
> changes you have not seen. Integrate them with your changes and then
> push again. See 'non-fast forward' section of 'git push --help'.
Well, a beginner may rewrite a commit whithout realize what he did. If he is
the only to work on the projet, this message is somewhat wrong.
What about
Non-fast forward pushes were rejected because you would discard remote
changes. See 'non-fast forward' section of 'git push --help'.
?
--
Nicolas Sebrecht
next prev parent reply other threads:[~2009-08-08 22:23 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-06 17:32 [PATCH] push: point to 'git pull' and 'git push --force' in case of non-fast forward Matthieu Moy
2009-08-06 20:04 ` Michael J Gruber
2009-08-07 19:21 ` Matthieu Moy
2009-08-07 19:46 ` Michael J Gruber
2009-08-06 20:15 ` Junio C Hamano
2009-08-06 21:16 ` [PATCH] " Nicolas Sebrecht
2009-08-06 21:32 ` Junio C Hamano
2009-08-07 19:37 ` [PATCH] " Matthieu Moy
2009-08-07 20:05 ` Junio C Hamano
2009-08-07 20:22 ` Matthieu Moy
2009-08-08 7:51 ` [PATCH v2] " Matthieu Moy
2009-08-08 8:35 ` Teemu Likonen
2009-08-08 15:22 ` Matthieu Moy
2009-08-08 16:25 ` Junio C Hamano
2009-08-08 22:23 ` Nicolas Sebrecht [this message]
2009-08-09 18:35 ` Matthieu Moy
2009-08-09 20:22 ` Junio C Hamano
2009-08-10 8:43 ` Matthieu Moy
2009-08-10 8:49 ` Junio C Hamano
2009-08-10 8:56 ` Matthieu Moy
2009-08-11 3:03 ` Nanako Shiraishi
2009-09-06 6:44 ` [RFC/PATCH 0/4] make helpful messages optional Jeff King
2009-09-06 6:46 ` [PATCH 1/4] push: fix english in non-fast-forward message Jeff King
2009-09-06 6:47 ` [PATCH 2/4] push: re-flow " Jeff King
2009-09-06 6:48 ` [PATCH 3/4] push: make non-fast-forward help message configurable Jeff King
2009-09-06 7:09 ` Junio C Hamano
2009-09-06 7:23 ` Jeff King
2009-09-06 7:30 ` Junio C Hamano
2009-09-06 7:32 ` Jeff King
2009-09-06 7:52 ` Junio C Hamano
2009-09-06 11:30 ` Sverre Rabbelier
2009-09-07 0:44 ` Nanako Shiraishi
2009-09-07 7:35 ` Johannes Sixt
2009-09-07 7:40 ` Mike Hommey
2009-09-07 8:24 ` Jeff King
2009-09-07 8:34 ` Matthieu Moy
2009-09-07 8:54 ` Jeff King
2009-09-07 11:20 ` Matthieu Moy
2009-09-08 18:51 ` Uri Okrent
2009-09-09 11:22 ` Jeff King
2009-09-09 11:26 ` [PATCH 0/2] configurable advice messages Jeff King
2009-09-09 11:38 ` [PATCH 1/2] push: make non-fast-forward help message configurable Jeff King
2009-09-09 19:06 ` Junio C Hamano
2009-09-09 20:39 ` Jeff King
2009-09-09 21:47 ` Junio C Hamano
2009-09-09 11:43 ` [PATCH 2/2] status: make "how to stage" messages optional Jeff King
2009-09-06 6:50 ` [PATCH 4/4] " Jeff King
2009-09-06 11:53 ` [RFC/PATCH 0/4] make helpful " Matthieu Moy
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=20090808222333.GA12954@vidovic \
--to=nicolas.s.dev@gmx.fr \
--cc=Matthieu.Moy@imag.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=tlikonen@iki.fi \
/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).