From: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
To: "W. Trevor King" <wking@tremily.us>
Cc: Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>,
John Keeping <john@keeping.me.uk>, Andreas Krey <a.krey@gmx.de>,
John Szakmeister <john@szakmeister.net>
Subject: Re: [PATCH] pull: require choice between rebase/merge on non-fast-forward pull
Date: Fri, 28 Jun 2013 08:34:53 +0200 [thread overview]
Message-ID: <vpq1u7magky.fsf@anie.imag.fr> (raw)
In-Reply-To: <20130627201032.GF9999@odin.tremily.us> (W. Trevor King's message of "Thu, 27 Jun 2013 16:10:32 -0400")
"W. Trevor King" <wking@tremily.us> writes:
> On Thu, Jun 27, 2013 at 12:48:52PM -0700, Junio C Hamano wrote:
>> Because letting a trivial merge automatically handled by Git is so
>> easy with "git pull", a person who is new to Git may not realize
>> that the project s/he is interacting with may prefer "rebase"
>> workflow.
>
> Or they may not even realize that they've just merged an unrelated
> branch at all, dragging in a thousand unrelated commits which they
> accidentally push to a central repository without looking,
> contaminating future branches based on the central repostitory without
> drastic rebase surgery ;). I just saw one of these earlier this week.
I don't understand how the change would solve this. If "pull" would drag
a lot of commits in the current branch, the "rebase" will rebase the
current branch on a totally different history, and pushing the result
would be equally bad.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
next prev parent reply other threads:[~2013-06-28 6:35 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-22 11:50 first parent, commit graph layout, and pull merge direction Andreas Krey
2013-05-22 18:07 ` Junio C Hamano
2013-05-23 9:06 ` Andreas Krey
2013-05-23 9:48 ` John Szakmeister
2013-05-23 10:07 ` Jeremy Rosen
2013-05-23 10:29 ` Andreas Krey
2013-05-23 11:08 ` John Keeping
2013-05-23 16:01 ` Junio C Hamano
2013-05-23 16:41 ` John Keeping
2013-05-23 21:01 ` Junio C Hamano
2013-05-23 21:55 ` John Keeping
2013-05-23 21:59 ` Felipe Contreras
2013-05-23 22:11 ` Junio C Hamano
2013-05-23 22:46 ` Felipe Contreras
2013-05-23 22:54 ` Junio C Hamano
2013-05-23 23:09 ` Felipe Contreras
2013-05-23 23:26 ` Junio C Hamano
2013-05-23 23:53 ` Felipe Contreras
2013-05-24 8:29 ` John Keeping
2013-05-24 9:38 ` John Szakmeister
2013-05-24 0:03 ` Linus Torvalds
2013-05-24 0:21 ` Junio C Hamano
2013-05-24 0:24 ` Linus Torvalds
2013-05-24 0:25 ` Felipe Contreras
2013-05-24 0:32 ` Felipe Contreras
2013-05-24 16:26 ` Junio C Hamano
2013-05-24 20:47 ` Philip Oakley
2013-06-27 19:48 ` [PATCH] pull: require choice between rebase/merge on non-fast-forward pull Junio C Hamano
2013-06-27 20:10 ` W. Trevor King
2013-06-27 21:20 ` Junio C Hamano
2013-06-28 1:08 ` W. Trevor King
2013-06-28 6:34 ` Matthieu Moy [this message]
2013-06-28 9:09 ` W. Trevor King
2013-06-28 11:52 ` Matthieu Moy
2013-06-28 12:28 ` W. Trevor King
2013-06-27 20:11 ` Fredrik Gustafsson
2013-06-27 20:49 ` Junio C Hamano
2013-06-27 20:30 ` W. Trevor King
2013-06-27 20:58 ` Junio C Hamano
2013-06-27 22:16 ` Matthieu Moy
2013-06-28 1:19 ` W. Trevor King
2013-06-28 8:09 ` John Keeping
2013-06-28 17:22 ` Junio C Hamano
2013-06-28 17:42 ` John Keeping
2013-06-28 22:41 ` Junio C Hamano
2013-07-02 21:18 ` John Keeping
2013-07-14 15:03 ` [PATCH] fixup! " John Keeping
2013-07-15 4:23 ` Junio C Hamano
2013-08-28 23:22 ` [PATCH] " Felipe Contreras
2013-07-18 14:30 ` John Keeping
2013-07-18 17:38 ` Andreas Schwab
2013-07-18 18:00 ` Junio C Hamano
2013-07-18 19:35 ` [PATCH v2] " Junio C Hamano
2013-07-19 0:54 ` Eric Sunshine
2013-07-19 16:22 ` Junio C Hamano
2013-07-19 20:29 ` Eric Sunshine
2013-07-19 22:20 ` Junio C Hamano
2013-07-19 22:30 ` Eric Sunshine
2013-07-19 22:55 ` Junio C Hamano
2014-01-22 19:08 ` Flimm
2013-05-24 17:11 ` first parent, commit graph layout, and pull merge direction Andreas Krey
2013-05-24 19:23 ` Junio C Hamano
2013-05-23 19:25 ` Andreas Krey
2013-05-24 9:29 ` Holger Hellmuth (IKS)
2013-05-24 13:42 ` Andreas Krey
2013-05-24 15:05 ` Holger Hellmuth (IKS)
2013-05-24 17:24 ` Andreas Krey
2013-05-23 11:34 ` Felipe Contreras
2013-05-23 12:21 ` Andreas Krey
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=vpq1u7magky.fsf@anie.imag.fr \
--to=matthieu.moy@grenoble-inp.fr \
--cc=a.krey@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=john@keeping.me.uk \
--cc=john@szakmeister.net \
--cc=torvalds@linux-foundation.org \
--cc=wking@tremily.us \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.