git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* A failing attempt to use Git in a centralized environment
@ 2014-04-28  6:29 Marat Radchenko
  2014-04-28 18:41 ` Junio C Hamano
                   ` (3 more replies)
  0 siblings, 4 replies; 73+ messages in thread
From: Marat Radchenko @ 2014-04-28  6:29 UTC (permalink / raw)
  To: git

Setup:
20 people (programmers, artists, designers) with prior SVN knowledge and a desire to use Git for a new project (mostly on programmers side). Non-programmers used TortoiseSVN before so choosing TortoiseGit as a GUI was an obvios step.

We made an in-house presentation introducing basic Git concepts and how it is different from SVN. Also, individual training was done for each person who didn't have Git experience. During this training, they tried everyday tasks of updating, committing, pushing changes and viewing history on a toy repository. 

Problem #1: TortoiseGit GUI windows for common tasks have a heck lots of controls that a common Git user will never need. Just look at a monstrosity of its push dialog [1]. This was kinda fixed by training users to use Git Sync dialog [2].

"Autoload PuTTY key"? What the hell is this? Why I can switch it on/off in Git Push but it is disabled in Git Sync? What is PuTTY doing here at all, I'm using OpenSSH.

Problem #2 occured the first day we started using Git on real project. It is explained in detail in older post to Git ML [3]. I call it "swapped/reverse merge problem".

In short:
1. Hack, hack, hack
2. Commit
3. Push, woops, reject (non-ff)
4. Pull
5. Push

The root of evil is step #4 that creates a merge commit with "swapped" parents - local commits become first parent, remote commits become second. If one would want to make proper parent order, he would have to:
1. git fetch
2. git checkout origin/master -b tmp
3. git merge master
4. git push
5. git checkout master
6. git merge origin/master
7. git branch -d tmp

And all this branch dance produces exactly the same commit (content-wise) as simple "pull, push" sequence with the only difference in parent order. And things become even worse if comeone pushes more commits to remote repo while you perform this dance.

We can't expect all developers (especially, designers and artist) to do it. They don't want to use branches and just work on mainline. This is especially important on early development stages when new features (that designers' work depends upon) are added every day.

Additionally, many git-related tools depend on first-parent convention and show wrong graphs/diffs.

Problem #3: on conflicts, user ends up with a working copy that marks all remote-changed files as modified. Luckily, nobody has problems with conflict resolution process, it's just confusing to see changes other way round.

Okay, then, let's try rebase workflow. "git config pull.rebase true" and go.

Problem #4: when conflict happens during rebase, mergetool shows user own changes as "theirs" and remote changes as "mine". And believe me, explaining this to users doesn't increase their willingness to adopt Git.

Problem #5 (TortoiseGit-related): for some dumb reason, TortoiseGit's rebase is not a git rebase! Worse, TortoiseGit doesn't have any button to say 'git rebase --continue". So we had to cancel "pull.rebase=true" approach and teach users to use "Fetch&Rebase" button. It would be usable if only TortoiseGit didn't show rebase dialog even when everything was already up-to-date. And even git-aware developers don't understand the idea behind "Force rebase" checkbox in rebase dialog and why anyone would ever want to have it disabled (and it is disabled by default).

Problem #6: push - reject - pull - push sequence sometimes transforms into a loop with several iterations and doesn't add happiness.

So... Any suggestions how to make life easier are welcome.

[1] http://tortoisegit.googlecode.com/git/doc/images/en/GitPush.png
[2] http://tortoisegit.googlecode.com/git/doc/images/en/GitSync.png
[3] http://git.661346.n2.nabble.com/first-parent-commit-graph-layout-and-pull-merge-direction-td7586671.html

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: A failing attempt to use Git in a centralized environment
  2014-04-28  6:29 A failing attempt to use Git in a centralized environment Marat Radchenko
@ 2014-04-28 18:41 ` Junio C Hamano
  2014-04-30 14:21   ` Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment) Marc Branchaud
  2014-04-30 16:12 ` A failing attempt to use Git in a centralized environment Stepan Kasal
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 73+ messages in thread
From: Junio C Hamano @ 2014-04-28 18:41 UTC (permalink / raw)
  To: Marat Radchenko; +Cc: git

Marat Radchenko <marat@slonopotamus.org> writes:

> Problem #1: TortoiseGit GUI windows for common tasks have a heck
> lots of controls that a common Git user will never need.

Do people around TortoiseGit lurk on this list?  Otherwise this may
not be something we can help you with here.

> Problem #2 occured the first day we started using Git on real
> project. It is explained in detail in older post to Git ML [3]. I
> call it "swapped/reverse merge problem".
>
> In short:
> 1. Hack, hack, hack
> 2. Commit
> 3. Push, woops, reject (non-ff)
> 4. Pull
> 5. Push
>
> The root of evil is step #4 that creates a merge commit with
> "swapped" parents.

Yes, this is a real issue, and I do not mind seeing a patch to
improve the situation (there may be different approaches, and one
random approach somebody takes may not necessarily be a good way to
improve the situation though).

 - Perhaps by allowing an option to tell the "pull" at the fourth
   step to record swapped parents in the merge?

 - Perhaps in step #3, stop suggesting to "pull first" and instead
   tell them to "fetch upstream, rebase your work on it and then
   push"?

 - Extending on the second one, wrap a large part of the procedure
   in a single handy wrapper "git update" or something, whose point
   is to "update your work to be mergeable and pushable"?

> Problem #3: on conflicts, user ends up with a working copy that
> marks all remote-changed files as modified. Luckily, nobody has
> problems with conflict resolution process, it's just confusing to
> see changes other way round.

If we flip the resolution process to "apply/merge your work to the
updated upstream (i.e. the topic of your problem #2 above)", that
"other way round" issue will disappear, no?
>
> Problem #4: when conflict happens during rebase, mergetool shows
> user own changes as "theirs" and remote changes as "mine". And
> believe me, explaining this to users doesn't increase their
> willingness to adopt Git.

Likewise.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)
  2014-04-28 18:41 ` Junio C Hamano
@ 2014-04-30 14:21   ` Marc Branchaud
  2014-04-30 14:55     ` Junio C Hamano
  2014-04-30 16:47     ` Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment) Felipe Contreras
  0 siblings, 2 replies; 73+ messages in thread
From: Marc Branchaud @ 2014-04-30 14:21 UTC (permalink / raw)
  To: Junio C Hamano, Marat Radchenko; +Cc: git

On 14-04-28 02:41 PM, Junio C Hamano wrote:
> Marat Radchenko <marat@slonopotamus.org> writes:
> 
>> Problem #1: TortoiseGit GUI windows for common tasks have a heck
>> lots of controls that a common Git user will never need.
> 
> Do people around TortoiseGit lurk on this list?  Otherwise this may
> not be something we can help you with here.
> 
>> Problem #2 occured the first day we started using Git on real
>> project. It is explained in detail in older post to Git ML [3]. I
>> call it "swapped/reverse merge problem".
>>
>> In short:
>> 1. Hack, hack, hack
>> 2. Commit
>> 3. Push, woops, reject (non-ff)
>> 4. Pull
>> 5. Push
>>
>> The root of evil is step #4 that creates a merge commit with
>> "swapped" parents.
> 
> Yes, this is a real issue, and I do not mind seeing a patch to
> improve the situation (there may be different approaches, and one
> random approach somebody takes may not necessarily be a good way to
> improve the situation though).
> 
>  - Perhaps by allowing an option to tell the "pull" at the fourth
>    step to record swapped parents in the merge?
> 
>  - Perhaps in step #3, stop suggesting to "pull first" and instead
>    tell them to "fetch upstream, rebase your work on it and then
>    push"?

This approach would be my preference.

But I'm definitely biased because I think pull is pretty much broken:

* New users are encouraged to use pull, but all too often the default
fetch-then-merge behaviour doesn't match their expectations and they end up
starting threads like this one on the mailing list.

* If we change pull's default behaviour, we'll just be shifting the
mismatched expectations onto the other half of the new users who would be
happy with fetch-then-merge.

* I'm not sure why new users are taught to use pull.  I suspect it's because
it tries to hide the idea of local-vs-remote branches, and people writing git
tutorials don't want to overwhelm new users with what seems to be an internal
detail.  But these notions are really fundamental to using git effectively,
and I think pull does everyone a disservice by trying to gloss them over.

Anyway, rather than ranting on I'll just suggest that there's not enough
commonality between the ways people use git to make it worthwhile trying to
teach pull how to deal with a significant number of them.  I think the pull
command should be deprecated and quietly retired as a failed experiment.

		M.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)
  2014-04-30 14:21   ` Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment) Marc Branchaud
@ 2014-04-30 14:55     ` Junio C Hamano
  2014-04-30 19:45       ` Pull is Evil Marc Branchaud
  2014-04-30 16:47     ` Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment) Felipe Contreras
  1 sibling, 1 reply; 73+ messages in thread
From: Junio C Hamano @ 2014-04-30 14:55 UTC (permalink / raw)
  To: Marc Branchaud; +Cc: Marat Radchenko, git

Marc Branchaud <marcnarc@xiplink.com> writes:

> But I'm definitely biased because I think pull is pretty much broken:
>
> * New users are encouraged to use pull, but all too often the default
> fetch-then-merge behaviour doesn't match their expectations and they end up
> starting threads like this one on the mailing list.
>
> * If we change pull's default behaviour, we'll just be shifting the
> mismatched expectations onto the other half of the new users who would be
> happy with fetch-then-merge.
>
> * I'm not sure why new users are taught to use pull.  I suspect it's because
> it tries to hide the idea of local-vs-remote branches, and people writing git
> tutorials don't want to overwhelm new users with what seems to be an internal
> detail.  But these notions are really fundamental to using git effectively,
> and I think pull does everyone a disservice by trying to gloss them over.
>
> Anyway, rather than ranting on I'll just suggest that there's not enough
> commonality between the ways people use git to make it worthwhile trying to
> teach pull how to deal with a significant number of them.  I think the pull
> command should be deprecated and quietly retired as a failed experiment.

I almost agree with the first sentence in the last paragraph, and
your bulletted list above supports it.

I am not sure how the second sentence can follow as its consequence.

If the conclusion were "maybe adding a 'git update' to match the
expectation of those who build on top of the work of others (aka
CVS/SVN style) more  closely and teaching new users to use that
instead of 'git pull' may be a good way forward", I can sort of
understand (if I may not be able to immediately agree with, until I
can regurgitate the ramifications of such a change) it.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: A failing attempt to use Git in a centralized environment
  2014-04-28  6:29 A failing attempt to use Git in a centralized environment Marat Radchenko
  2014-04-28 18:41 ` Junio C Hamano
@ 2014-04-30 16:12 ` Stepan Kasal
  2014-04-30 17:15 ` Geert Bosch
  2014-05-02 20:56 ` Max Kirillov
  3 siblings, 0 replies; 73+ messages in thread
From: Stepan Kasal @ 2014-04-30 16:12 UTC (permalink / raw)
  To: Marat Radchenko; +Cc: git

Hello Marat,

On Mon, Apr 28, 2014 at 10:29:07AM +0400, Marat Radchenko wrote:
> Setup:
> 20 people (programmers, artists, designers) with prior SVN

I was in a similar situation: 10 people, mostly mathematicians,
previous experience with Tortoise SVN.

I wanted to move to Git with centralized model.  I call it a success:
people can do basic changes on master and also can work with
branches, if they don't want to break master.  (Much better than
keeping uncommitted changes at a svn checkout.)

I avoided TortoiseGit because I thought it would make the switch more
complicated: Git does differ from SVN, and it cannot be hidden.

We use Git Extensions (Windows only frontend).
I like it, as it is very close to command-line, so it is easy for me
to provide support.  It also improves the dialogs by hiding all the
advanced options; you have to click on "advanced" to get the full
list.

When working on master, pull --rebase is a necessity:
The install procedure does set config
  branch.autosetuprebase = always
(Must be done before any clone, so that all branches created after
that are set up to rebase, rtfm...)

I also told people to check "Rebase" in the pull dialog (it is
persistent then).

And I provided snapshots, so they immediatly call for help if they
see non-linear history.

> Problem #4: when conflict happens during rebase, mergetool shows
> user own changes as "theirs" and remote changes as "mine". And
> believe me, explaining this to users doesn't increase their
> willingness to adopt Git.

Our mergetool is Kdiff3.  (Git Extensions are willing to install it;
we did that separately to get a newer 64bit version.)
Kdiff3 shows three columns; their names (BASE, LOCAL, etc.) are
confusiong, but in our case it was easy to ignore them; we had no
previous experience with merge conflicts resolving.

> Problem #6: push - reject - pull - push sequence sometimes
> transforms into a loop with several iterations and doesn't add
> happiness.

I told people to do "pull-push" always when they want to push.
If the pull has conflicts, then they naturally do "pull-push" again
after the conflicts are resolved.

Git Extensions has its problems, you may look at the issue tracker;
I created several reports when exploring it (login kasal).

I would mention:
https://github.com/gitextensions/gitextensions/issues/2241

If you pull on a non-tracking branch, it creates a false
origin/branchname from origin/HEAD.  The bug was fixed, but there was
no release since then: so you have to live with it or you have to
build Git Extensions yourself in Visual Studio.

I had to write this in haste; hope this helps you anyway.

Stepan

^ permalink raw reply	[flat|nested] 73+ messages in thread

* RE: Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)
  2014-04-30 14:21   ` Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment) Marc Branchaud
  2014-04-30 14:55     ` Junio C Hamano
@ 2014-04-30 16:47     ` Felipe Contreras
  2014-04-30 17:09       ` Pull is Evil Matthieu Moy
  1 sibling, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-04-30 16:47 UTC (permalink / raw)
  To: Marc Branchaud, Junio C Hamano, Marat Radchenko; +Cc: git

Marc Branchaud wrote:
> But I'm definitely biased because I think pull is pretty much broken:
> 
> * New users are encouraged to use pull, but all too often the default
> fetch-then-merge behaviour doesn't match their expectations and they end up
> starting threads like this one on the mailing list.

Yes, this has been discussed many times in the past, and everyone agrees
the default behavior is not correct.

Most people agree it has to be changed.

And we have patches for it[1].

But it's not going to change. Why? No reason given, it's just not going
to.

> * If we change pull's default behaviour, we'll just be shifting the
> mismatched expectations onto the other half of the new users who would be
> happy with fetch-then-merge.

Not true. As it has been agreed in the discussions, very few people
would be affected negatively by this change, and even then an
appropriate error message like:

  The pull was not fast-forward, please either merge or rebase.
  If unsure, run 'git pull --merge'.

Should do the trick.

[1] http://article.gmane.org/gmane.comp.version-control.git/247567

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 16:47     ` Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment) Felipe Contreras
@ 2014-04-30 17:09       ` Matthieu Moy
  2014-04-30 18:31         ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: Matthieu Moy @ 2014-04-30 17:09 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: Marc Branchaud, Junio C Hamano, Marat Radchenko, git

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

> Marc Branchaud wrote:
>> But I'm definitely biased because I think pull is pretty much broken:
>> 
>> * New users are encouraged to use pull, but all too often the default
>> fetch-then-merge behaviour doesn't match their expectations and they end up
>> starting threads like this one on the mailing list.
>
> Yes, this has been discussed many times in the past, and everyone agrees
> the default behavior is not correct.

You definitely have a strange notion of "everyone".

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: A failing attempt to use Git in a centralized environment
  2014-04-28  6:29 A failing attempt to use Git in a centralized environment Marat Radchenko
  2014-04-28 18:41 ` Junio C Hamano
  2014-04-30 16:12 ` A failing attempt to use Git in a centralized environment Stepan Kasal
@ 2014-04-30 17:15 ` Geert Bosch
  2014-05-04  8:58   ` John Szakmeister
  2014-05-02 20:56 ` Max Kirillov
  3 siblings, 1 reply; 73+ messages in thread
From: Geert Bosch @ 2014-04-30 17:15 UTC (permalink / raw)
  To: Marat Radchenko; +Cc: git


On Apr 28, 2014, at 02:29, Marat Radchenko <marat@slonopotamus.org> wrote:

> In short:
> 1. Hack, hack, hack
> 2. Commit
> 3. Push, woops, reject (non-ff)
> 4. Pull
> 5. Push

