git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Marc Branchaud <marcnarc@xiplink.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Pull is Mostly Evil
Date: Fri, 02 May 2014 13:06:06 -0700	[thread overview]
Message-ID: <xmqqtx989c9d.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <5363edc954f8e_70ef0f30c24@nysa.notmuch> (Felipe Contreras's message of "Fri, 02 May 2014 14:11:05 -0500")

Felipe Contreras <felipe.contreras@gmail.com> writes:

>> Stepping back even further, and thinking what is different between
>> these two pulls, we notice that the first one is pulling from the
>> place we push back to.  Perhaps a way to solve this issue, without
>> having to introduce a new 'git update' and updating the tutorials,
>> may be disallow fetch+merge by default only when pulling from the
>> place the result is going to be pushed back to?
>
> Which is basically essentially the same as not specifying anything, or
> rather, running `git pull` without arguments.

I cannot tell if you are agreeing or disagreeing, and with what.

Using the "special case 'git pull' without arguments" heuristics
would take us back to the old jc/pull-training-wheel patch

    http://thread.gmane.org/gmane.comp.version-control.git/225146/focus=230856

which we agreed to drop in

    http://thread.gmane.org/gmane.comp.version-control.git/233554/focus=234365

to favor the old series you did with pull.mode, and we rejected that
patch in $gmane/230856 for a sound reason, I would think.

"You are pulling from the place the result is going to be pushed
back to" is different from "'git pull' was run without arguments".
In the "pumpking" example in the message you are responding to:

    When he becomes in charge of producing a new 'maint' (in his
    original, he says 'maintenance-branch'), he first does this:

        $ git checkout maint
        $ git pull --ff-only [ origin maint ]

the heuristics would trigger the safety only when the optional
"origin maint" are not given, but we do have enough information
to see "git pull origin maint" (with where from and what to pull
explicitly specified on the command line) falls into the case where
the user needs protection, don't we?

Also, with the triangular push configuration, "git pull" without
argument will fetch from one place that is different from where the
current branch is going to pushed to, so that heuristics would not
work at all.

So...

  reply	other threads:[~2014-05-02 20:06 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-02 15:37 Pull is Mostly Evil Marc Branchaud
2014-05-02 15:45 ` David Kastrup
2014-05-02 16:05   ` Philip Oakley
2014-05-02 19:05     ` Felipe Contreras
2014-05-02 22:34       ` Philip Oakley
2014-05-02 22:53         ` Jonathan Nieder
2014-05-03 20:24           ` Philip Oakley
2014-05-02 23:23         ` Felipe Contreras
2014-05-03 11:24           ` Philip Oakley
2014-05-03 11:30             ` Felipe Contreras
2014-05-02 19:31   ` David Lang
2014-05-02 19:37     ` David Kastrup
2014-05-02 18:13 ` Junio C Hamano
2014-05-02 19:11   ` Felipe Contreras
2014-05-02 20:06     ` Junio C Hamano [this message]
2014-05-02 20:58       ` Felipe Contreras
2014-05-02 21:48     ` Jeff King
2014-05-02 21:55       ` Felipe Contreras
2014-05-02 22:36         ` Jeff King
2014-05-02 23:27           ` Felipe Contreras
2014-05-03  2:18       ` David Kastrup
2014-05-06 22:06       ` Junio C Hamano
2014-05-06 22:19         ` Felipe Contreras
2014-05-03  7:56   ` Richard Hansen
2014-05-03  8:17     ` David Kastrup
2014-05-03  9:04       ` Felipe Contreras
2014-05-03  9:56         ` David Kastrup
2014-05-04  4:30           ` David Lang
2014-05-04  4:38             ` Felipe Contreras
2014-05-04  6:13               ` David Kastrup
2014-05-04  6:50               ` James Denholm
2014-05-04  7:48                 ` David Kastrup
2014-05-04  9:51                 ` Felipe Contreras
2014-05-04 10:37                   ` James Denholm
2014-05-04 11:02                     ` David Kastrup
2014-05-03  9:26     ` Felipe Contreras
2014-05-03 22:09       ` Richard Hansen
2014-05-04  3:08         ` Felipe Contreras
2014-05-04  7:49           ` Richard Hansen
2014-05-04 10:17             ` Felipe Contreras
2014-05-04 19:09               ` Richard Hansen
2014-05-04 21:13                 ` Felipe Contreras
2014-05-05  5:44                   ` Richard Hansen
2014-05-05  5:47                     ` Felipe Contreras
2014-05-07 22:37     ` Max Kirillov
2014-05-03 10:00   ` John Szakmeister
2014-05-05 15:39     ` Richard Hansen
2014-05-05 18:15       ` Felipe Contreras
2014-05-02 22:12 ` Philip Oakley
2014-05-09 19:49 ` Marc Branchaud

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=xmqqtx989c9d.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=marcnarc@xiplink.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).