Re: Pull is Evil (was: Re: A failing attempt to use Git in a centralized environment)

Marc Branchaud [off-list ref] 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.

On 14-04-30 10:55 AM, Junio C Hamano wrote:

Marc Branchaud [off-list ref] writes:

quoted

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'".

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

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

On 14-04-30 04:14 PM, Felipe Contreras wrote:

Marc Branchaud wrote:

quoted

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

Marc Branchaud wrote:

On 14-04-30 04:14 PM, Felipe Contreras wrote:

quoted

Marc Branchaud wrote:

quoted

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.

quoted

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

On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:

Marc Branchaud wrote:

quoted

On 14-04-30 04:14 PM, Felipe Contreras wrote:

quoted

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.

quoted

quoted

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

brian m. carlson wrote:

On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:

quoted

Marc Branchaud wrote:

quoted

On 14-04-30 04:14 PM, Felipe Contreras wrote:

quoted

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.

quoted

quoted

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

On 14-05-01 05:46 AM, brian m. carlson wrote:

On Wed, Apr 30, 2014 at 05:25:59PM -0500, Felipe Contreras wrote:

quoted

Marc Branchaud wrote:

quoted

On 14-04-30 04:14 PM, Felipe Contreras wrote:

quoted

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.

quoted

quoted

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.

On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:

On 14-05-01 05:46 AM, brian m. carlson wrote:

quoted

  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

On 14-05-01 01:56 PM, W. Trevor King wrote:

On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:

quoted

On 14-05-01 05:46 AM, brian m. carlson wrote:

quoted

  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.

quoted

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.

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

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

On 14-05-01 03:22 PM, Felipe Contreras wrote:

Marc Branchaud wrote:

quoted

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.

On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote:

On 14-05-01 01:56 PM, W. Trevor King wrote:

quoted

On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:

quoted

On 14-05-01 05:46 AM, brian m. carlson wrote:

quoted

  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

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.

From: "Marc Branchaud" <redacted>
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
-- 

Oops..
From: "Philip Oakley" <redacted>

From: "Marc Branchaud" <redacted>
Sent: Wednesday, April 30, 2014 8:45 PM
[...]

quoted

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. 

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

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

On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote:

On 14-05-01 01:56 PM, W. Trevor King wrote:

quoted

On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:

quoted

On 14-05-01 05:46 AM, brian m. carlson wrote:

quoted

  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

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

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

W. Trevor King wrote:

On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote:

quoted

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

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

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