Just do pull --rebase? This is essentially the same as what SVN
used to do in your setup.

  -Geert

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 17:09       ` Pull is Evil Matthieu Moy
@ 2014-04-30 18:31         ` Felipe Contreras
  2014-04-30 19:10           ` Junio C Hamano
  0 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-04-30 18:31 UTC (permalink / raw)
  To: Matthieu Moy, Felipe Contreras
  Cc: Marc Branchaud, Junio C Hamano, Marat Radchenko, git

Matthieu Moy wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > Marc Branchaud wrote:
> >> But I'm definitely biased because I think pull is pretty much broken:
> >> 
> >> * New users are encouraged to use pull, but all too often the default
> >> fetch-then-merge behaviour doesn't match their expectations and they end up
> >> starting threads like this one on the mailing list.
> >
> > Yes, this has been discussed many times in the past, and everyone agrees
> > the default behavior is not correct.
> 
> You definitely have a strange notion of "everyone".

Do I? Let's look at some of the discussions:

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

* W. Trevor King agrees the default should change
* Junio C Hamano agrees the default should change
* John Keeping agrees the default should change
* Matthieu Moy doesn't agree anything should change
* Linus Torvalds agrees changing the default is fine

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

* Richard Hansen agrees with my proposal
* Ramkumar Ramachandra agrees with my proposal
* Brian M. Carlson is not happy but can live with my proposal
* Jeff King accepts my proposal is a good way to move forward
* Matthieu Moy is OK with change, but only if the default remains the same

So, by "everyone" I mean everyone but one person (you).

Rational people don't think in absolute terms, "everyone" means
virtually everyone, which is the case.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 18:31         ` Felipe Contreras
@ 2014-04-30 19:10           ` Junio C Hamano
  2014-04-30 19:32             ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: Junio C Hamano @ 2014-04-30 19:10 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Matthieu Moy, Marc Branchaud, Marat Radchenko, git, Jeff King

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

> Matthieu Moy wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> ...
>> > Yes, this has been discussed many times in the past, and everyone agrees
>> > the default behavior is not correct.
>> 
>> You definitely have a strange notion of "everyone".
>
> Do I? Let's look at some of the discussions:
>
> http://thread.gmane.org/gmane.comp.version-control.git/225146
>
> * W. Trevor King agrees the default should change
> * Junio C Hamano agrees the default should change
> * John Keeping agrees the default should change
> * Matthieu Moy doesn't agree anything should change
> * Linus Torvalds agrees changing the default is fine
>
> http://thread.gmane.org/gmane.comp.version-control.git/233554
>
> * Richard Hansen agrees with my proposal
> * Ramkumar Ramachandra agrees with my proposal
> * Brian M. Carlson is not happy but can live with my proposal
> * Jeff King accepts my proposal is a good way to move forward
> * Matthieu Moy is OK with change, but only if the default remains the same
>
> So, by "everyone" I mean everyone but one person (you).

I looked at the latter thread and re-read what Peff wrote (added to
Cc).  I think the most relevant (other than solving it in quite a
different way $gmane/233554) one to your version of the solution is
this:

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

where he responds to my "how about this way forward" with this:

    > ... I think other people are also in
    > agreement. So perhaps:
    > 
    >  - drop jc/pull-training-wheel and revert its merge from 'next';
    > 
    >  - update Felipe's series with a bit of tweak to make it less
    >    impactful by demoting error into warning and advice.
    > 
    > would be a good way forward?

    I think that would address the concern I raised, because it does not
    create a roadblock to new users accomplishing their task. They can
    ignore the warning, or choose "merge" as the default to shut up the
    warning (and it is easy to choose that if you are confused, because
    it is what git is doing by default alongside the warning).

While I do not quite see the previous discussion as deciding the
particular implementation is good without further tweaks, I would
say that everybody agrees that the default behaviour is not good for
everybody and therefore should (or for Linus, "it is OK to") change.

> Rational people don't think in absolute terms, "everyone" means
> virtually everyone, which is the case.

True for "should change", not virtually everyone for "should change
with that particular solution".

But after re-reading the series description 0/n this round in the
other thread, I think the overall direction is good (just like Peff
said in the previous thread), especially if there is a warning not
error period.

The step (I am not sure you have it in your series or not, but I
would strongly recommend adding one if it doesn't yet) that gives a
"will change the default, and here is how to configure" warning when
we see an actual merge made (or rebased) after "git pull" without
"--merge/--rebase" is not just a way to prepare existing users, but
is a good way to bring new goodness to newbies.  The session might
go like this:

	$ git pull
        ... fetching ...
        ... merging ...
        ... diffstat ...
        warning: you merged the $branch from $remote into your
        warning: work, which may not be what you wanted to do unless
        warning: you are acting as a project integrator.  If that is
        warning: the case, "git config --set pull.mode ff-only" to
        warning: cause "git pull" to refuse working when it does not
        warning: fast-forward.  Use pull.mode=merge if you did mean
        warning: it, to squelch this message.

I am not advocating the exact wording above, but am illustrating
that there is a place for us to tell the new people to live in a
better future before the switchover happens.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 19:10           ` Junio C Hamano
@ 2014-04-30 19:32             ` Felipe Contreras
  2014-04-30 19:53               ` Junio C Hamano
  0 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-04-30 19:32 UTC (permalink / raw)
  To: Junio C Hamano, Felipe Contreras
  Cc: Matthieu Moy, Marc Branchaud, Marat Radchenko, git, Jeff King

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> > Matthieu Moy wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >> ...
> >> > Yes, this has been discussed many times in the past, and everyone agrees
> >> > the default behavior is not correct.
> >> 
> >> You definitely have a strange notion of "everyone".

> While I do not quite see the previous discussion as deciding the
> particular implementation is good without further tweaks, I would
> say that everybody agrees that the default behaviour is not good for
> everybody and therefore should (or for Linus, "it is OK to") change.

Yes. The only aspect I didn't see consensus is whether
'git pull $remote' should reject non-ff merges by default as well. I
argued that 'git pull $remote' shouldn't behave differently than
'git pull', but I got no responses.

> > Rational people don't think in absolute terms, "everyone" means
> > virtually everyone, which is the case.
> 
> True for "should change", not virtually everyone for "should change
> with that particular solution".

I said 'everyone agrees the default behavior is not correct', which is
true.

> But after re-reading the series description 0/n this round in the
> other thread, I think the overall direction is good (just like Peff
> said in the previous thread), especially if there is a warning not
> error period.
> 
> The step (I am not sure you have it in your series or not, but I
> would strongly recommend adding one if it doesn't yet) that gives a
> "will change the default, and here is how to configure" warning when
> we see an actual merge made (or rebased) after "git pull" without
> "--merge/--rebase" is not just a way to prepare existing users, but
> is a good way to bring new goodness to newbies.  The session might
> go like this:
> 
> 	$ git pull
>         ... fetching ...
>         ... merging ...
>         ... diffstat ...
>         warning: you merged the $branch from $remote into your
>         warning: work, which may not be what you wanted to do unless
>         warning: you are acting as a project integrator.  If that is
>         warning: the case, "git config --set pull.mode ff-only" to
>         warning: cause "git pull" to refuse working when it does not
>         warning: fast-forward.  Use pull.mode=merge if you did mean
>         warning: it, to squelch this message.
> 
> I am not advocating the exact wording above, but am illustrating
> that there is a place for us to tell the new people to live in a
> better future before the switchover happens.

As I said, I already sent a patch similar to that, but I dropped it
since this was for v2.0, and since I excepted this series to be ignored
like so many.

I'll resend.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 14:55     ` Junio C Hamano
@ 2014-04-30 19:45       ` Marc Branchaud
  2014-04-30 20:01         ` Jonathan Nieder
                           ` (3 more replies)
  0 siblings, 4 replies; 73+ messages in thread
From: Marc Branchaud @ 2014-04-30 19:45 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Marat Radchenko, git

On 14-04-30 10:55 AM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
> 
>> But I'm definitely biased because I think pull is pretty much broken:
>>
>> * New users are encouraged to use pull, but all too often the default
>> fetch-then-merge behaviour doesn't match their expectations and they end up
>> starting threads like this one on the mailing list.
>>
>> * If we change pull's default behaviour, we'll just be shifting the
>> mismatched expectations onto the other half of the new users who would be
>> happy with fetch-then-merge.
>>
>> * I'm not sure why new users are taught to use pull.  I suspect it's because
>> it tries to hide the idea of local-vs-remote branches, and people writing git
>> tutorials don't want to overwhelm new users with what seems to be an internal
>> detail.  But these notions are really fundamental to using git effectively,
>> and I think pull does everyone a disservice by trying to gloss them over.
>>
>> Anyway, rather than ranting on I'll just suggest that there's not enough
>> commonality between the ways people use git to make it worthwhile trying to
>> teach pull how to deal with a significant number of them.  I think the pull
>> command should be deprecated and quietly retired as a failed experiment.
> 
> I almost agree with the first sentence in the last paragraph, and
> your bulletted list above supports it.
> 
> I am not sure how the second sentence can follow as its consequence.
> 
> If the conclusion were "maybe adding a 'git update' to match the
> expectation of those who build on top of the work of others (aka
> CVS/SVN style) more  closely and teaching new users to use that
> instead of 'git pull' may be a good way forward", I can sort of
> understand (if I may not be able to immediately agree with, until I
> can regurgitate the ramifications of such a change) it.

(Yum!  You know, regurgitated ramifications aren't just for breakfast
anymore... :) )

I think we would run into much the same problem with "git update" as we do
with "git pull".  To wit, any "git pull" (or "git update") implementation
needs to make certain workflow assumptions.  I think that no matter which
assumptions are made, there will always be a significant proportion of new
users[1] for whom the assumptions are wrong.

This is why the command is broken.  It's also why the "let's change git pull"
discussions never seem to get anywhere:  Attempting to make the command work
in new user X's environment will make it not work in new user Y's.  Whatever
change is made to "git pull", after a few months new user Y comes along and
says it's wrong.

And now we're seeing third-party tools, like TortoiseGit, using "git pull"
(or the default "git pull" workflow model) and exposing yet more new users to
workflow dissonance.

I don't think we'll ever be able to create a One "Git Pull" To Rule Them All.
 At best we'll end up with something with enough knobs that it could be
configured to work in most workflows (I think we're actually pretty close to
that).  But for new users that defeats the purpose.  It means that "git pull"
is really an advanced command, and beginners should avoid it until they
understand enough of git to configure it properly.

So rather than perpetuate the myth that one command can always (or even just
usually) do the right thing, let's just retire the command.

All that said, I don't object to any attempts at improving the command
either.  But I also don't see any kind of improvement that would lead me to
start using "git pull" let alone recommending it to new users.

		M.

[1] By "significant" I mean "enough to perpetually create new mailing list
threads about changing 'git pull'".

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 19:32             ` Felipe Contreras
@ 2014-04-30 19:53               ` Junio C Hamano
  2014-04-30 20:11                 ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: Junio C Hamano @ 2014-04-30 19:53 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Matthieu Moy, Marc Branchaud, Marat Radchenko, git, Jeff King

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

> Junio C Hamano wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> > Matthieu Moy wrote:
>> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
>> >> ...
>> >> > Yes, this has been discussed many times in the past, and everyone agrees
>> >> > the default behavior is not correct.
>> >> 
>> >> You definitely have a strange notion of "everyone".
>
>> While I do not quite see the previous discussion as deciding the
>> particular implementation is good without further tweaks, I would
>> say that everybody agrees that the default behaviour is not good for
>> everybody and therefore should (or for Linus, "it is OK to") change.
> ...
> I said 'everyone agrees the default behavior is not correct', which is
> true.

Isn't that what I said a few lines above?  Why are you still
arguing?

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 19:45       ` Pull is Evil Marc Branchaud
@ 2014-04-30 20:01         ` Jonathan Nieder
  2014-04-30 20:01         ` Junio C Hamano
                           ` (2 subsequent siblings)
  3 siblings, 0 replies; 73+ messages in thread
From: Jonathan Nieder @ 2014-04-30 20:01 UTC (permalink / raw)
  To: Marc Branchaud; +Cc: Junio C Hamano, Marat Radchenko, git

Marc Branchaud wrote:

> All that said, I don't object to any attempts at improving the command
> either.  But I also don't see any kind of improvement that would lead me to
> start using "git pull" let alone recommending it to new users.

If "git pull" starts using --ff-only by default then I might start
recommending it.

I'm a little scared to look at the details of this thread.  Hopefully
once the topic matures and settles down a little it will be worthwhile
to review, or if there's any way I can help before then, feel free to
ask me privately.

Thanks for your work,
Jonathan

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 19:45       ` Pull is Evil Marc Branchaud
  2014-04-30 20:01         ` Jonathan Nieder
@ 2014-04-30 20:01         ` Junio C Hamano
  2014-04-30 21:48           ` Marc Branchaud
  2014-05-02  7:40           ` Andreas Krey
  2014-04-30 20:14         ` Felipe Contreras
  2014-05-01 21:06         ` Philip Oakley
  3 siblings, 2 replies; 73+ messages in thread
From: Junio C Hamano @ 2014-04-30 20:01 UTC (permalink / raw)
  To: Marc Branchaud; +Cc: Marat Radchenko, git

Marc Branchaud <marcnarc@xiplink.com> writes:

> On 14-04-30 10:55 AM, Junio C Hamano wrote:
>> Marc Branchaud <marcnarc@xiplink.com> writes:
> ...
>>> Anyway, rather than ranting on I'll just suggest that there's not enough
>>> commonality between the ways people use git to make it worthwhile trying to
>>> teach pull how to deal with a significant number of them.  I think the pull
>>> command should be deprecated and quietly retired as a failed experiment.
>> 
>> I almost agree with the first sentence in the last paragraph, and
>> your bulletted list above supports it.
>> 
>> I am not sure how the second sentence can follow as its consequence.
>> 
>> If the conclusion were "maybe adding a 'git update' to match the
>> expectation of those who build on top of the work of others (aka
>> CVS/SVN style) more  closely and teaching new users to use that
>> instead of 'git pull' may be a good way forward", I can sort of
>> understand (if I may not be able to immediately agree with, until I
>> can regurgitate the ramifications of such a change) it.
>
> I think we would run into much the same problem with "git update" as we do
> with "git pull"....

Maybe I was unclear.

I didn't mean "replace 'pull' with 'update' everywhere".  I meant
"Introduce 'update' that lets integrate your history into that from
the remote, which is to integrate in a direction opposite from how
'pull' does".  

Then the downstream people (i.e. by definition, most of us) would
use "git update" while integrators would use "git pull".  There is
no workflow assumption if we do so.

> I don't think we'll ever be able to create a One "Git Pull" To Rule Them All.

Yes, that is exactly why I mentioned "git update".

Another way not to make any workflow assumption is to ask the user
to tell us.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 19:53               ` Junio C Hamano
@ 2014-04-30 20:11                 ` Felipe Contreras
  0 siblings, 0 replies; 73+ messages in thread
From: Felipe Contreras @ 2014-04-30 20:11 UTC (permalink / raw)
  To: Junio C Hamano, Felipe Contreras
  Cc: Matthieu Moy, Marc Branchaud, Marat Radchenko, git, Jeff King

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> > Junio C Hamano wrote:
> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >> > Matthieu Moy wrote:
> >> >> Felipe Contreras <felipe.contreras@gmail.com> writes:
> >> >> ...
> >> >> > Yes, this has been discussed many times in the past, and everyone agrees
> >> >> > the default behavior is not correct.
> >> >> 
> >> >> You definitely have a strange notion of "everyone".
> >
> >> While I do not quite see the previous discussion as deciding the
> >> particular implementation is good without further tweaks, I would
> >> say that everybody agrees that the default behaviour is not good for
> >> everybody and therefore should (or for Linus, "it is OK to") change.
> > ...
> > I said 'everyone agrees the default behavior is not correct', which is
> > true.
> 
> Isn't that what I said a few lines above?  Why are you still
> arguing?

I'm not arguing, I'm clarifying what I said for Matthieu. What I said
was a response to him.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 19:45       ` Pull is Evil Marc Branchaud
  2014-04-30 20:01         ` Jonathan Nieder
  2014-04-30 20:01         ` Junio C Hamano
@ 2014-04-30 20:14         ` Felipe Contreras
  2014-04-30 22:06           ` Marc Branchaud
  2014-05-01 21:06         ` Philip Oakley
  3 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-04-30 20:14 UTC (permalink / raw)
  To: Marc Branchaud, Junio C Hamano; +Cc: Marat Radchenko, git

Marc Branchaud wrote:
> All that said, I don't object to any attempts at improving the command
> either.  But I also don't see any kind of improvement that would lead
> me to start using "git pull" let alone recommending it to new users.

What is wrong when `git pull` merges a fast-forward? The problems with
`git pull` come when you can't do a fast-forward merge, right?

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 20:01         ` Junio C Hamano
@ 2014-04-30 21:48           ` Marc Branchaud
  2014-05-02  7:40           ` Andreas Krey
  1 sibling, 0 replies; 73+ messages in thread
From: Marc Branchaud @ 2014-04-30 21:48 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Marat Radchenko, git

On 14-04-30 04:01 PM, Junio C Hamano wrote:
> 
> Maybe I was unclear.
> 
> I didn't mean "replace 'pull' with 'update' everywhere".  I meant
> "Introduce 'update' that lets integrate your history into that from
> the remote, which is to integrate in a direction opposite from how
> 'pull' does".  

That's what I understood.

> Then the downstream people (i.e. by definition, most of us) would
> use "git update" while integrators would use "git pull".  There is
> no workflow assumption if we do so.

Isn't merge-or-rebase a workflow assumption?  I don't think there's a good
rule of thumb for that choice.  Downstream-vs-Integrator doesn't seem like
enough, nor does it seem as simple as "'git pull' should merge" and "'git
update' should rebase" (or vice-versa).

But maybe I'm wrong and there really is only one salient axis (be it that one
or another).

>> I don't think we'll ever be able to create a One "Git Pull" To Rule Them All.
> 
> Yes, that is exactly why I mentioned "git update".

I doubt that a new, additional command with different workflow assumptions
will be any more successful.

> Another way not to make any workflow assumption is to ask the user
> to tell us.

Yes.  But I wouldn't expect a new user to be able to answer.

		M.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 20:14         ` Felipe Contreras
@ 2014-04-30 22:06           ` Marc Branchaud
  2014-04-30 22:25             ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: Marc Branchaud @ 2014-04-30 22:06 UTC (permalink / raw)
  To: Felipe Contreras, Junio C Hamano; +Cc: Marat Radchenko, git

On 14-04-30 04:14 PM, Felipe Contreras wrote:
> Marc Branchaud wrote:
>> All that said, I don't object to any attempts at improving the command
>> either.  But I also don't see any kind of improvement that would lead
>> me to start using "git pull" let alone recommending it to new users.
> 
> What is wrong when `git pull` merges a fast-forward?

Nothing.  Everything.  It depends.

> The problems with `git pull` come when you can't do a fast-forward merge, right?

Some of them, maybe most of them.

But the reason "git pull" is broken is that any solution to the problems that
arise depend on the project's workflow.  That would be fine if there was a
workflow that suited some large majority of users, but there doesn't seem to
be one.

<aside>

I dug up the workflows question from the 2012 user survey[1], but it's less
revealing than one might like:

 19. What git workflow(s) is used by projects in which development you
participate?

single developer, only private repository (no interaction)		67%

centralized workflow (push to common repository)			69%

branched centralized (push to different branches in common repository)	50%

peer-to-peer workflow (all repositories roughly equal)			 9%

integration-manager workflow (maintainer pulls/applies patches to "blessed"
repository))	19%

dictator and lieutenants workflow (hierarchical workflow)		 5%

using collaborative code review tool, e.g. Gerrit			13%

other workflow, please explain						 2%

Total respondents	4352

Respondents who skipped this question	135

(IIRC, this was a "check all that apply" question.)

I don't think this lets us conclude anything about the popularity of merging
or rebasing, even though many respondents use a centralized workflow.  I use
a centralized workflow, and I will sometimes merge and sometimes rebase.  It
depends on the work I'm doing.

</aside>

		M.

[1] https://www.survs.com/results/QPESOB10/ME8UTHXM4M

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 22:06           ` Marc Branchaud
@ 2014-04-30 22:25             ` Felipe Contreras
  2014-05-01  9:46               ` brian m. carlson
  0 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-04-30 22:25 UTC (permalink / raw)
  To: Marc Branchaud, Felipe Contreras, Junio C Hamano; +Cc: Marat Radchenko, git

Marc Branchaud wrote:
> On 14-04-30 04:14 PM, Felipe Contreras wrote:
> > Marc Branchaud wrote:
> >> All that said, I don't object to any attempts at improving the command
> >> either.  But I also don't see any kind of improvement that would lead
> >> me to start using "git pull" let alone recommending it to new users.
> > 
> > What is wrong when `git pull` merges a fast-forward?
> 
> Nothing.  Everything.  It depends.

It depends on what? I don't see how a fast-forward `git pull` could
possibly have any trouble.

> > The problems with `git pull` come when you can't do a fast-forward merge, right?
> 
> Some of them, maybe most of them.

Name one problem with a fast-forward merge.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 22:25             ` Felipe Contreras
@ 2014-05-01  9:46               ` brian m. carlson
  2014-05-01 10:48                 ` Felipe Contreras
                                   ` (2 more replies)
  0 siblings, 3 replies; 73+ messages in thread
From: brian m. carlson @ 2014-05-01  9:46 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: Marc Branchaud, Junio C Hamano, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 1370 bytes --]

On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:
> Marc Branchaud wrote:
> > On 14-04-30 04:14 PM, Felipe Contreras wrote:
> > > What is wrong when `git pull` merges a fast-forward?
> > 
> > Nothing.  Everything.  It depends.
> 
> It depends on what? I don't see how a fast-forward `git pull` could
> possibly have any trouble.
> 
> > > The problems with `git pull` come when you can't do a fast-forward merge, right?
> > 
> > Some of them, maybe most of them.
> 
> Name one problem with a fast-forward merge.

At work, we have a workflow where we merge topic branches as
non-fast-forward, so that we have a record of the history (including who
reviewed the code), but when we want to just update our local branches,
we always want fast-forward:

  git checkout maintenance-branch
  # Update our maintenance branch to the latest from the main repo.
  git pull --ff-only
  git pull --no-ff developer-remote topic-branch
  git push main-repo HEAD

So there are times when fast-forward merges are the right thing, and
times when they're not, and as you can see, this depends on context and
isn't per-repository.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-01  9:46               ` brian m. carlson
@ 2014-05-01 10:48                 ` Felipe Contreras
  2014-05-01 15:16                   ` Junio C Hamano
  2014-05-01 15:20                 ` Marc Branchaud
  2014-05-01 19:27                 ` Felipe Contreras
  2 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-05-01 10:48 UTC (permalink / raw)
  To: brian m. carlson, Felipe Contreras
  Cc: Marc Branchaud, Junio C Hamano, Marat Radchenko, git

brian m. carlson wrote:
> On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:
> > Marc Branchaud wrote:
> > > On 14-04-30 04:14 PM, Felipe Contreras wrote:
> > > > What is wrong when `git pull` merges a fast-forward?
> > > 
> > > Nothing.  Everything.  It depends.
> > 
> > It depends on what? I don't see how a fast-forward `git pull` could
> > possibly have any trouble.
> > 
> > > > The problems with `git pull` come when you can't do a fast-forward merge, right?
> > > 
> > > Some of them, maybe most of them.
> > 
> > Name one problem with a fast-forward merge.
> 
> At work, we have a workflow where we merge topic branches as
> non-fast-forward, so that we have a record of the history (including who
> reviewed the code), but when we want to just update our local branches,
> we always want fast-forward:
> 
>   git checkout maintenance-branch
>   # Update our maintenance branch to the latest from the main repo.
>   git pull --ff-only
>   git pull --no-ff developer-remote topic-branch
>   git push main-repo HEAD
> 
> So there are times when fast-forward merges are the right thing, and
> times when they're not, and as you can see, this depends on context and
> isn't per-repository.

That's not what I asked.

I didn't ask you if fast-forward merges were the right thing to do in
every situation.

I asked you, *when* people do a fast-forward merge (that is; when it's
possible and desirable), what are the problems that a fast-forward merge
causes?

I tired of waiting, so I'll answer for you: there are absolutely no
problems. The problems are only on non-fast-forward merges, and we have
a solution.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-01 10:48                 ` Felipe Contreras
@ 2014-05-01 15:16                   ` Junio C Hamano
  2014-05-01 19:16                     ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: Junio C Hamano @ 2014-05-01 15:16 UTC (permalink / raw)
  To: Felipe Contreras; +Cc: brian m. carlson, Marc Branchaud, Marat Radchenko, git

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

> brian m. carlson wrote:
>> ..
>> At work, we have a workflow where we merge topic branches as
>> non-fast-forward, so that we have a record of the history (including who
>> reviewed the code), but when we want to just update our local branches,
>> we always want fast-forward:
>> 
>>   git checkout maintenance-branch
>>   # Update our maintenance branch to the latest from the main repo.
>>   git pull --ff-only
>>   git pull --no-ff developer-remote topic-branch
>>   git push main-repo HEAD
>> 
>> So there are times when fast-forward merges are the right thing, and
>> times when they're not, and as you can see, this depends on context and
>> isn't per-repository.
>
> That's not what I asked.
>
> I didn't ask you if fast-forward merges were the right thing to do in
> every situation.
>
> I asked you, *when* people do a fast-forward merge (that is; when it's
> possible and desirable), what are the problems that a fast-forward merge
> causes?

But then I think you asked a wrong question.  The opposite case of
the question tells me what is wrong in it:

    When people do a real merge (that is: when it's possible and
    desirable), there is no reason to forbid 'git pull' from creating a
    real merge.  What are the problems that a real merge causes under
    that condition?

By definition, because of "when it's possible and DESIRABLE" part,
the answer is "absolutely zero".  That is not an interesting
question, is it?

My reading of the design of the "let's forbid non-ff merge when
people do 'git pull'" is based on this reasonong:

 - Most people are not integrators, and letting "git pull" run on
   their work based on a stale upstream to sync with an updated
   upstream would create a merge in a wrong direction and letting
   user continue on it.  We need to have a way to prevent this.

 - Forbid "git pull" when the HEAD is based on a stale upstream,
   i.e. the pull does not fast-forward.  Integrators that would want
   to _allow_ real merges may be inconvenienced so we will give a
   configuration to let them say that with pull.mode=merge.

 - We do not forbid "git pull" if the pull will fast-forward.  We do
   not do anything for that case, because everybody will accept
   fast-forward, whether he is a contributor or an integrator.

Doesn't Brian's case show the justification "because everybody will
accept fast-forward" does not hold?  It shows that the user do not
necessarily know when it's possible and DESIRABLE, and updating the
command is about helping people avoid an action that may not be
desirable in the end.

Brian needs a way to make sure he fast-forwards when pulling the
project's maintenance-branch into his maintenance-branch, and also
he does *not* fast-forward when pulling developer's fix branch into
that same maintenance-branch of his.  So neither pull.mode nor
branch.*.pullmode would help him and the example may show we need a
bit more work to help that case, no?

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-01  9:46               ` brian m. carlson
  2014-05-01 10:48                 ` Felipe Contreras
@ 2014-05-01 15:20                 ` Marc Branchaud
  2014-05-01 17:56                   ` W. Trevor King
  2014-05-01 19:22                   ` Felipe Contreras
  2014-05-01 19:27                 ` Felipe Contreras
  2 siblings, 2 replies; 73+ messages in thread
From: Marc Branchaud @ 2014-05-01 15:20 UTC (permalink / raw)
  To: Felipe Contreras, Junio C Hamano, Marat Radchenko, git

On 14-05-01 05:46 AM, brian m. carlson wrote:
> On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:
>> Marc Branchaud wrote:
>>> On 14-04-30 04:14 PM, Felipe Contreras wrote:
>>>> What is wrong when `git pull` merges a fast-forward?
>>>
>>> Nothing.  Everything.  It depends.
>>
>> It depends on what? I don't see how a fast-forward `git pull` could
>> possibly have any trouble.
>>
>>>> The problems with `git pull` come when you can't do a fast-forward merge, right?
>>>
>>> Some of them, maybe most of them.
>>
>> Name one problem with a fast-forward merge.
> 
> At work, we have a workflow where we merge topic branches as
> non-fast-forward, so that we have a record of the history (including who
> reviewed the code), but when we want to just update our local branches,
> we always want fast-forward:
> 
>   git checkout maintenance-branch
>   # Update our maintenance branch to the latest from the main repo.
>   git pull --ff-only
>   git pull --no-ff developer-remote topic-branch
>   git push main-repo HEAD

Thanks for the nice example.

To me this looks like an advanced use of "git pull".  A new user could be
taught to work like this, but I don't think a new user would come up with it
on their own (until they became an experienced user).

What's more, it seems to me that the only real advantage "git pull" provides
here is a less typing compared to the non-pull equivalent:

  git fetch main-repo
  git checkout main-repo/maintenance-branch
  git fetch developer-remote
  git merge --no-ff developer-remote/topic-branch
  git push main-repo HEAD

I suggest that this approach is superior for new users (despite the increased
risk of finger cramps), because if main-repo's maintenance-branch is updated
in the interim and the push fails, the user can use the exact same commands
to resolve the situation.

Sure, the non-pull approach makes use of Scary Branch Stuff (remotes and
namespaces and detached HEADs -- oh my!).  But trying to avoid that stuff is
precisely the slippery slope that led to pull's misguided gymnastics.  We've
gone down that slope, slipped and fallen over, and now we're wallowing in the
muck.

		M.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Re: Pull is Evil
  2014-05-01 15:20                 ` Marc Branchaud
@ 2014-05-01 17:56                   ` W. Trevor King
  2014-05-01 18:04                     ` Marc Branchaud
  2014-05-01 19:22                   ` Felipe Contreras
  1 sibling, 1 reply; 73+ messages in thread
From: W. Trevor King @ 2014-05-01 17:56 UTC (permalink / raw)
  To: Marc Branchaud; +Cc: Felipe Contreras, Junio C Hamano, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 1674 bytes --]

On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
> On 14-05-01 05:46 AM, brian m. carlson wrote:
> >   git checkout maintenance-branch
> >   # Update our maintenance branch to the latest from the main repo.
> >   git pull --ff-only
> >   git pull --no-ff developer-remote topic-branch
> >   git push main-repo HEAD
> 
> …
> What's more, it seems to me that the only real advantage "git pull" provides
> here is a less typing compared to the non-pull equivalent:
> 
>   git fetch main-repo
>   git checkout main-repo/maintenance-branch
>   git fetch developer-remote
>   git merge --no-ff developer-remote/topic-branch
>   git push main-repo HEAD

You're missing Brian's fast-forward merge here.  It should be:

  git checkout maintenance-branch
  git fetch main-repo
  git merge --ff-only main-repo/maintenance-branch
  git fetch developer-remote
  …

> Sure, the non-pull approach makes use of Scary Branch Stuff (remotes
> and namespaces and detached HEADs -- oh my!).

No need for detached heads with Brian's local maintenance-branch.  If
you're teaching and just need folks merging the remote's HEAD, you
can avoid namespaces and remotes entirely:

  git fetch git://example.net/main-repo.git
  git merge --ff-only FETCH_HEAD

although I doubt “the remote's HEAD” will be easier to explain than
the namespaced, remote-tracking branches it replaces.  It's certainly
not worth the hassle of un-training FETCH_HEAD-merges later on ;).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Re: Pull is Evil
  2014-05-01 17:56                   ` W. Trevor King
@ 2014-05-01 18:04                     ` Marc Branchaud
  2014-05-01 18:30                       ` W. Trevor King
  2014-05-01 23:45                       ` brian m. carlson
  0 siblings, 2 replies; 73+ messages in thread
From: Marc Branchaud @ 2014-05-01 18:04 UTC (permalink / raw)
  To: W. Trevor King; +Cc: Felipe Contreras, Junio C Hamano, Marat Radchenko, git

On 14-05-01 01:56 PM, W. Trevor King wrote:
> On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
>> On 14-05-01 05:46 AM, brian m. carlson wrote:
>>>   git checkout maintenance-branch
>>>   # Update our maintenance branch to the latest from the main repo.
>>>   git pull --ff-only
>>>   git pull --no-ff developer-remote topic-branch
>>>   git push main-repo HEAD
>>
>> …
>> What's more, it seems to me that the only real advantage "git pull" provides
>> here is a less typing compared to the non-pull equivalent:
>>
>>   git fetch main-repo
>>   git checkout main-repo/maintenance-branch
>>   git fetch developer-remote
>>   git merge --no-ff developer-remote/topic-branch
>>   git push main-repo HEAD
> 
> You're missing Brian's fast-forward merge here.  It should be:
> 
>   git checkout maintenance-branch
>   git fetch main-repo
>   git merge --ff-only main-repo/maintenance-branch
>   git fetch developer-remote
>   …

I think you're mistaken -- I checked out "main-repo/maintenance-branch"
directly, so there's no need to fast-forward a local branch.

>> Sure, the non-pull approach makes use of Scary Branch Stuff (remotes
>> and namespaces and detached HEADs -- oh my!).
> 
> No need for detached heads with Brian's local maintenance-branch.

Yes.  OTOH, no need to bother keeping a local maintenance-branch up to date
if you use a detached HEAD.

> If
> you're teaching and just need folks merging the remote's HEAD, you
> can avoid namespaces and remotes entirely:
> 
>   git fetch git://example.net/main-repo.git
>   git merge --ff-only FETCH_HEAD
> 
> although I doubt “the remote's HEAD” will be easier to explain than
> the namespaced, remote-tracking branches it replaces.  It's certainly
> not worth the hassle of un-training FETCH_HEAD-merges later on ;).

Agreed.  I wouldn't advocate teaching people about FETCH_HEAD as if it were
something they should use regularly.

		M.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Re: Pull is Evil
  2014-05-01 18:04                     ` Marc Branchaud
@ 2014-05-01 18:30                       ` W. Trevor King
  2014-05-01 20:21                         ` Marc Branchaud
  2014-05-01 23:45                       ` brian m. carlson
  1 sibling, 1 reply; 73+ messages in thread
From: W. Trevor King @ 2014-05-01 18:30 UTC (permalink / raw)
  To: Marc Branchaud; +Cc: Felipe Contreras, Junio C Hamano, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]

On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote:
> On 14-05-01 01:56 PM, W. Trevor King wrote:
> > On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
> >> On 14-05-01 05:46 AM, brian m. carlson wrote:
> >>>   git checkout maintenance-branch
> >>>   # Update our maintenance branch to the latest from the main repo.
> >>>   git pull --ff-only
> >>>   git pull --no-ff developer-remote topic-branch
> >>>   git push main-repo HEAD
> >>
> >> …
> >> What's more, it seems to me that the only real advantage "git
> >> pull" provides here is a less typing compared to the non-pull
> >> equivalent:
> >>
> >>   git fetch main-repo
> >>   git checkout main-repo/maintenance-branch
> >>   git fetch developer-remote
> >>   git merge --no-ff developer-remote/topic-branch
> >>   git push main-repo HEAD
> > 
> > You're missing Brian's fast-forward merge here.  It should be:
> > 
> >   git checkout maintenance-branch
> >   git fetch main-repo
> >   git merge --ff-only main-repo/maintenance-branch
> >   git fetch developer-remote
> >   …
> 
> I think you're mistaken -- I checked out
> "main-repo/maintenance-branch" directly, so there's no need to
> fast-forward a local branch.

I find a local branch useful to mark the amount of the upstream branch
that I've reviewed.  The reflog helps a bit, but I may go several
fetches between reviews.  For newbies, I recommend avoiding detached
HEADs, where possible, so they don't have to rely on the reflog if
they accidentally commit and then checkout something else (ignoring
Git's warning).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-01 15:16                   ` Junio C Hamano
@ 2014-05-01 19:16                     ` Felipe Contreras
  2014-05-01 19:48                       ` W. Trevor King
  0 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-05-01 19:16 UTC (permalink / raw)
  To: Junio C Hamano, Felipe Contreras
  Cc: brian m. carlson, Marc Branchaud, Marat Radchenko, git

Junio C Hamano wrote:
> Felipe Contreras <felipe.contreras@gmail.com> writes:
> 
> > brian m. carlson wrote:
> >> ..
> >> At work, we have a workflow where we merge topic branches as
> >> non-fast-forward, so that we have a record of the history (including who
> >> reviewed the code), but when we want to just update our local branches,
> >> we always want fast-forward:
> >> 
> >>   git checkout maintenance-branch
> >>   # Update our maintenance branch to the latest from the main repo.
> >>   git pull --ff-only
> >>   git pull --no-ff developer-remote topic-branch
> >>   git push main-repo HEAD
> >> 
> >> So there are times when fast-forward merges are the right thing, and
> >> times when they're not, and as you can see, this depends on context and
> >> isn't per-repository.
> >
> > That's not what I asked.
> >
> > I didn't ask you if fast-forward merges were the right thing to do in
> > every situation.
> >
> > I asked you, *when* people do a fast-forward merge (that is; when it's
> > possible and desirable), what are the problems that a fast-forward merge
> > causes?
> 
> But then I think you asked a wrong question.

I asked the simple uncontroversial question as a rhetorical aid. I hoped
I would get the obvious answer, but I didn't even get that, so what hope
is there of convincing these people of the one that needs real pondering?

> The opposite case of the question tells me what is wrong in it:
> 
>     When people do a real merge (that is: when it's possible and
>     desirable), there is no reason to forbid 'git pull' from creating a
>     real merge.  What are the problems that a real merge causes under
>     that condition?
> 
> By definition, because of "when it's possible and DESIRABLE" part,
> the answer is "absolutely zero".  That is not an interesting
> question, is it?

That's right, but we are discussing the default behavior of `git pull`,
which if we agree has no problems when the ff is a) possible, and b)
desirable, the problems must come when either one of those is not met.

 a) If the fast-forward is not possible, that creates problems, because
    a real merge might happen, and it's not desirable. However, if we
    don't allow real merges to happen by default this couldn't be a
    problem.

 b) If the fast-forward is not desirable, then the user wouldn't be
    running `git pull`, would be running `git pull --no-ff`.

In other words, after the proposed changes `git pull` by default would
have no issues.

> Doesn't Brian's case show the justification "because everybody will
> accept fast-forward" does not hold?  It shows that the user do not
> necessarily know when it's possible and DESIRABLE, and updating the
> command is about helping people avoid an action that may not be
> desirable in the end.

No, it doesn't hold. As I said, if we change the default the fact that
it's not possible is not an issue.

The only problem would be when it's not desirable, however, that's a
problem of the user's ignorance, and the failure of the project's
policity to communicate clearly to him that he should be running
`git merge --no-ff`. There's absolutely nothing we can do to help him.

The only thing we could do is not allow fast-forward merges either, in
which case `git pull` becomes a no-op that can't possibly do anything
ever.

> Brian needs a way to make sure he fast-forwards when pulling the
> project's maintenance-branch into his maintenance-branch, and also he
> does *not* fast-forward when pulling developer's fix branch into that
> same maintenance-branch of his.

First of all this use-case is not realistic. The moment he merges a
developer branch, hes maintenance and the probject's diverge, and all
the pulls after that cannot be fast-forward.

It's pointless to add something that just doesn't happen. It will be
possible to do the fast-forward merges only early on the life of this
branch, not afterwards. For this short period of time he can just simply
use his fingers to type `git merge --no-ff`.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-01 15:20                 ` Marc Branchaud
  2014-05-01 17:56                   ` W. Trevor King
@ 2014-05-01 19:22                   ` Felipe Contreras
  2014-05-01 19:43                     ` Marc Branchaud
  1 sibling, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-05-01 19:22 UTC (permalink / raw)
  To: Marc Branchaud, Felipe Contreras, Junio C Hamano, Marat Radchenko, git

Marc Branchaud wrote:
> What's more, it seems to me that the only real advantage "git pull"
> provides here is a less typing compared to the non-pull equivalent:
> 
>   git fetch main-repo
>   git checkout main-repo/maintenance-branch
>   git fetch developer-remote
>   git merge --no-ff developer-remote/topic-branch
>   git push main-repo HEAD

You mean `git push main-repo HEAD:maintenance-branch`, right?

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-01  9:46               ` brian m. carlson
  2014-05-01 10:48                 ` Felipe Contreras
  2014-05-01 15:20                 ` Marc Branchaud
@ 2014-05-01 19:27                 ` Felipe Contreras
  2 siblings, 0 replies; 73+ messages in thread
From: Felipe Contreras @ 2014-05-01 19:27 UTC (permalink / raw)
  To: brian m. carlson, Felipe Contreras
  Cc: Marc Branchaud, Junio C Hamano, Marat Radchenko, git

brian m. carlson wrote:
> At work, we have a workflow where we merge topic branches as
> non-fast-forward, so that we have a record of the history (including
> who reviewed the code), but when we want to just update our local
> branches, we always want fast-forward:
> 
>   git checkout maintenance-branch
>   # Update our maintenance branch to the latest from the main repo.
>   git pull --ff-only

If we make it the default, you only need to type `git pull`.

>   git pull --no-ff developer-remote topic-branch

I don't see anything wrong with having to type --no-ff if that's what
you really want.

>   git push main-repo HEAD

main-repo/maintenance-branch should be the upstream of
maintenance-branch, in which hase:

% git push

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-01 19:22                   ` Felipe Contreras
@ 2014-05-01 19:43                     ` Marc Branchaud
  0 siblings, 0 replies; 73+ messages in thread
From: Marc Branchaud @ 2014-05-01 19:43 UTC (permalink / raw)
  To: Felipe Contreras, Junio C Hamano, Marat Radchenko, git

On 14-05-01 03:22 PM, Felipe Contreras wrote:
> Marc Branchaud wrote:
>> What's more, it seems to me that the only real advantage "git pull"
>> provides here is a less typing compared to the non-pull equivalent:
>>
>>   git fetch main-repo
>>   git checkout main-repo/maintenance-branch
>>   git fetch developer-remote
>>   git merge --no-ff developer-remote/topic-branch
>>   git push main-repo HEAD
> 
> You mean `git push main-repo HEAD:maintenance-branch`, right?

Right.  Sorry, for that command I thoughtlessly just copied Brian's example.

		M.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Re: Pull is Evil
  2014-05-01 19:16                     ` Felipe Contreras
@ 2014-05-01 19:48                       ` W. Trevor King
  2014-05-01 20:07                         ` W. Trevor King
  2014-05-01 23:20                         ` Re: Pull is Evil Felipe Contreras
  0 siblings, 2 replies; 73+ messages in thread
From: W. Trevor King @ 2014-05-01 19:48 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 1445 bytes --]

On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote:
> The only problem would be when it's not desirable, however, that's a
> problem of the user's ignorance, and the failure of the project's
> policity to communicate clearly to him that he should be running
> `git merge --no-ff`. There's absolutely nothing we can do to help him.

I think “user ignorange” is the *only* problem with git pull.  Once
you understand the ff flags, you can set them however you like, and
pull will do what you tell it to.

> The only thing we could do is not allow fast-forward merges either, in
> which case `git pull` becomes a no-op that can't possibly do anything
> ever.

My interest in all of the proposed git-pull-training-wheel patches is
that they give users a way to set a finger-breaking configuration that
makes pull a no-op (or slows it down, like 'rm -i …').  Then folks who
compulsively run 'git pull' (e.g. because SVN habits die slowly) can
set an option that gives them something to think about before going
ahead and running the pull anyway.  The space in 'git pull' makes a
shell-side:

  $ alias 'git pull'='echo "try fetch/merge!"'

solution unfeasible, and clobbering /usr/libexec/git-core/git-pull
seems a bit extreme.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Re: Pull is Evil
  2014-05-01 19:48                       ` W. Trevor King
@ 2014-05-01 20:07                         ` W. Trevor King
  2014-05-01 23:25                           ` Felipe Contreras
  2014-05-01 23:20                         ` Re: Pull is Evil Felipe Contreras
  1 sibling, 1 reply; 73+ messages in thread
From: W. Trevor King @ 2014-05-01 20:07 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:
> My interest in all of the proposed git-pull-training-wheel patches is
> that they give users a way to set a finger-breaking configuration that
> makes pull a no-op (or slows it down, like 'rm -i …').  Then folks who
> compulsively run 'git pull' (e.g. because SVN habits die slowly) can
> set an option that gives them something to think about before going
> ahead and running the pull anyway.

Actually, what do we think about an -i/--interactive flag (with an
associated pull.interactive boolean config to setup global/per-repo
defaults)?  Then after the fetch, you'd get one of the following:

  Merge $count commits from $repository $refspec into $current_branch?
  Rebase $count commits from $current_branch onto $repository $refpec?
  Fast-forward $current_branch by $count commits to $repository $refpec?

and have a chance to bail out if you saw:

  Merge 1003 commits from git://example.net/main.git master into my-feature?

because you forgot which branch you were on.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Re: Pull is Evil
  2014-05-01 18:30                       ` W. Trevor King
@ 2014-05-01 20:21                         ` Marc Branchaud
  2014-05-01 23:28                           ` Felipe Contreras
                                             ` (2 more replies)
  0 siblings, 3 replies; 73+ messages in thread
From: Marc Branchaud @ 2014-05-01 20:21 UTC (permalink / raw)
  To: W. Trevor King; +Cc: Felipe Contreras, Junio C Hamano, Marat Radchenko, git

On 14-05-01 02:30 PM, W. Trevor King wrote:
> 
> I find a local branch useful to mark the amount of the upstream branch
> that I've reviewed.  The reflog helps a bit, but I may go several
> fetches between reviews.  For newbies, I recommend avoiding detached
> HEADs, where possible, so they don't have to rely on the reflog if
> they accidentally commit and then checkout something else (ignoring
> Git's warning).

All sound practices that I think are perfectly fine.

I may be mistaken, but I think "git pull" evolved to try to address the
detached-HEAD risk (at least in part).  This risk was pretty real before the
reflog came about (I'm under the impression -- and too lazy to check -- that
"git pull" predates the reflog; please forgive me if I'm mis-perceiving the
timeline).

But these days there's hardly any risk to using a detached HEAD.  Plus
nowadays I think it's commonly accepted that using topic branches is a git
best practice.  The notion of doing work on a generically-named branch like
"maint" seems archaic.

So what benefit does "git pull" provide?

In your particular case, you're using "git pull" to help you track your
reviews of the upstream branch.  To me this seems more like you taking
advantage of a "git pull" side-effect than using the command as it is
intended to be used.  Certainly there are other ways that git can track this
for you.  A simple, aliasable, "git tag -f LastReviewPoint upstream/branch"
seems just as effective to me (but then, I'm not you).

		M.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 19:45       ` Pull is Evil Marc Branchaud
                           ` (2 preceding siblings ...)
  2014-04-30 20:14         ` Felipe Contreras
@ 2014-05-01 21:06         ` Philip Oakley
  2014-05-01 21:16           ` Philip Oakley
  2014-05-01 23:34           ` Felipe Contreras
  3 siblings, 2 replies; 73+ messages in thread
From: Philip Oakley @ 2014-05-01 21:06 UTC (permalink / raw)
  To: git; +Cc: Marat Radchenko, Felipe Contreras, Junio C Hamano, Marc Branchaud

From: "Marc Branchaud" <marcnarc@xiplink.com>
Sent: Wednesday, April 30, 2014 8:45 PM
[...]
> I don't think we'll ever be able to create a One "Git Pull" To Rule 
> Them All.
> At best we'll end up with something with enough knobs that it could be
> configured to work in most workflows (I think we're actually pretty 
> close to
> that).  But for new users that defeats the purpose.  It means that 
> "git pull"
> is really an advanced command, and beginners should avoid it until 
> they
> understand enough of git to configure it properly.
>
> So rather than perpetuate the myth that one command can always (or 
> even just
> usually) do the right thing, let's just retire the command.
>
> All that said, I don't object to any attempts at improving the command
> either.  But I also don't see any kind of improvement that would lead 
> me to
> start using "git pull" let alone recommending it to new users.
>
> M.
>
> [1] By "significant" I mean "enough to perpetually create new mailing 
> list
> threads about changing 'git pull'".
>
[general reply to all, rather than to anyone in particular, using Marc's 
summary]

The point that there is no easy solution to an updated default pull 
action that is right for everybody, straight out of the box, I think is 
now fairly obvious, a summarised by Marc. I certainly avoid pull.

My 'solution', if it could be called that, would be that at the point of 
switch over, after a period of release note warning and then code 
warning, that the plain 'git pull' would not even do the no-ff, but 
would simply refuse to do anything unless the user had explicitly set 
the [new] config variable(s) to a value of _their_ choice. The message 
could give guidance based on their old setting(s) and the new options as 
appropriate, i.e. if they have an old definitive setting then the new 
setting may be an obvious one.

During the warning period between the release cycles, we may have a two 
step ramp up of the warning, where the first cycle allows users who have 
read the release notes to choose their new setting and it's auto 
detected from there on, then in the second cycle Git detects the lack of 
a setting and gives a warning prompt (just like the Git 2.0 warning), 
and finally the change over release makes a 'git pull' without a config 
setting an error.

I know that for some it's a phaff that appears to waste time (been 
there, been that person), but it does allow the stragglers time to pick 
up the hints and not be too surprised, which will include many otherwise 
professional folks who just happen to have other priorities [e.g. this 
message typed from a Win XP machine!].

The approach does have a solid heritage, and avoids anyone (on the 
coding side) having to decide on an initial default, when it should be a 
user choice. Though I do agree with Filipe that the '--no-ff merge' 
would probably be the least worst for the new user and likely be a 
suitable 'if you don't know use this one' suggestion.

Philip
-- 

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-01 21:06         ` Philip Oakley
@ 2014-05-01 21:16           ` Philip Oakley
  2014-05-01 23:34           ` Felipe Contreras
  1 sibling, 0 replies; 73+ messages in thread
From: Philip Oakley @ 2014-05-01 21:16 UTC (permalink / raw)
  To: git; +Cc: Marat Radchenko, Felipe Contreras, Junio C Hamano, Marc Branchaud

Oops..
From: "Philip Oakley" <philipoakley@iee.org>
> From: "Marc Branchaud" <marcnarc@xiplink.com>
> Sent: Wednesday, April 30, 2014 8:45 PM
> [...]
>> I don't think we'll ever be able to create a One "Git Pull" To Rule 
>> Them All.
>> At best we'll end up with something with enough knobs that it could 
>> be
>> configured to work in most workflows (I think we're actually pretty 
>> close to
>> that).  But for new users that defeats the purpose.  It means that 
>> "git pull"
>> is really an advanced command, and beginners should avoid it until 
>> they
>> understand enough of git to configure it properly.
>>
>> So rather than perpetuate the myth that one command can always (or 
>> even just
>> usually) do the right thing, let's just retire the command.
>>
>> All that said, I don't object to any attempts at improving the 
>> command
>> either.  But I also don't see any kind of improvement that would lead 
>> me to
>> start using "git pull" let alone recommending it to new users.
>>
>> M.
>>
>> [1] By "significant" I mean "enough to perpetually create new mailing 
>> list
>> threads about changing 'git pull'".
>>
> [general reply to all, rather than to anyone in particular, using 
> Marc's summary]
>
> The point that there is no easy solution to an updated default pull 
> action that is right for everybody, straight out of the box, I think 
> is now fairly obvious, a summarised by Marc. I certainly avoid pull.
>
> My 'solution', if it could be called that, would be that at the point 
> of switch over, after a period of release note warning and then code 
> warning, that the plain 'git pull' would not even do the no-ff, but

s/no-ff/--ff/g that is, only 'merge' if it's a fast forward.

> would simply refuse to do anything unless the user had explicitly set 
> the [new] config variable(s) to a value of _their_ choice. The message 
> could give guidance based on their old setting(s) and the new options 
> as appropriate, i.e. if they have an old definitive setting then the 
> new setting may be an obvious one.
>
> During the warning period between the release cycles, we may have a 
> two step ramp up of the warning, where the first cycle allows users 
> who have read the release notes to choose their new setting and it's 
> auto detected from there on, then in the second cycle Git detects the 
> lack of a setting and gives a warning prompt (just like the Git 2.0 
> warning), and finally the change over release makes a 'git pull' 
> without a config setting an error.
>
> I know that for some it's a phaff that appears to waste time (been 
> there, been that person), but it does allow the stragglers time to 
> pick up the hints and not be too surprised, which will include many 
> otherwise professional folks who just happen to have other priorities 
> [e.g. this message typed from a Win XP machine!].
>
> The approach does have a solid heritage, and avoids anyone (on the 
> coding side) having to decide on an initial default, when it should be 
> a user choice. Though I do agree with Filipe that the '--no-ff merge'

s/no-ff/--ff/

> would probably be the least worst for the new user and likely be a 
> suitable 'if you don't know use this one' suggestion.
>
> Philip
> -- 
sorry for the finger-brain failures. 

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Re: Pull is Evil
  2014-05-01 19:48                       ` W. Trevor King
  2014-05-01 20:07                         ` W. Trevor King
@ 2014-05-01 23:20                         ` Felipe Contreras
  1 sibling, 0 replies; 73+ messages in thread
From: Felipe Contreras @ 2014-05-01 23:20 UTC (permalink / raw)
  To: W. Trevor King, Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

W. Trevor King wrote:
> On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote:
> > The only problem would be when it's not desirable, however, that's a
> > problem of the user's ignorance, and the failure of the project's
> > policity to communicate clearly to him that he should be running
> > `git merge --no-ff`. There's absolutely nothing we can do to help him.
> 
> I think “user ignorange” is the *only* problem with git pull.

That, and the fact that 'git pull' does something wrong by default.

> > The only thing we could do is not allow fast-forward merges either, in
> > which case `git pull` becomes a no-op that can't possibly do anything
> > ever.
> 
> My interest in all of the proposed git-pull-training-wheel patches is
> that they give users a way to set a finger-breaking configuration that
> makes pull a no-op (or slows it down, like 'rm -i …').  Then folks who
> compulsively run 'git pull' (e.g. because SVN habits die slowly) can
> set an option that gives them something to think about before going
> ahead and running the pull anyway.  The space in 'git pull' makes a
> shell-side:
> 
>   $ alias 'git pull'='echo "try fetch/merge!"'
> 
> solution unfeasible, and clobbering /usr/libexec/git-core/git-pull
> seems a bit extreme.

What is wrong with 'git pull' doing a merge when it can be fast-forward?

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Re: Pull is Evil
  2014-05-01 20:07                         ` W. Trevor King
@ 2014-05-01 23:25                           ` Felipe Contreras
  2014-05-02  0:02                             ` W. Trevor King
  0 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-05-01 23:25 UTC (permalink / raw)
  To: W. Trevor King, Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

W. Trevor King wrote:
> On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:
> > My interest in all of the proposed git-pull-training-wheel patches is
> > that they give users a way to set a finger-breaking configuration that
> > makes pull a no-op (or slows it down, like 'rm -i …').  Then folks who
> > compulsively run 'git pull' (e.g. because SVN habits die slowly) can
> > set an option that gives them something to think about before going
> > ahead and running the pull anyway.
> 
> Actually, what do we think about an -i/--interactive flag (with an
> associated pull.interactive boolean config to setup global/per-repo
> defaults)?  Then after the fetch, you'd get one of the following:
> 
>   Merge $count commits from $repository $refspec into $current_branch?
>   Rebase $count commits from $current_branch onto $repository $refpec?

Not much interactivity in those options. Maybe --prompt would make more
sense.

>   Fast-forward $current_branch by $count commits to $repository $refpec?

Why would anyone say 'no' to this one?

But your wording made me realize that my proposed option 'merge-ff-only'
is not appropriate, because in theroy the user can think about it as
'rebase-ff-only'; in other words, a 'fast-forward' is not really a
merge, and not really a rebase.

> and have a chance to bail out if you saw:
> 
>   Merge 1003 commits from git://example.net/main.git master into my-feature?
> 
> because you forgot which branch you were on.

Yes, that might be nice. But we still need to change the defaults.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Re: Pull is Evil
  2014-05-01 20:21                         ` Marc Branchaud
@ 2014-05-01 23:28                           ` Felipe Contreras
  2014-05-02  7:16                           ` Andreas Krey
  2014-05-02 19:29                           ` Junio C Hamano
  2 siblings, 0 replies; 73+ messages in thread
From: Felipe Contreras @ 2014-05-01 23:28 UTC (permalink / raw)
  To: Marc Branchaud, W. Trevor King
  Cc: Felipe Contreras, Junio C Hamano, Marat Radchenko, git

Marc Branchaud wrote:
> So what benefit does "git pull" provide?

The same that 'hg update' provies: a way for the user fetch/pull the
latest changes and check them out into the working directory.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-01 21:06         ` Philip Oakley
  2014-05-01 21:16           ` Philip Oakley
@ 2014-05-01 23:34           ` Felipe Contreras
  2014-05-01 23:59             ` W. Trevor King
  1 sibling, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-05-01 23:34 UTC (permalink / raw)
  To: Philip Oakley, git
  Cc: Marat Radchenko, Felipe Contreras, Junio C Hamano, Marc Branchaud

Philip Oakley wrote:
> The point that there is no easy solution to an updated default pull 
> action that is right for everybody, straight out of the box, I think is 
> now fairly obvious, a summarised by Marc. I certainly avoid pull.

Yes, I avoid it too, and quite a lot of people.

> My 'solution', if it could be called that, would be that at the point of 
> switch over, after a period of release note warning and then code 
> warning, that the plain 'git pull' would not even do the no-ff, but 
> would simply refuse to do anything...

I still haven't heard a single argument why a fast-forward by default
wouldn't be desirable.

Remember that we are talking about inexperienced users here. Experienced
users can simply do `git pull --no-ff` or do the right configuration.

The problem we want to track is newcomers doing merges (real ones) by
mistake.

Nobody ever complained about somebody doing a fast-forward by mistake.

I think a non-fast-forward warning by default, and eventually rejecting
them is the most sensible approach.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Re: Pull is Evil
  2014-05-01 23:45                       ` brian m. carlson
@ 2014-05-01 23:39                         ` Felipe Contreras
  0 siblings, 0 replies; 73+ messages in thread
From: Felipe Contreras @ 2014-05-01 23:39 UTC (permalink / raw)
  To: brian m. carlson, Marc Branchaud
  Cc: W. Trevor King, Felipe Contreras, Junio C Hamano, Marat Radchenko, git

brian m. carlson wrote:
> I just used this to illustrate the fact that there isn't actually one
> completely correct case with pull.

Nobody is arguing otherwise. The argument is that `git pull` by default
can be made more sensible.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Re: Pull is Evil
  2014-05-01 18:04                     ` Marc Branchaud
  2014-05-01 18:30                       ` W. Trevor King
@ 2014-05-01 23:45                       ` brian m. carlson
  2014-05-01 23:39                         ` Felipe Contreras
  1 sibling, 1 reply; 73+ messages in thread
From: brian m. carlson @ 2014-05-01 23:45 UTC (permalink / raw)
  To: Marc Branchaud
  Cc: W. Trevor King, Felipe Contreras, Junio C Hamano, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 2500 bytes --]

On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote:
> On 14-05-01 01:56 PM, W. Trevor King wrote:
> > On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
> >> On 14-05-01 05:46 AM, brian m. carlson wrote:
> >>>   git checkout maintenance-branch
> >>>   # Update our maintenance branch to the latest from the main repo.
> >>>   git pull --ff-only
> >>>   git pull --no-ff developer-remote topic-branch
> >>>   git push main-repo HEAD
> >>
> >> …
> >> What's more, it seems to me that the only real advantage "git pull" provides
> >> here is a less typing compared to the non-pull equivalent:
> >>
> >>   git fetch main-repo
> >>   git checkout main-repo/maintenance-branch
> >>   git fetch developer-remote
> >>   git merge --no-ff developer-remote/topic-branch
> >>   git push main-repo HEAD
> > 
> > You're missing Brian's fast-forward merge here.  It should be:
> > 
> >   git checkout maintenance-branch
> >   git fetch main-repo
> >   git merge --ff-only main-repo/maintenance-branch
> >   git fetch developer-remote
> >   …
> 
> I think you're mistaken -- I checked out "main-repo/maintenance-branch"
> directly, so there's no need to fast-forward a local branch.

I actually need my local copy to be up-to-date.  Part of my workflow,
which I omitted for the sake of brevity, is running scripts that rely on
my local branch's name, format, and contents.

My use case is that I'm one of several code reviewers, and I update my
branch, merge in another developer's changes, review them, and then push
them if they're good.  I need to pull from the main repo immediately
before merging, to minimize the chances that someone else will have
pushed before me, which would result in me having to redo the merge
(because the push has to be fast-forward).

I just used this to illustrate the fact that there isn't actually one
completely correct case with pull.  I have aliases for pull (and merge)
--ff-only and --no-ff, and I never actually use plain git pull unless I
really don't care whether or not it's a fast-forward.  So I'm okay with
the status quo because I have distinct choices for merge, no merge, and
don't care.  I don't really have a strong opinion, though, as long as
those three options remain.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-01 23:34           ` Felipe Contreras
@ 2014-05-01 23:59             ` W. Trevor King
  2014-05-02  0:31               ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: W. Trevor King @ 2014-05-01 23:59 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Philip Oakley, git, Marat Radchenko, Junio C Hamano, Marc Branchaud

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote:
> Nobody ever complained about somebody doing a fast-forward by mistake.

Unless they fast-forward merged a feature branch into master, but the
project prefers explicitly-merged feature branches with a cover-letter
explaination in the merge commit [1].  On the one hand, folks
integrating feature branches are likely more experienced Git users.
On the other hand, I know several project maintainers who integrate
feature branches that are pull-happy.

I agree that accidental ff-merges are likely to be less troublesome
than accidental non-ff merge/rebases, but I don't think changing the
default to ff-only is a perfect fix.

Cheers,
Trevor

[1]: http://article.gmane.org/gmane.comp.version-control.git/247807

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Re: Pull is Evil
  2014-05-01 23:25                           ` Felipe Contreras
@ 2014-05-02  0:02                             ` W. Trevor King
  2014-05-02  0:37                               ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: W. Trevor King @ 2014-05-02  0:02 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 1847 bytes --]

On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:
> > > My interest in all of the proposed git-pull-training-wheel patches is
> > > that they give users a way to set a finger-breaking configuration that
> > > makes pull a no-op (or slows it down, like 'rm -i …').  Then folks who
> > > compulsively run 'git pull' (e.g. because SVN habits die slowly) can
> > > set an option that gives them something to think about before going
> > > ahead and running the pull anyway.
> > 
> > Actually, what do we think about an -i/--interactive flag (with an
> > associated pull.interactive boolean config to setup global/per-repo
> > defaults)?  Then after the fetch, you'd get one of the following:
> > 
> >   Merge $count commits from $repository $refspec into $current_branch?
> >   Rebase $count commits from $current_branch onto $repository $refpec?
> 
> Not much interactivity in those options. Maybe --prompt would make more
> sense.

I think matching rm, mv, cp, etc. is good, but I'd be ok with
--prompt.

> >   Fast-forward $current_branch by $count commits to $repository $refpec?
> 
> Why would anyone say 'no' to this one?

Because the want explicit merges when they bring in topic branches?

> > and have a chance to bail out if you saw:
> > 
> >   Merge 1003 commits from git://example.net/main.git master into my-feature?
> > 
> > because you forgot which branch you were on.
> 
> Yes, that might be nice. But we still need to change the defaults.

So I should submit an orthogonal patch with -i/--interative/--prompt?

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-01 23:59             ` W. Trevor King
@ 2014-05-02  0:31               ` Felipe Contreras
  0 siblings, 0 replies; 73+ messages in thread
From: Felipe Contreras @ 2014-05-02  0:31 UTC (permalink / raw)
  To: W. Trevor King, Felipe Contreras
  Cc: Philip Oakley, git, Marat Radchenko, Junio C Hamano, Marc Branchaud

W. Trevor King wrote:
> On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote:
> > Nobody ever complained about somebody doing a fast-forward by mistake.
> 
> Unless they fast-forward merged a feature branch into master, but the
> project prefers explicitly-merged feature branches with a cover-letter
> explaination in the merge commit [1].  On the one hand, folks
> integrating feature branches are likely more experienced Git users.

Exactly. That's barely an issue.

> I agree that accidental ff-merges are likely to be less troublesome
> than accidental non-ff merge/rebases, but I don't think changing the
> default to ff-only is a perfect fix.

I don't see what else we could do.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Re: Pull is Evil
  2014-05-02  0:02                             ` W. Trevor King
@ 2014-05-02  0:37                               ` Felipe Contreras
  2014-05-02  1:10                                 ` W. Trevor King
  0 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-05-02  0:37 UTC (permalink / raw)
  To: W. Trevor King, Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

W. Trevor King wrote:
> On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote:
> > W. Trevor King wrote:
> > > On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:
> > > > My interest in all of the proposed git-pull-training-wheel patches is
> > > > that they give users a way to set a finger-breaking configuration that
> > > > makes pull a no-op (or slows it down, like 'rm -i …').  Then folks who
> > > > compulsively run 'git pull' (e.g. because SVN habits die slowly) can
> > > > set an option that gives them something to think about before going
> > > > ahead and running the pull anyway.
> > > 
> > > Actually, what do we think about an -i/--interactive flag (with an
> > > associated pull.interactive boolean config to setup global/per-repo
> > > defaults)?  Then after the fetch, you'd get one of the following:
> > > 
> > >   Merge $count commits from $repository $refspec into $current_branch?
> > >   Rebase $count commits from $current_branch onto $repository $refpec?
> > 
> > Not much interactivity in those options. Maybe --prompt would make more
> > sense.
> 
> I think matching rm, mv, cp, etc. is good, but I'd be ok with
> --prompt.

Those are actually interactive. `git mergetool --prompt` is an exactly
of a configration where it's interactivity is constrainted to a single
input.

> > >   Fast-forward $current_branch by $count commits to $repository $refpec?
> > 
> > Why would anyone say 'no' to this one?
> 
> Because the want explicit merges when they bring in topic branches?

If that was the case the user wouls have run `git merge --no-ff`. Only
expereinced users would answer 'no'.

> > > and have a chance to bail out if you saw:
> > > 
> > >   Merge 1003 commits from git://example.net/main.git master into my-feature?
> > > 
> > > because you forgot which branch you were on.
> > 
> > Yes, that might be nice. But we still need to change the defaults.
> 
> So I should submit an orthogonal patch with -i/--interative/--prompt?

I'm not entirely sure what would be the ideal behavior.

For example, I'm thinking that by default when the a fast-forward is
possible, just do it, when it's not, ask if the user wants to do a merge
or a rebase, if the user just press 'enter' a merge is attempted.

In addition a summary of the commits ahead behind would be helpful.

If the user wants to cancel the operation, he can just do CTRL+C.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02  0:37                               ` Felipe Contreras
@ 2014-05-02  1:10                                 ` W. Trevor King
  2014-05-02  1:14                                   ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: W. Trevor King @ 2014-05-02  1:10 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 2314 bytes --]

On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > Fast-forward $current_branch by $count commits to $repository
> > > > $refpec?
> > > 
> > > Why would anyone say 'no' to this one?
> > 
> > Because the want explicit merges when they bring in topic
> > branches?
> 
> If that was the case the user wouls have run `git merge
> --no-ff`. Only expereinced users would answer 'no'.

Folks who are setting any ff options don't need any of these training
wheels.  My proposed --prompt behavior is for folks who think “I often
run this command without thinking it through all the way.  I'm also
not used to reading Git's output and using 'reset --hard' with the
reflog to reverse changes.  Instead of trusting me to only say what I
mean or leaving me to recover from mistakes, please tell me what's
about to change and let me opt out if I've changed my mind.”

> > > > and have a chance to bail out if you saw:
> > > > 
> > > >   Merge 1003 commits from git://example.net/main.git master into my-feature?
> > > > 
> > > > because you forgot which branch you were on.
> > > 
> > > Yes, that might be nice. But we still need to change the defaults.
> > 
> > So I should submit an orthogonal patch with -i/--interative/--prompt?
> 
> I'm not entirely sure what would be the ideal behavior.
> 
> For example, I'm thinking that by default when the a fast-forward is
> possible, just do it, …

But just because a ff is possible doesn't mean it's what the
user/project wants.  It may be the most likely guess, but why guess
when they've explicitly asked for a prompt?

> when it's not, ask if the user wants to do a merge or a rebase, if
> the user just press 'enter' a merge is attempted.

I'll just mimic however mergetool currently handles prompt
accept/decline.

> In addition a summary of the commits ahead behind would be helpful.

Good idea.

> If the user wants to cancel the operation, he can just do CTRL+C.

I'll just mimic mergetool.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02  1:10                                 ` W. Trevor King
@ 2014-05-02  1:14                                   ` Felipe Contreras
  2014-05-02 14:54                                     ` W. Trevor King
  0 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-05-02  1:14 UTC (permalink / raw)
  To: W. Trevor King, Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

W. Trevor King wrote:
> On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote:
> > If that was the case the user wouls have run `git merge
> > --no-ff`. Only expereinced users would answer 'no'.
> 
> Folks who are setting any ff options don't need any of these training
> wheels.

Indeed.

> My proposed --prompt behavior is for folks who think “I often run this
> command without thinking it through all the way.  I'm also not used to
> reading Git's output and using 'reset --hard' with the reflog to
> reverse changes.  Instead of trusting me to only say what I mean or
> leaving me to recover from mistakes, please tell me what's about to
> change and let me opt out if I've changed my mind.”

Unfortunately those folks by definition wouldn't know about the --prompt
option.

> > For example, I'm thinking that by default when the a fast-forward is
> > possible, just do it, …
> 
> But just because a ff is possible doesn't mean it's what the
> user/project wants.

Yeah, so? We cannot read minds, especially not the minds of the people
that are not sitted in from of the computer.

> It may be the most likely guess, but why guess when they've explicitly
> asked for a prompt?

*If* the user has specifically asked for a prompt, sure, ask. But I'm
not particularly interested in that, because I'm certain very very few
people would use --prompt.

I'm interested in the defaults.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-01 20:21                         ` Marc Branchaud
  2014-05-01 23:28                           ` Felipe Contreras
@ 2014-05-02  7:16                           ` Andreas Krey
  2014-05-02  8:14                             ` Felipe Contreras
  2014-05-02 19:29                           ` Junio C Hamano
  2 siblings, 1 reply; 73+ messages in thread
From: Andreas Krey @ 2014-05-02  7:16 UTC (permalink / raw)
  To: Marc Branchaud
  Cc: W. Trevor King, Felipe Contreras, Junio C Hamano, Marat Radchenko, git

On Thu, 01 May 2014 16:21:42 +0000, Marc Branchaud wrote:
...
> 
> But these days there's hardly any risk to using a detached HEAD.  Plus
> nowadays I think it's commonly accepted that using topic branches is a git
> best practice.  The notion of doing work on a generically-named branch like
> "maint" seems archaic.
> 
> So what benefit does "git pull" provide?

It provides the moral equivalent of 'cvs update', 'svn update', and
'clearcase <do nothing>'.

Even when I'm on a feature branch, there are cases where I have that branch
as the current one in multiple repos (on different machines because testing),
or multiple people working on that branch. A 'git pull' is the obvious way
to get divergent branches back together.

In cvs&svn a local workspace can't ever be more than half a commit ahead,
and what an 'update' does is most similar to a rebase in git. But I'm
not eager to teach this future userbase rebases, and also a rebase loses
expensive test results that are tied to the commit ids.

My personal beef with 'git pull' is still that sometimes (namely in the
'git pull && git push' sequence) it should reverse the order of the
parents in the merge commit, so that *my* commits look like an
integrated topic branch, instead of the former mainline.

Unfortunately the answers to the question "what to do instead of 'git
pull'" are, in increasing order of teaching needed:

- Ok, just 'git pull' <sigh>.

- Please do a 'git pull --rebase'; I'll show you how.

- <Something involving switching branches and doing the
   merge in the other direction>

(I'm coming from a 'blessed repo where everybody pushes to' setup,
and we're considering a server trigger that refuses pushes where
the previous head is not a *first* parent of the new head, in order
not to accidentally mess up the mainline.)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-04-30 20:01         ` Junio C Hamano
  2014-04-30 21:48           ` Marc Branchaud
@ 2014-05-02  7:40           ` Andreas Krey
  2014-05-02  8:46             ` David Kastrup
  1 sibling, 1 reply; 73+ messages in thread
From: Andreas Krey @ 2014-05-02  7:40 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Marc Branchaud, Marat Radchenko, git

On Wed, 30 Apr 2014 13:01:49 +0000, Junio C Hamano wrote:
...
> I didn't mean "replace 'pull' with 'update' everywhere".  I meant
> "Introduce 'update' that lets integrate your history into that from
> the remote, which is to integrate in a direction opposite from how
> 'pull' does".  

That still doesn't quite solve my problem. If I'm tracking origin/master
in a local master branch, I can just use 'git pull' to get my 'feature'
branch (which is named master) updated to the current state of the origin.
This amounts to 'integrating' origin/master into my master.

When I finally want to deliver and push to origin/master, I put on the
integrator's hat, and I cat do a 'git update' that will do the merge
in reverse, and push the result to origin/master. The result will look
like origin pulled my master branch into his.

Problem is that whether to use pull or update depends on whether I
intend to push afterwards; and additionally, if I can push fast-forward
without needing to 'git update' the integration into origin/master will
look weird.

(Oh, and please don't name it 'update' - we have an important alias
of that name.)

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02  7:16                           ` Andreas Krey
@ 2014-05-02  8:14                             ` Felipe Contreras
  0 siblings, 0 replies; 73+ messages in thread
From: Felipe Contreras @ 2014-05-02  8:14 UTC (permalink / raw)
  To: Andreas Krey, Marc Branchaud
  Cc: W. Trevor King, Felipe Contreras, Junio C Hamano, Marat Radchenko, git

Andreas Krey wrote:
> My personal beef with 'git pull' is still that sometimes (namely in
> the 'git pull && git push' sequence) it should reverse the order of
> the parents in the merge commit, so that *my* commits look like an
> integrated topic branch, instead of the former mainline.

I haven't really thought much about this but it does make sense. How
about changing the behavior so `git pull` by default changes the order
of the parents, but `git pull repo branch` doesn't.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02  7:40           ` Andreas Krey
@ 2014-05-02  8:46             ` David Kastrup
  2014-05-03  6:17               ` Andreas Krey
  0 siblings, 1 reply; 73+ messages in thread
From: David Kastrup @ 2014-05-02  8:46 UTC (permalink / raw)
  To: git

Andreas Krey <a.krey@gmx.de> writes:

> On Wed, 30 Apr 2014 13:01:49 +0000, Junio C Hamano wrote:
> ...
>> I didn't mean "replace 'pull' with 'update' everywhere".  I meant
>> "Introduce 'update' that lets integrate your history into that from
>> the remote, which is to integrate in a direction opposite from how
>> 'pull' does".  
>
> That still doesn't quite solve my problem. If I'm tracking origin/master
> in a local master branch, I can just use 'git pull' to get my 'feature'
> branch (which is named master) updated to the current state of the origin.
> This amounts to 'integrating' origin/master into my master.

This discussion makes as much sense to me as debating whether "git
fiddle" should, in case a simple "git hammer" does not apply, should
translate to an implied "git screwdriver", and when it does, whether
more people's workflows involve turning a screw left rather than right
by default.

What the gibbins?  I don't even use git pull.  I use git fetch, and
then, depending on my needs, I rebase or merge.  git pull is not part of
my workflow exactly because it does non-connected things not translating
unambiguously to a particular identifiable workflow.  It might
sometimes, more by accident than design, do what I would have done
anyway.  But I prefer making that choice on my own, depending on the
particular circumstances.

-- 
David Kastrup

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02  1:14                                   ` Felipe Contreras
@ 2014-05-02 14:54                                     ` W. Trevor King
  2014-05-02 18:55                                       ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: W. Trevor King @ 2014-05-02 14:54 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > My proposed --prompt behavior is for folks who think “I often run
> > this command without thinking it through all the way.  I'm also
> > not used to reading Git's output and using 'reset --hard' with the
> > reflog to reverse changes.  Instead of trusting me to only say
> > what I mean or leaving me to recover from mistakes, please tell me
> > what's about to change and let me opt out if I've changed my
> > mind.”
> 
> Unfortunately those folks by definition wouldn't know about the
> --prompt option.

But once such folks are identified, you just have to convince them
(once) to set the pull.prompt config.  That's a lot easier than
convincing them (for every pull) to set the appropriate ff flag.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02 14:54                                     ` W. Trevor King
@ 2014-05-02 18:55                                       ` Felipe Contreras
  2014-05-02 19:07                                         ` W. Trevor King
  0 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-05-02 18:55 UTC (permalink / raw)
  To: W. Trevor King, Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

W. Trevor King wrote:
> On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
> > W. Trevor King wrote:
> > > My proposed --prompt behavior is for folks who think “I often run
> > > this command without thinking it through all the way.  I'm also
> > > not used to reading Git's output and using 'reset --hard' with the
> > > reflog to reverse changes.  Instead of trusting me to only say
> > > what I mean or leaving me to recover from mistakes, please tell me
> > > what's about to change and let me opt out if I've changed my
> > > mind.”
> > 
> > Unfortunately those folks by definition wouldn't know about the
> > --prompt option.
> 
> But once such folks are identified, you just have to convince them
> (once) to set the pull.prompt config.  That's a lot easier than
> convincing them (for every pull) to set the appropriate ff flag.

It wouldn't matter if by the default non-fast-forward merges are
rejected.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02 18:55                                       ` Felipe Contreras
@ 2014-05-02 19:07                                         ` W. Trevor King
  2014-05-02 19:10                                           ` David Kastrup
  2014-05-02 19:13                                           ` Felipe Contreras
  0 siblings, 2 replies; 73+ messages in thread
From: W. Trevor King @ 2014-05-02 19:07 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > My proposed --prompt behavior is for folks who think “I often run
> > > > this command without thinking it through all the way.  I'm also
> > > > not used to reading Git's output and using 'reset --hard' with the
> > > > reflog to reverse changes.  Instead of trusting me to only say
> > > > what I mean or leaving me to recover from mistakes, please tell me
> > > > what's about to change and let me opt out if I've changed my
> > > > mind.”
> > > 
> > > Unfortunately those folks by definition wouldn't know about the
> > > --prompt option.
> > 
> > But once such folks are identified, you just have to convince them
> > (once) to set the pull.prompt config.  That's a lot easier than
> > convincing them (for every pull) to set the appropriate ff flag.
> 
> It wouldn't matter if by the default non-fast-forward merges are
> rejected.

It would matter if you didn't want them making non-fast-forward merges
(e.g. for explicitly-merged topic branches).

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02 19:07                                         ` W. Trevor King
@ 2014-05-02 19:10                                           ` David Kastrup
  2014-05-02 19:13                                           ` Felipe Contreras
  1 sibling, 0 replies; 73+ messages in thread
From: David Kastrup @ 2014-05-02 19:10 UTC (permalink / raw)
  To: git

"W. Trevor King" <wking@tremily.us> writes:

> On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
>> W. Trevor King wrote:
>> > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
>> > > W. Trevor King wrote:
>> > > > My proposed --prompt behavior is for folks who think “I often run
>> > > > this command without thinking it through all the way.  I'm also
>> > > > not used to reading Git's output and using 'reset --hard' with the
>> > > > reflog to reverse changes.  Instead of trusting me to only say
>> > > > what I mean or leaving me to recover from mistakes, please tell me
>> > > > what's about to change and let me opt out if I've changed my
>> > > > mind.”
>> > > 
>> > > Unfortunately those folks by definition wouldn't know about the
>> > > --prompt option.
>> > 
>> > But once such folks are identified, you just have to convince them
>> > (once) to set the pull.prompt config.  That's a lot easier than
>> > convincing them (for every pull) to set the appropriate ff flag.
>> 
>> It wouldn't matter if by the default non-fast-forward merges are
>> rejected.
>
> It would matter if you didn't want them making non-fast-forward merges
> (e.g. for explicitly-merged topic branches).

s/didn't want/only wanted/

-- 
David Kastrup

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02 19:07                                         ` W. Trevor King
  2014-05-02 19:10                                           ` David Kastrup
@ 2014-05-02 19:13                                           ` Felipe Contreras
  2014-05-02 19:46                                             ` W. Trevor King
  1 sibling, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-05-02 19:13 UTC (permalink / raw)
  To: W. Trevor King, Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

W. Trevor King wrote:
> On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
> > W. Trevor King wrote:
> > > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
> > > > W. Trevor King wrote:
> > > > > My proposed --prompt behavior is for folks who think “I often run
> > > > > this command without thinking it through all the way.  I'm also
> > > > > not used to reading Git's output and using 'reset --hard' with the
> > > > > reflog to reverse changes.  Instead of trusting me to only say
> > > > > what I mean or leaving me to recover from mistakes, please tell me
> > > > > what's about to change and let me opt out if I've changed my
> > > > > mind.”
> > > > 
> > > > Unfortunately those folks by definition wouldn't know about the
> > > > --prompt option.
> > > 
> > > But once such folks are identified, you just have to convince them
> > > (once) to set the pull.prompt config.  That's a lot easier than
> > > convincing them (for every pull) to set the appropriate ff flag.
> > 
> > It wouldn't matter if by the default non-fast-forward merges are
> > rejected.
> 
> It would matter if you didn't want them making non-fast-forward merges
> (e.g. for explicitly-merged topic branches).

It would matter almost exactly zero. And just as they can do pull.promot
= true, they can do pull.mode = fetch-only.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-01 20:21                         ` Marc Branchaud
  2014-05-01 23:28                           ` Felipe Contreras
  2014-05-02  7:16                           ` Andreas Krey
@ 2014-05-02 19:29                           ` Junio C Hamano
  2014-05-02 19:53                             ` Junio C Hamano
  2 siblings, 1 reply; 73+ messages in thread
From: Junio C Hamano @ 2014-05-02 19:29 UTC (permalink / raw)
  To: Marc Branchaud; +Cc: W. Trevor King, Felipe Contreras, Marat Radchenko, git

Marc Branchaud <marcnarc@xiplink.com> writes:

> I may be mistaken, but I think "git pull" evolved to try to address the
> detached-HEAD risk (at least in part).

You are totally mistaken.

"git pull" was part of the things to make git usable by Linus before
1.0 release, and matches the integrator workflow perfectly well.
The detached HEAD came much much later.

The issue we are discussing with "git pull" is that if a non
integrator does a "git pull" from the upstream, in order to push the
result of integrating the local work with it back to the upstream,
by default "git pull" creates a merge in a direction that is wrong
when seen in the "first-parent chain is the trunk" point of view.

One way to solve that _might_ be to use the detached HEAD as you
illustrated in your long-hand in the thread that had Brian's
example, but that is not even a failed 'git push' recommends to do
to the users, and there was no link between how 'git pull' behaves
and use of detached HEAD at all.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02 19:13                                           ` Felipe Contreras
@ 2014-05-02 19:46                                             ` W. Trevor King
  2014-05-02 20:34                                               ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: W. Trevor King @ 2014-05-02 19:46 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 2333 bytes --]

On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote [1]:
> > On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
> > > > > W. Trevor King wrote:
> > > > > > My proposed --prompt behavior is for folks who think “I often run
> > > > > > this command without thinking it through all the way.  I'm also
> > > > > > not used to reading Git's output and using 'reset --hard' with the
> > > > > > reflog to reverse changes.  Instead of trusting me to only say
> > > > > > what I mean or leaving me to recover from mistakes, please tell me
> > > > > > what's about to change and let me opt out if I've changed my
> > > > > > mind.”
> > > > > 
> > > > > Unfortunately those folks by definition wouldn't know about the
> > > > > --prompt option.
> > > > 
> > > > But once such folks are identified, you just have to convince them
> > > > (once) to set the pull.prompt config.  That's a lot easier than
> > > > convincing them (for every pull) to set the appropriate ff flag.
> > > 
> > > It wouldn't matter if by the default non-fast-forward merges are
> > > rejected.
> > 
> > It would matter if you [only wanted] them making non-fast-forward
> > merges (e.g. for explicitly-merged topic branches).
> 
> It would matter almost exactly zero.

Some folks have explicit merge policies, and deciding how much that
matters is probably best left up to the projects themselves and not
decided in Git code.  I like having a place to explain why a feature
is useful and has been included in projects I maintain.

> And just as they can do pull.promot = true, they can do pull.mode =
> fetch-only.

Why would you run a fetch-only pull instead of running 'git fetch'?  I
think it would make more sense to have 'pull.mode = none' with which
'git pull …' turns into a no-op suggesting an explicit
fetch/{merge|rebase}.  Having something like that available would
help with the training issue that pull.prompt was addressing.

Cheers,
Trevor

[1]: With David Kastrup's "only wanted" typo fix.

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02 19:29                           ` Junio C Hamano
@ 2014-05-02 19:53                             ` Junio C Hamano
  0 siblings, 0 replies; 73+ messages in thread
From: Junio C Hamano @ 2014-05-02 19:53 UTC (permalink / raw)
  To: Marc Branchaud; +Cc: W. Trevor King, Felipe Contreras, Marat Radchenko, git

Junio C Hamano <gitster@pobox.com> writes:

> Marc Branchaud <marcnarc@xiplink.com> writes:
>
>> I may be mistaken, but I think "git pull" evolved to try to address the
>> detached-HEAD risk (at least in part).
>
> You are totally mistaken.
>
> "git pull" was part of the things to make git usable by Linus before
> 1.0 release, and matches the integrator workflow perfectly well.
> The detached HEAD came much much later.
>
> The issue we are discussing with "git pull" is that if a non
> integrator does a "git pull" from the upstream, in order to push the
> result of integrating the local work with it back to the upstream,
> by default "git pull" creates a merge in a direction that is wrong
> when seen in the "first-parent chain is the trunk" point of view.
>
> One way to solve that _might_ be to use the detached HEAD as you
> illustrated in your long-hand in the thread that had Brian's
> example, but that is not even a failed 'git push' recommends to do
> to the users, and there was no link between how 'git pull' behaves
> and use of detached HEAD at all.

One other thing to keep in mind is that the "first-parent" view
itself is fairly new, compared to "git pull" (and it is even newer
than detached HEAD IIRC, but I do not think detached HEAD has much
to do with the current "'git pull' is often harmful" confusion,
except that it may be one ingredient for a possible solution).

Back when we started "A simple CVS/SVN like workflow can be done by
cycles of 'git pull', do your work, 'git push'", the order of
parents in resulting merges was not an issue.

I am only saying these to give people the historical background to
discuss a possible solution.  I am not saying that it is a possible
solution to discourage the "first-parent chain is the mainline of
the development" world view.

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02 19:46                                             ` W. Trevor King
@ 2014-05-02 20:34                                               ` Felipe Contreras
  2014-05-02 21:13                                                 ` W. Trevor King
  0 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-05-02 20:34 UTC (permalink / raw)
  To: W. Trevor King, Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

W. Trevor King wrote:
> On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> > It would matter almost exactly zero.
> 
> Some folks have explicit merge policies, and deciding how much that
> matters is probably best left up to the projects themselves and not
> decided in Git code.

Let's make some fake numbers to see around how much this would matter.
The amount of people that are not used to Git could be around 60%.

Of these, the amount that would be doing integration is probably 30%, as
those tasks would be relegated to more advanced users. A project that
lets non-advanced users to integration probably wouldn't care if the
merges are fast-forward or not, but let's say 10% of them do. That makes
3%.

On the other hand, user might do merges when trying to bring their local
repositories up-to-date, let's say 100% of them do. Of those, the ones
in a project that doesn't want fast-forward merges is probably 10%. That
makes 10%. However, such projects wouldn't want them merging
'origin/master' to 'master', but 'topic' to 'master', so they shouldn't
be using `git pull` anyway, but for the sake of argument let's say that
they do.

That would make around 8%, and 6% of those wouldn't be using `git pull`
anyway.

So no, for all intents and purposes it doesn't matter. I would rather
concentrate on the issue more than 90% of the users face.

> > And just as they can do pull.promot = true, they can do pull.mode =
> > fetch-only.
> 
> Why would you run a fetch-only pull instead of running 'git fetch'?  I
> think it would make more sense to have 'pull.mode = none' with which
> 'git pull …' turns into a no-op suggesting an explicit
> fetch/{merge|rebase}.  Having something like that available would
> help with the training issue that pull.prompt was addressing.

I fail to see how training them to do this:

  % git config --global pull.mode none
  % git pull
  % git fetch
  % git merge --no-ff

Is preferable than training them to do:

  % git pull --no-ff

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: A failing attempt to use Git in a centralized environment
  2014-04-28  6:29 A failing attempt to use Git in a centralized environment Marat Radchenko
                   ` (2 preceding siblings ...)
  2014-04-30 17:15 ` Geert Bosch
@ 2014-05-02 20:56 ` Max Kirillov
  3 siblings, 0 replies; 73+ messages in thread
From: Max Kirillov @ 2014-05-02 20:56 UTC (permalink / raw)
  To: Marat Radchenko; +Cc: git

Hi.

> Problem #6: push - reject - pull - push sequence sometimes transforms
> into a loop with several iterations and doesn't add happiness.

As far as I undestand, this is the most annoying thing. In
git (like other distributed systems), you cannot push your
changes unless you merge them with a very last version of
the whole repository.

I think the only good way to use git in a team with more
than a very few persons is to switch to pull-request based
workflow, which does not require users to update to push
their changes. Then their changes are merged to master
either by a human integrator or by a tool (gitorious,
github, stash, gerrit etc.).

I think it can be even as little as 'update' hook, thich is
triggered when user pushes to branch like 'inbox/bob' and
tries to merge the branch to master. The only issue I can
see with it is that does not provide a way to specify
meaningful merge message.

Btw, then the problem#2 is not a problem, because the merge
done by user does not yet produce the commit to be added to
master, but just prepares more recent version - to resolves
conflicts or check how the changes work against newer
codebase. One more merge is still performed by the server,
and parent order is correct:

master =====+===+======2
             \   \    /
your copy     +===1==+

-- 
Max

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02 20:34                                               ` Felipe Contreras
@ 2014-05-02 21:13                                                 ` W. Trevor King
  2014-05-02 21:18                                                   ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: W. Trevor King @ 2014-05-02 21:13 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]

On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> > > It would matter almost exactly zero.
> > 
> > Some folks have explicit merge policies, and deciding how much
> > that matters is probably best left up to the projects themselves
> > and not decided in Git code.
> 
> Let's make some fake numbers to see around how much this would matter.

The point isn't that this is a huge flaw, the point is that we should
be able to configure Git to match sane workflows.  Saying “that's
unlikely to happen” doesn't solve the problem that some newcomers have
trouble matching their project's desired workflow.

> So no, for all intents and purposes it doesn't matter. I would rather
> concentrate on the issue more than 90% of the users face.

You don't have to concentrate on it, because I'm willing to write up
the patch, I'm just trying to find a consensus spec before writing the
patch.  If you don't have strong feelings about a pull.prompt
proposal, I won't mind ;).  I just don't want to write it up and
*then* hear “that's a terrible idea, you should have just done $x.”.

> > > And just as they can do pull.promot = true, they can do pull.mode =
> > > fetch-only.
> > 
> > Why would you run a fetch-only pull instead of running 'git fetch'?  I
> > think it would make more sense to have 'pull.mode = none' with which
> > 'git pull …' turns into a no-op suggesting an explicit
> > fetch/{merge|rebase}.  Having something like that available would
> > help with the training issue that pull.prompt was addressing.
> 
> I fail to see how training them to do this:
> 
>   % git config --global pull.mode none
>   % git pull
>   % git fetch
>   % git merge --no-ff
> 
> Is preferable than training them to do:
> 
>   % git pull --no-ff

The goal is to train them to do:

>   % git config --global pull.mode none
>   % git fetch
>   % git merge --no-ff

The 'git pull' (with 'none' mode) explainer just helps retrain folks
that are already using the current 'git pull' incorrectly.

The benefit is that the repeated pair of commands (fetch/merge) takes
longer to type, which gives them longer to realize that they should
think about what they're doing and abort.  That's all a pull.prompt
would be doing anyway.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02 21:13                                                 ` W. Trevor King
@ 2014-05-02 21:18                                                   ` Felipe Contreras
  2014-05-02 22:01                                                     ` pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil) W. Trevor King
  0 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-05-02 21:18 UTC (permalink / raw)
  To: W. Trevor King, Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

W. Trevor King wrote:
> On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
> > W. Trevor King wrote:
> > > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> > > > It would matter almost exactly zero.
> > > 
> > > Some folks have explicit merge policies, and deciding how much
> > > that matters is probably best left up to the projects themselves
> > > and not decided in Git code.
> > 
> > Let's make some fake numbers to see around how much this would matter.
> 
> The point isn't that this is a huge flaw, the point is that we should
> be able to configure Git to match sane workflows.

The point is that we are tainting a discussion about how to improve the
defaults for the vast majority of users, and given Git's history, the
most likely outcome is that nothing will happen, neither for the
majority, nor the tiny minority.

> Saying “that's unlikely to happen” doesn't solve the problem that some
> newcomers have trouble matching their project's desired workflow.

% git config --global pull.ff false

Done.

> The goal is to train them to do:
> 
> >   % git config --global pull.mode none
> >   % git fetch
> >   % git merge --no-ff
> 
> The 'git pull' (with 'none' mode) explainer just helps retrain folks
> that are already using the current 'git pull' incorrectly.

If you are going to train them to use a configuration, it should be:

% git config --global pull.ff false

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil)
  2014-05-02 21:18                                                   ` Felipe Contreras
@ 2014-05-02 22:01                                                     ` W. Trevor King
  2014-05-02 22:20                                                       ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: W. Trevor King @ 2014-05-02 22:01 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 2198 bytes --]

On Fri, May 02, 2014 at 04:18:57PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> > > > > It would matter almost exactly zero.
> > > > 
> > > > Some folks have explicit merge policies, and deciding how much
> > > > that matters is probably best left up to the projects themselves
> > > > and not decided in Git code.
> > > 
> > > Let's make some fake numbers to see around how much this would matter.
> > 
> > The point isn't that this is a huge flaw, the point is that we should
> > be able to configure Git to match sane workflows.
> 
> The point is that we are tainting a discussion about how to improve the
> defaults for the vast majority of users

I've renamed this sub-thread (which started around $gmane/247835) to
avoid potential confusion/dilution.

> > The goal is to train them to do:
> > 
> > >   % git config --global pull.mode none
> > >   % git fetch
> > >   % git merge --no-ff

Sticking to my 'no-ff' topic branch example, this should have been:

  git merge --no-ff remote branch

I want folks to use --ff-only when pulling their default upstream.

> > The 'git pull' (with 'none' mode) explainer just helps retrain folks
> > that are already using the current 'git pull' incorrectly.
> 
> If you are going to train them to use a configuration, it should be:
> 
> % git config --global pull.ff false

I don't want all pulls to be --no-ff, only pulls from topic branches.
I think adding a prompt or making the integration a two-step
fetch/merge are both ways to jog a user into consciously evaluating
their actions.  I don't see how a changing the default single-step
pull strategy (whatever it is) will.  I also don't look forward to
explaining an adaptive strategy that tries to get my workflow right
without command-line ff options to folks on their first day using Git.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* RE: pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil)
  2014-05-02 22:01                                                     ` pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil) W. Trevor King
@ 2014-05-02 22:20                                                       ` Felipe Contreras
  2014-05-03  0:05                                                         ` pull.prompt or other way to slow/disable 'git pull' W. Trevor King
  0 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-05-02 22:20 UTC (permalink / raw)
  To: W. Trevor King, Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

W. Trevor King wrote:
> I've renamed this sub-thread (which started around $gmane/247835) to
> avoid potential confusion/dilution.

Thanks.

> > > The goal is to train them to do:
> > > 
> > > >   % git config --global pull.mode none
> > > >   % git fetch
> > > >   % git merge --no-ff
> 
> Sticking to my 'no-ff' topic branch example, this should have been:
> 
>   git merge --no-ff remote branch
> 
> I want folks to use --ff-only when pulling their default upstream.

That's proposed to be the default anyway, so they won't need it.

> > > The 'git pull' (with 'none' mode) explainer just helps retrain folks
> > > that are already using the current 'git pull' incorrectly.
> > 
> > If you are going to train them to use a configuration, it should be:
> > 
> > % git config --global pull.ff false
> 
> I don't want all pulls to be --no-ff, only pulls from topic branches.

Pulling some branch to a topic branch, or pulling a topic branch to
another branch?

Either way, since I think these two are different modes:

  1) git pull
  2) git pull origin topic

Maybe it would actually make sense to have a configuration specific to
2): pull.topicmode.

This way they could do "pull.topicmode = merge-no-ff". Or maybe we need
arguments: "pull.topicargs = --merge --no-ff".

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: pull.prompt or other way to slow/disable 'git pull'
  2014-05-02 22:20                                                       ` Felipe Contreras
@ 2014-05-03  0:05                                                         ` W. Trevor King
  2014-05-03  9:50                                                           ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: W. Trevor King @ 2014-05-03  0:05 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 4265 bytes --]

On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > > > The 'git pull' (with 'none' mode) explainer just helps retrain folks
> > > > that are already using the current 'git pull' incorrectly.
> > > 
> > > If you are going to train them to use a configuration, it should be:
> > > 
> > > % git config --global pull.ff false
> > 
> > I don't want all pulls to be --no-ff, only pulls from topic branches.
> 
> Pulling some branch to a topic branch, or pulling a topic branch to
> another branch?

The latter.  Here's a more detailed list:

1. HEAD: an integration branch (master, maint, …)
   target: @{upstream}, branch.*.pushremote, and other mirrors
   my preferred integration mode: ff-only merge the target

2. HEAD: an integration branch
   target: a *different* branch (e.g. maint or feature-x, but not
     origin/master or jdoe/master, if HEAD is master)
   my preferred integration mode: no-ff merge the target into HEAD.

3. HEAD: a topic branch (e.g. feature-x)
   target: a collaborating topic branch (jdoe/feature-x)
   my preferred integration mode: ff-only merge the target

4. HEAD: a topic branch (e.g. feature-x)
   target: a related topic branch (e.g. jdoe/feature-y) or integration
     branch updates used by my feature-x
   my preferred integration mode: rebase feature-x onto the target

Cases 1 and 2 can usually be distinguished by comparing the
checked-out branch with the branch portion of the remote-tracking
reference), but for folks developing in master, jdoe/master may be a
feature branch (case 2) not a mirror of the maintenance branch (case
1).

Cases 1 and 3 are the same idea, with any feature branch running long
enough to get collaborators being indistinguishable from an
integration branch except that the latter will eventually be merged
(or dropped) and deleted.

In the event of non-trivial merge conflicts in case 2, I sometimes
rebase the target onto HEAD and no-ff merge the resulting target'.  On
the other hand, sometimes rebasing is not an option.  For example, if
I want to merge the target into both master and maint, but master
contains a conflicting commit A:

  -o---o---A---o---B  master
   |\
   | o---o---C  maint
    \
     o---D  target

Rebasing would drag A into maint at F:

  -o---o---A---o---B---E  master
    \       \         /
     \       o---D'---  target'
      \           \
       o---o---C---F  maint

And I don't want both the pre- and post-rebase versions in my history
at G:

  -o---o---A---o---B---E---G  master
   |\       \         /   /
   | \       o---D'---   /  target'
   |  \                 /
   |   o---o---C---F----  maint
    \             /
     o---D--------  target

So I'd just deal with a complicated merge at E:

  -o---o---A---o---B---E---G  master
   |\                 /   /
   | o---D------------   /  target
    \           \       /
     o---o---C---F------  maint

Case 4 has similar caveats, since you don't want to rebase feature-x
on top of jdoe/feature-y if there are already other branches based on
the current feature-x that can't (or won't) be rebased.

> Either way, since I think these two are different modes:
> 
>   1) git pull
>   2) git pull origin topic
> 
> Maybe it would actually make sense to have a configuration specific to
> 2): pull.topicmode.

I think it makes more sense to just use merge/rebase explicitly, and
not try and bundle all of this complication into something that *also*
fetches.  Unfortunately, there's currently no finger-breaker to help
compulsive pull users break the habit or keep novices from starting.
Adding more elaborate handling to pull just pushes back the point
where you reach something that is pretty much impossible to resolve
automatically (like my case 2 caveat).  When that happens, it would be
nice to have a workflow independent way to calm the pull-happy user
(e.g. pull.mode=none, or pull.prompt=true) while they learn to
explicitly use fetch/{merge|rebase} or more careful pulls.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-02  8:46             ` David Kastrup
@ 2014-05-03  6:17               ` Andreas Krey
  2014-05-03  6:55                 ` David Kastrup
  0 siblings, 1 reply; 73+ messages in thread
From: Andreas Krey @ 2014-05-03  6:17 UTC (permalink / raw)
  To: David Kastrup; +Cc: git

On Fri, 02 May 2014 10:46:09 +0000, David Kastrup wrote:
...
> What the gibbins?  I don't even use git pull.

I do, but I watch for the fast-forward message
and undo as appropriate.

> I use git fetch, and then, depending on my needs, I rebase or merge.

I wouldn't mind that, but I have a century of newbies who are used
to having other people's changes appear in their workspace without
any interaction. Teaching them the mainline thing (aka first-parent)
and the commands to properly merge&push is...tricky.

And that goes for every user base, so some improvement would be
greatly appreciated.

Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: Pull is Evil
  2014-05-03  6:17               ` Andreas Krey
@ 2014-05-03  6:55                 ` David Kastrup
  0 siblings, 0 replies; 73+ messages in thread
From: David Kastrup @ 2014-05-03  6:55 UTC (permalink / raw)
  To: Andreas Krey; +Cc: git

Andreas Krey <a.krey@gmx.de> writes:

> On Fri, 02 May 2014 10:46:09 +0000, David Kastrup wrote:
> ...
>> What the gibbins?  I don't even use git pull.
>
> I do, but I watch for the fast-forward message
> and undo as appropriate.
>
>> I use git fetch, and then, depending on my needs, I rebase or merge.
>
> I wouldn't mind that, but I have a century of newbies who are used
> to having other people's changes appear in their workspace without
> any interaction. Teaching them the mainline thing (aka first-parent)
> and the commands to properly merge&push is...tricky.
>
> And that goes for every user base, so some improvement would be
> greatly appreciated.

I've seen the proposals for "git update" and whatever.  It's sort of
like having an assembly line where there are separate automatic screw
drivers for screwing and unscrewing.  The latter are hard to find in the
rare case you need them, with quite different handling and looks.

This is modeled after the successful fastening model for nails, where
hammer and pliers look and behave quite differently, so people are used
to handle and arrange hammer and pliers on different racks and have
different numbers for them.

Since this model works well for nails, let's employ it for screws as
well and call right-turning screwdrivers "hammers" and left-turning
screwdrivers "pliers" and sort them accordingly in order to avoid
confusion for beginners and help them learn to deal with screws properly
and deftly.

-- 
David Kastrup

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: pull.prompt or other way to slow/disable 'git pull'
  2014-05-03  0:05                                                         ` pull.prompt or other way to slow/disable 'git pull' W. Trevor King
@ 2014-05-03  9:50                                                           ` Felipe Contreras
  2014-05-04 18:51                                                             ` W. Trevor King
  0 siblings, 1 reply; 73+ messages in thread
From: Felipe Contreras @ 2014-05-03  9:50 UTC (permalink / raw)
  To: W. Trevor King, Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

W. Trevor King wrote:
> On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:
> > W. Trevor King wrote:
> > > > > The 'git pull' (with 'none' mode) explainer just helps retrain folks
> > > > > that are already using the current 'git pull' incorrectly.
> > > > 
> > > > If you are going to train them to use a configuration, it should be:
> > > > 
> > > > % git config --global pull.ff false
> > > 
> > > I don't want all pulls to be --no-ff, only pulls from topic branches.
> > 
> > Pulling some branch to a topic branch, or pulling a topic branch to
> > another branch?
> 
> The latter.  Here's a more detailed list:
> 
> 1. HEAD: an integration branch (master, maint, …)
>    target: @{upstream}, branch.*.pushremote, and other mirrors
>    my preferred integration mode: ff-only merge the target

`git pull` would do that by default.

> 2. HEAD: an integration branch
>    target: a *different* branch (e.g. maint or feature-x, but not
>      origin/master or jdoe/master, if HEAD is master)
>    my preferred integration mode: no-ff merge the target into HEAD.

That makes sense, but other people would be OK with a ff merge.

> 3. HEAD: a topic branch (e.g. feature-x)
>    target: a collaborating topic branch (jdoe/feature-x)
>    my preferred integration mode: ff-only merge the target

I don't see why. It will alomst always be non-fast-fowrward, so you
should already be prepared for a merge (or rebase).

> 4. HEAD: a topic branch (e.g. feature-x)
>    target: a related topic branch (e.g. jdoe/feature-y) or integration
>      branch updates used by my feature-x
>    my preferred integration mode: rebase feature-x onto the target

Nah. Most people would prefer a merge. And actually, quite many would
want jdoe/feature-y to be rebased on top of feature-x.

Either way it would be impossible for Git to figre out what you want to
do.

> Cases 1 and 2 can usually be distinguished by comparing the
> checked-out branch with the branch portion of the remote-tracking
> reference), but for folks developing in master, jdoe/master may be a
> feature branch (case 2) not a mirror of the maintenance branch (case
> 1).

I'd say they can be distinguished by what the user typed.
 
> Cases 1 and 3 are the same idea, with any feature branch running long
> enough to get collaborators being indistinguishable from an
> integration branch except that the latter will eventually be merged
> (or dropped) and deleted.

Ineed, so why would you want so drastically different behavior?
 
> In the event of non-trivial merge conflicts in case 2, I sometimes
> rebase the target onto HEAD and no-ff merge the resulting target'.  On
> the other hand, sometimes rebasing is not an option.  For example, if
> I want to merge the target into both master and maint, but master
> contains a conflicting commit A:
> 
>   -o---o---A---o---B  master
>    |\
>    | o---o---C  maint
>     \
>      o---D  target
> 
> Rebasing would drag A into maint at F:
> 
>   -o---o---A---o---B---E  master
>     \       \         /
>      \       o---D'---  target'
>       \           \
>        o---o---C---F  maint
> 
> And I don't want both the pre- and post-rebase versions in my history
> at G:
> 
>   -o---o---A---o---B---E---G  master
>    |\       \         /   /
>    | \       o---D'---   /  target'
>    |  \                 /
>    |   o---o---C---F----  maint
>     \             /
>      o---D--------  target
> 
> So I'd just deal with a complicated merge at E:
> 
>   -o---o---A---o---B---E---G  master
>    |\                 /   /
>    | o---D------------   /  target
>     \           \       /
>      o---o---C---F------  maint
> 
> Case 4 has similar caveats, since you don't want to rebase feature-x
> on top of jdoe/feature-y if there are already other branches based on
> the current feature-x that can't (or won't) be rebased.

What I do in those cases is do both a merge and a rebase. If I resolved
the conflicts correctly in the rebase the result of the merge should be
exactly the same. It's not hard because rerere stores the conflict
resolutions of the rebase and the merge becomes much simpler. After I'm
certain the merge is correct, I remove the temporary rebased branch.

Anyway I don't see how is this possibly relevant to the topic at hand.

> > Either way, since I think these two are different modes:
> > 
> >   1) git pull
> >   2) git pull origin topic
> > 
> > Maybe it would actually make sense to have a configuration specific to
> > 2): pull.topicmode.
> 
> I think it makes more sense to just use merge/rebase explicitly,

Fine, if you want the user to be explicit, he can be explicit with
`git pull --no-ff origin topic`. Problem solved.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: A failing attempt to use Git in a centralized environment
  2014-04-30 17:15 ` Geert Bosch
@ 2014-05-04  8:58   ` John Szakmeister
  0 siblings, 0 replies; 73+ messages in thread
From: John Szakmeister @ 2014-05-04  8:58 UTC (permalink / raw)
  To: Geert Bosch; +Cc: Marat Radchenko, git

On Wed, Apr 30, 2014 at 1:15 PM, Geert Bosch <boschg@mac.com> wrote:
>
> On Apr 28, 2014, at 02:29, Marat Radchenko <marat@slonopotamus.org> wrote:
>
>> In short:
>> 1. Hack, hack, hack
>> 2. Commit
>> 3. Push, woops, reject (non-ff)
>> 4. Pull
>> 5. Push
>
> Just do pull --rebase? This is essentially the same as what SVN
> used to do in your setup.

That's not necessarily a good solution either.  For teams that don't
use rebase, it can leave them with their newly committed stuff now
rebased on the work from upstream--duplicating commits without
understanding why and where they came from, especially if other
branches were built on top of that one.

I agree in concept, but in practice it can be quite confusing. :-(

-John

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: pull.prompt or other way to slow/disable 'git pull'
  2014-05-03  9:50                                                           ` Felipe Contreras
@ 2014-05-04 18:51                                                             ` W. Trevor King
  2014-05-04 20:54                                                               ` Felipe Contreras
  0 siblings, 1 reply; 73+ messages in thread
From: W. Trevor King @ 2014-05-04 18:51 UTC (permalink / raw)
  To: Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

[-- Attachment #1: Type: text/plain, Size: 6065 bytes --]

On Sat, May 03, 2014 at 04:50:52AM -0500, Felipe Contreras wrote:
> Either way it would be impossible for Git to figre out what you want
> to do.

That's my point.  The details of my particular workflow are
unimportant.

> Anyway I don't see how is this possibly relevant to the topic at
> hand.

I'm trying to motivate a way to slow/disable 'git pull', which I see
as orthogonal to your push to change the default configuration.  I
thought describing my workflow in more detail would help clarify why…

> W. Trevor King wrote:
> > On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > > > The 'git pull' (with 'none' mode) explainer just helps retrain folks
> > > > > > that are already using the current 'git pull' incorrectly.
> > > > > 
> > > > > If you are going to train them to use a configuration, it should be:
> > > > > 
> > > > > % git config --global pull.ff false
> > > > 
> > > > I don't want all pulls to be --no-ff, only pulls from topic branches.

… this global pull.ff config was not a solution.

> > > Either way, since I think these two are different modes:
> > > 
> > >   1) git pull
> > >   2) git pull origin topic
> > > 
> > > Maybe it would actually make sense to have a configuration specific to
> > > 2): pull.topicmode.
> > 
> > I think it makes more sense to just use merge/rebase explicitly,
> 
> Fine, if you want the user to be explicit, he can be explicit with
> `git pull --no-ff origin topic`. Problem solved.

That's certainly explicit, but some folks are in the habit of just
running 'git pull' (regardless of which branch they happen to be on)
without thinking “Where am I, what am I integrating, and how should I
integrate it?”.  As I claimed earlier:

On Thu, May 01, 2014 at 06:10:04PM -0700, W. Trevor King wrote [1]:
> Folks who are setting any ff options don't need any of these
> training wheels.  My proposed --prompt behavior is for folks who
> think “I often run this command without thinking it through all the
> way.  I'm also not used to reading Git's output and using 'reset
> --hard' with the reflog to reverse changes.  Instead of trusting me
> to only say what I mean or leaving me to recover from mistakes,
> please tell me what's about to change and let me opt out if I've
> changed my mind.”

In the messages following that, you seemed to agree that such folks
existed [2], and suggested I use pull.mode=fetch-only [3] or
pull.ff=false [4] or pull.topicargs='--merge --no-ff' [5].  Now we
agree (I think?  Based on your “it would be impossible for Git…”
quoted above) that you can have a sane workflow for which no
pull-strategy default will always do the right thing.  We just
disagree (I think) on what to do about it.  I'm suggesting
pull.prompt, pull.mode=none, or some other way to slow/disable 'git
pull' while folks retrain themselves.  You're suggesting (I think?
Based on your 'git pull --no-ff origin topic' quoted above) that folks
just skip right to remembering which ff options to use in which
situations.  Do you feel folks won't need a way to slow/disable 'git
pull' while they build the ff options and their project's recommended
workflow into their own practice?  Or do you agree that they will need
some kind of helper for the transition, and just feel that git.prompt
is the wrong helper?

Cheers,
Trevor

[1]: http://article.gmane.org/gmane.comp.version-control.git/247917
[2]: http://article.gmane.org/gmane.comp.version-control.git/247919
     On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
     > W. Trevor King wrote:
     > > Folks who are setting any ff options don't need any of these
     > > training wheels.
     >
     > Indeed.
[3]: http://article.gmane.org/gmane.comp.version-control.git/247957
     On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
     > W. Trevor King wrote:
     > > On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
     > > > W. Trevor King wrote:
     > > > > But once such folks are identified, you just have to
     > > > > convince them (once) to set the pull.prompt config.
     > > > > That's a lot easier than convincing them (for every pull)
     > > > > to set the appropriate ff flag.
     > > >
     > > > It wouldn't matter if by the default non-fast-forward
     > > > merges are rejected.
     > >
     > > It would matter if you didn't want them making
     > > non-fast-forward merges (e.g. for explicitly-merged topic
     > > branches).
     >
     > It would matter almost exactly zero. And just as they can do
     > pull.promot = true, they can do pull.mode = fetch-only.
[4]: http://article.gmane.org/gmane.comp.version-control.git/247986
     On Fri, May 02, 2014 at 04:18:57PM -0500, Felipe Contreras wrote:
     > W. Trevor King wrote:
     > > Saying “that's unlikely to happen” doesn't solve the problem
     > > that some newcomers have trouble matching their project's
     > > desired workflow.
     >
     > % git config --global pull.ff false
     >
     > Done.
[5]: http://article.gmane.org/gmane.comp.version-control.git/247998
     On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:
     > W. Trevor King wrote:
     > > I don't want all pulls to be --no-ff, only pulls from topic
     > > branches.
     >
     > Pulling some branch to a topic branch, or pulling a topic
     > branch to another branch?
     >
     > Either way, since I think these two are different modes:
     >
     >   1) git pull
     >   2) git pull origin topic
     >
     > Maybe it would actually make sense to have a configuration
     > specific to 2): pull.topicmode.
     >
     > This way they could do "pull.topicmode = merge-no-ff". Or maybe
     > we need arguments: "pull.topicargs = --merge --no-ff".

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 73+ messages in thread

* Re: pull.prompt or other way to slow/disable 'git pull'
  2014-05-04 18:51                                                             ` W. Trevor King
@ 2014-05-04 20:54                                                               ` Felipe Contreras
  0 siblings, 0 replies; 73+ messages in thread
From: Felipe Contreras @ 2014-05-04 20:54 UTC (permalink / raw)
  To: W. Trevor King, Felipe Contreras
  Cc: Junio C Hamano, brian m. carlson, Marc Branchaud, Marat Radchenko, git

W. Trevor King wrote:
> Do you feel folks won't need a way to slow/disable 'git pull' while
> they build the ff options and their project's recommended workflow
> into their own practice?

That's right.

> Or do you agree that they will need some kind of helper for the
> transition, and just feel that git.prompt is the wrong helper?

I feel helpers are good when we are transitioning from an established
Git behavior to a new one. Or when the operation is potentially
dangerous.

But a fast-forward merge is not dangerous, an in fact it's what the vast
majority of people would want.

Even more, I'm now feeling confident I will be able to put a proposal
that allow a simple configuration to fulfill the need of these users
without affecting anyone else negatively.

-- 
Felipe Contreras

^ permalink raw reply	[flat|nested] 73+ messages in thread

end of thread, other threads:[~2014-05-04 21:04 UTC | newest]

Thread overview: 73+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-28  6:29 A failing attempt to use Git in a centralized environment Marat Radchenko
2014-04-28 18:41 ` Junio C Hamano
2014-04-30 14:21   ` Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment) Marc Branchaud
2014-04-30 14:55     ` Junio C Hamano
2014-04-30 19:45       ` Pull is Evil Marc Branchaud
2014-04-30 20:01         ` Jonathan Nieder
2014-04-30 20:01         ` Junio C Hamano
2014-04-30 21:48           ` Marc Branchaud
2014-05-02  7:40           ` Andreas Krey
2014-05-02  8:46             ` David Kastrup
2014-05-03  6:17               ` Andreas Krey
2014-05-03  6:55                 ` David Kastrup
2014-04-30 20:14         ` Felipe Contreras
2014-04-30 22:06           ` Marc Branchaud
2014-04-30 22:25             ` Felipe Contreras
2014-05-01  9:46               ` brian m. carlson
2014-05-01 10:48                 ` Felipe Contreras
2014-05-01 15:16                   ` Junio C Hamano
2014-05-01 19:16                     ` Felipe Contreras
2014-05-01 19:48                       ` W. Trevor King
2014-05-01 20:07                         ` W. Trevor King
2014-05-01 23:25                           ` Felipe Contreras
2014-05-02  0:02                             ` W. Trevor King
2014-05-02  0:37                               ` Felipe Contreras
2014-05-02  1:10                                 ` W. Trevor King
2014-05-02  1:14                                   ` Felipe Contreras
2014-05-02 14:54                                     ` W. Trevor King
2014-05-02 18:55                                       ` Felipe Contreras
2014-05-02 19:07                                         ` W. Trevor King
2014-05-02 19:10                                           ` David Kastrup
2014-05-02 19:13                                           ` Felipe Contreras
2014-05-02 19:46                                             ` W. Trevor King
2014-05-02 20:34                                               ` Felipe Contreras
2014-05-02 21:13                                                 ` W. Trevor King
2014-05-02 21:18                                                   ` Felipe Contreras
2014-05-02 22:01                                                     ` pull.prompt or other way to slow/disable 'git pull' (was: Pull is Evil) W. Trevor King
2014-05-02 22:20                                                       ` Felipe Contreras
2014-05-03  0:05                                                         ` pull.prompt or other way to slow/disable 'git pull' W. Trevor King
2014-05-03  9:50                                                           ` Felipe Contreras
2014-05-04 18:51                                                             ` W. Trevor King
2014-05-04 20:54                                                               ` Felipe Contreras
2014-05-01 23:20                         ` Re: Pull is Evil Felipe Contreras
2014-05-01 15:20                 ` Marc Branchaud
2014-05-01 17:56                   ` W. Trevor King
2014-05-01 18:04                     ` Marc Branchaud
2014-05-01 18:30                       ` W. Trevor King
2014-05-01 20:21                         ` Marc Branchaud
2014-05-01 23:28                           ` Felipe Contreras
2014-05-02  7:16                           ` Andreas Krey
2014-05-02  8:14                             ` Felipe Contreras
2014-05-02 19:29                           ` Junio C Hamano
2014-05-02 19:53                             ` Junio C Hamano
2014-05-01 23:45                       ` brian m. carlson
2014-05-01 23:39                         ` Felipe Contreras
2014-05-01 19:22                   ` Felipe Contreras
2014-05-01 19:43                     ` Marc Branchaud
2014-05-01 19:27                 ` Felipe Contreras
2014-05-01 21:06         ` Philip Oakley
2014-05-01 21:16           ` Philip Oakley
2014-05-01 23:34           ` Felipe Contreras
2014-05-01 23:59             ` W. Trevor King
2014-05-02  0:31               ` Felipe Contreras
2014-04-30 16:47     ` Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment) Felipe Contreras
2014-04-30 17:09       ` Pull is Evil Matthieu Moy
2014-04-30 18:31         ` Felipe Contreras
2014-04-30 19:10           ` Junio C Hamano
2014-04-30 19:32             ` Felipe Contreras
2014-04-30 19:53               ` Junio C Hamano
2014-04-30 20:11                 ` Felipe Contreras
2014-04-30 16:12 ` A failing attempt to use Git in a centralized environment Stepan Kasal
2014-04-30 17:15 ` Geert Bosch
2014-05-04  8:58   ` John Szakmeister
2014-05-02 20:56 ` Max Kirillov

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).