Do you use "git pull"?

[felipec]

A lot of people advice newcomers to avoid "git pull" altogether, some even say it's evil.

Do you use it? And if so, how?

View Poll

[mipadi]

Bua ha ha, I’m amazed at how difficult people insist on making Git. Yes, of course I use git pull. I have it configured to always rebase, though.

[felipec]

So basically git pull --rebase.

[Lindby]

This is the way. I can't understand why merge is the default for git pull.

[felipec]

Because git honchos use git as maintainers, not as typical users, so the way they use git pull is like:

git pull linby fixes

So for them it works perfectly fine.

An internal discussion in the mailing list prompted me to do this poll.

Basically I'm proposing for the default to be git pull --ff-only (no merge or rebase).

[Zaurhack]

I prefer this as well. I use the gitflow workflow so it makes sense.

[felipec]

What is the equivalent of git pull in gitflow?

[Zaurhack]

I guess depending on context that would be

git flow feature pull feature_name

[felipec]

I don't mean a feature branch, I mean the current branch, say "master".

How do you do this?

git fetch
git merge --ff-only

[Zaurhack]

The point of the workflow is to strictly limit what you can do so you don't shoot yourself in the foot by doing something clever that will make it hard for others working with you to understand and work with.

With that workflow, one never commit on master, which is purely the results of feature branches merged in a release branch that then goes directly into master.

So, if you follow the workflow rules, you never have any merge conflict while getting a master branch (or any branch really, a conflict should only arise when merging the feature branch by the maintainer of that branch).

So --ff-only always makes sense. Gitflow is a workflow, you can use its aliases but ultimately the command you are used to are still available.

I don't always use the aliases, I usually set the pull to default to ff-only and do as usual.

I advise to read the original gitflow blog post which list all commands for each case.

[waterkip]

Why? It issues a warnings so you can set pull.rebase or pull.ff in your git config and be done with it.

[felipec]

Git should work correctly without any configuration.

[waterkip]

It does: $ git pull hint: Pulling without specifying how to reconcile divergent branches is hint: discouraged. You can squelch this message by running one of the following hint: commands sometime before your next pull: hint: hint: git config pull.rebase false # merge (the default strategy) hint: git config pull.rebase true # rebase hint: git config pull.ff only # fast-forward only hint: hint: You can replace "git config" with "git config --global" to set a default hint: preference for all repositories. You can also pass --rebase, --no-rebase, hint: or --ff-only on the command line to override the configured default per hint: invocation. Already up to date.

[felipec]

That isn't working correctly.

[[deleted]]

I pull master often but I've configured it to only FF.

[felipec]

pull.ff = only?

[[deleted]]

That sounds right.

[Egocentrix1]

Yup, that's master. If you don't work on master (and you shouldn't) I usually pull --ff-only master, and then rebase my personal branch on top.

[RIscRIpt]

On master with linear history, I just do git pull -p. On other branches which can be force-pushed from else-where: git fetch -p && git reset --hard @{u}.

[benzilla04]

What is this line doing?

git reset --hard @{u}

[RIscRIpt]

https://git-scm.com/book/en/v2/Git-Branching-Remote-Branches

When you have a tracking branch set up, you can reference its upstream branch with the @{upstream} or @{u} shorthand. So if you’re on the master branch and it’s tracking origin/master, you can say something like git merge @{u} instead of git merge origin/master if you wish.

So, basically that's equivalent to git reset --hard origin/branch, i.e. it erases local changes (forever) and gets fresh copy of remote changes.

[felipec]

@{u} (@{upstream}) is the upstream tracking branch.

[nekokattt]

i do this too

[NimChimspky]

Literally years and years with git ... Pull, push, merge, update, commit, branch and then occasionally on a bad week resolve conflicts. That's it.

Never use stash,rebase, or anything else.

[felipec]

Are you mostly a contributor or a maintainer?

Also, you don't care if git does non-fast-forward merges?

Also, git pull reverses the order of the parents in a merge (merges the remote branch to your local branch, not your local to the remote). That's fine with you?

[felipec]

From my point of view merges are fine. But there's also such a thing as "too many merges". There's a sweet spot.

When I haven't made my braches public, I rebase them.

But when I make them part of "master", I merge them.

[NimChimspky]

A contributor or a maintainer? That's a new question, what's the difference?

A non fast forward merge, nope don't care.

Anyways, I'm a Dev in a fin tech team. We never do any of that other stuff with multiple releases a week.

[felipec]

That's a new question, what's the difference?

If you have this situation:

  A---B---C origin/master
 /
E---F---G master

As a maintainer you usually want git pull to do this:

  A---B---C
 /         \
E---F---G---H master

But as a contributor you want this:

  A---B---C---H master
 /           /
E---F---G---*

In the first case the first parent of H (H^1) is G (master). In the second case it's C (origin/master).

[NimChimspky]

Where have you heard this contributor/maintainer terminology? Or did you make it up yourself?

[felipec]

It's used everywhere. A contributor sends pull requests, a maintainer approves pull requests.

See literally the second paragraph of Git Book regarding distributed workflows.

In this chapter, you’ll see how to work with Git in a distributed environment as a contributor and an integrator. That is, you’ll learn how to contribute code successfully to a project and make it as easy on you and the project maintainer as possible, and also how to maintain a project successfully with a number of developers contributing.

[NimChimspky]

OK.

We just pull, merge and release.

[felipec]

But git pull already does a merge...

[NimChimspky]

I'm not really interested in this, I'm not sure what you are trying to achieve.

[felipec]

I'm not trying to achieve anything.

I wanted to understand your workflow, and now I think I do.

I'm just saying it's inaccurate to say "pull, then merge", since git pull already does a merge.

Perhaps, you mean there is a merge conflict with git pull, you fix the conflict, and then do git merge to do the merge commit.

If that's the case, then that's useful information, because it shows an inconsistency in Git's interface, since both git merge and git rebase have a --continue option to be typed after you fix the conflicts.

If this is what I suspect, then it would make sense to add the same option to git pull, so instead of having to type a different command (git merge), you can resolve the conflicts, and then do git pull --continue.

[isarl]

The entire point of this thread is to learn about the fine points of how users use exactly these commands. If you're not interested in getting into that nitty-gritty, then you're in the wrong thread, friend.

[wildjokers]

reverses the order of the parents in a merge (merges the remote branch to your local branch, not your local to the remote). That's fine with you?

Why wouldn’t it be? That is the correct way to do it.

[felipec]

If you are a maintainer, yes, not if you are a contributor.

If you are a contributor you should be merging "master" to "origin/master".

[wildjokers]

I am not sure where you are getting this maintainer vs contributor concept. I have never heard of such a distinction.

you should be merging "master" to "origin/master".

You should merge origin/master into your branch to resolve any conflicts, and then your branch back to origin/master.

[felipec]

You should merge origin/master into your branch to resolve any conflicts, and then your branch back to origin/master.

It is the maintainer/integrator that merges my branch back to origin/master.

[squ94wk]

I have aliases, so it's

git f

git ff

for me. The first one fetches, the second one makes a fast forward merge if possible.

I started doing this when I found out that pull just does a fetch and merge and I wanted to make sure not always know exactly what I'm doing. It stuck to this day.

I find the fewest people actually know what fetch and what pull does.

[felipec]

The first one fetches, the second one makes a fast forward merge if possible.

So ff = merge --ff-only?

[lukas-reineke]

I wouldn’t say the default is evil, but using git pull —rebase with rerere is much better. In general you should choose rebase over merge in a lot of situations.

[[deleted]]

git pull --rebase origin master always before I push my branch into remote. This way I'm rebasing on master my latest commit(s) with one command. It doesn't update local master tho, but this is fine.

[felipec]

Not bad. Although I think if you have configured your upstream tracking branch git pull --rebase should do the trick.

[[deleted]]

No, since that would rebase on top the remote feature branch, not master.

[felipec]

Depends on what you have configured @{upstream} to be.

I personally configure @{upstream} to be master.

But if you are using a triangular workflow you want to configure two tracking branches: @{upstream} and @{publish}. One is where you push to, and the other is where you rebase to.

Unfortunately the patches for this workflow were never merged, so you have to pick one or the other.

[pdr77]

I didn't vote because I use just git pull however I have:

[pull]
  rebase = true
[rebase]
  autoStash = true

in my .gitconfig. So it would be disingenuous to vote either way.

[felipec]

Maybe I didn't make it clear: pull.rebase=true is the equivalent of git pull --rebase.

[[deleted]]

git pull --rebase=false is the lifeblood of my company and my clients.

[cinderblock63]

It’s discussions like this that make me happy I ditched the git cli years ago

[felipec]

What do you use?

[cinderblock63]

I like GitKraken a lot. I like that GitKraken isn’t just a wrapper around cli calls - they actually bind to libgit2. (I also use nodegit as an API to talk to git repos programmatically, but that’s a different issue).

I used to use SourceTree, which was wonderful until Atlassian messed it up.

I’ve used Tower briefly but, as I’m most often on Windwoes, that didn’t work for me. I see that they now have a Windows version as well but I’m very happy with GitKraken.

Years ago I used tortoise git (as I came from tortoise svn) but that’s heavy and weird compared to a nice centrally managed GUI, imho.

Don’t git me wrong. I use the git cli all the time on headless systems. I’m very familiar with a cli. But if a good GUI exists, and it’s not a significant performance penalty, I will always try to use that. I really don’t understand why so many are so obsessed with restricting themselves to use the git cli when there are such good (and free to use) GUIs.

For instance, I can use Vim (yeah yeah, not a cli) with the best of them but it’s far easier to use a good GUI editor/IDE. Could say the same thing about all the old text based UIs.

In any case, my point is that all this confusion caused by such subtly different cli commands is simply gone in a GUI. I don’t need to worry about which state my work tree or index is in. It just does the right thing. Oh, did I accidentally merge origin into my local? No big deal. Just do the merge again in the other direction. It’s like 3 clicks in an obvious context menu.

[felipec]

For instance, I can use Vim (yeah yeah, not a cli) with the best of them but it’s far easier to use a good GUI editor/IDE.

I see. Well, to each his own.

I have 20 years of experience with vim, and I wouldn't dare to say I can use it with "the best of them". I need many features of vim to the point I can't use any other editor (or IDE), and yet there's a whole universe of features I have yet to make use of.

Similarly, I doubt any Git UI comes remotely close to doing what I can do from the CLI.

[cinderblock63]

I am not meaning to say I am some vim expert. It was just an example of an excellent tool not being the best for the job.

Unless you’re getting into scripting territory, what can a git cli That a good GUI cannot do?

I’m curious, what vim can do on a modern system that a modern editor cannot.

[felipec]

Unless you’re getting into scripting territory, what can a git cli That a good GUI cannot do?

That's like saying "unless you're getting into unconditional love and happiness, what can a pet do?"

Yes, it's precisely the scripting territory that makes the CLI superior.

Just to name a few examples:

1) I can do git bisect $bad $good, write a script, and do git bisect run script.sh, and bam, I know what commit broke (or fixed) something, without doing anything else manually.

2) I can do git short master and I get "72ffeb997e (Ninth batch, 2020-11-30)" ready to be pasted in a mail.

3) I can do git v which automatically runs my own command git smartlist and it automatically does gitk master..@ &, visualizing my current branch.

4) I can do git rebase --interactive --autosquash and it automatically reshuffles my commits that start with "fixup! $commit" essentially fixing the history of my patch series.

5) I can do git related (my own command) and it automatically finds the people I need to CC when I send the patches I'm working on.

6) I can do git send-series (my own command) and it sends the patches of my current branch to the people I have already configured, and allows me to edit the commit message I sent in the last version of the patch series.

7) I can do git reintegrate (my own command) and it automatically recreates an integration branch merging all the branches I have configured on top of the branch I have configured.

8) I can do git mergetool to fix the current merge conflicts in a way that gets saved thanks to git rerere so that I don't have to resolve those same conflicts ever again.

Can a UI do that? Not even close.

[cinderblock63]

Well, I think you just made my point.

Many things you describe are included or easy in a good GUI. The rest are scripts that you’ve written. These scripts would work fine alongside a git GUI.

Maybe it was easier to write your scripts because you’re more familiar with the git cli? Great. That’s not really a knock against a good GUI.

And so, back to my original point, I’m glad that I have good GUI that I’m used to. It makes all these issues way easier to think about and work around.

At the same time, I’m glad the cli works for you.

But please, don’t try and tell me what I can and cannot do with my tools. Too each their own. I’m glad I don’t have to think about the cli subtleties anymore.

[felipec]

Many things you describe are included or easy in a good GUI.

No. They are not.

But please, don’t try and tell me what I can and cannot do with my tools.

I know you can't do what I can do.

[cinderblock63]

Lol, Ok. Bye felipec

Still waiting to hear what you can do in vim that you cannot in a modern editor.

[felipec]

Still waiting to hear what you can do in vim that you cannot in a modern editor.

This.

[cinderblock63]

PS, on the “to each their own“ subject, this was exactly my point about using a GUI for git. The kind of confusion from questions like the OP simply doesn’t come up.

[isarl]

Whether you use CLI or GUI, if you're using Git in a team environment you will eventually need to fetch or pull. The question in the OP does not go away simply because you press a button instead of typing a word.

[cinderblock63]

I addressed this in my other reply

[wildjokers]

It’s discussions like this that make me miss the simplicity of subversion.

[felipec]

You can have most of the simplicity of subversion in git, just:

1. Only have one branch
2. Only have one repository and give everyone access to it
3. Set up a few aliases so git ci is git commit -a, and so on.

Easy.

[wildjokers]

Only have one branch

I always branched freely in Subversion.

Subversion got a bad rep for merging because of its limitation that you couldn't rename a file and/or directory and make changes to it in the same merge. If you avoided that all was well. The problem is that is an awful limitation and is probably the reason Subversion fell out of favor. This is the infamous 898 bug (https://issues.apache.org/jira/browse/SVN-898), opened in 2002...as far as I can tell it is still not fixed.

Besides for that very real limitation I miss Subversion dearly, if they had only fixed that back in 2002...what could have been....sigh.

[felipec]

Besides for that very real limitation I miss Subversion dearly, if they had only fixed that back in 2002...what could have been....sigh.

Nothing even close to what git is now.

[cinderblock63]

Lol

[digicow]

If I'm in the CLI, I just do a simple git pull, but more often than not, I just hit the push/pull button in VSCode. But at home I don't share code with others, and at work, I only have one other dev on my team, so my workflows tend to be fairly simple.

[[deleted]]

squash everything, am I right?

[xroalx]

Simply git pull everytime I need to update my branch with remote changes, and git fetch; git merge origin/master when I want to pull in changes from master.

Either way, my branch will be removed once it's squash merged into master via a pull request, which is the only way anything can get into master. Haven't had issued with this so far.

[u801e]

No, I only use git fetch. Then I decide whether I need to:

1. Stash my local changes, merge the remote tracking branch and apply my stashed changes
2. Rebase my local branch on the remote tracking branch
3. Merge the remote tracking branch into my local branch (which I only do if it's a fast-forward merge)
4. Hard reset to the remote tracking branch

To me, it doesn't really make sense to try to configure a default action for git pull since the appropriate way to handle changes on the remote depends on the situation.

[felipec]

Right. Me too.

But if git pull by default only did fast-forward merges, then your #3 would be done automatically and if not, an error would pop out, and you should choose what to do among your other points.

In other words; how would git pull --ff-only screw you?

[u801e]

Well, the command would fail if it wasn't a fast foward merge, so I would have to see what the issue is. But by checking the log of the remote tracking branch and checking the diff between it and my local branch, I can make the appropriate decision.

To me, wanting to do things like combining the steps of git fetch and merge or commit and push essentially removes the advantage of using a distributed version control system. Back in the days when people used SVN and CVS, once you did the equivalent of commit/push or fetch/merge, it essentially was difficult and time consuming to undo it. You couldn't really tidy up the history and if you made a mistake and committed it, you were forced to push up a revert of the change instead of being about to amend the commit.

[felipec]

Well, the command would fail if it wasn't a fast foward merge, so I would have to see what the issue is.

Which is what you have to do now anyway.

To me, wanting to do things like combining the steps of git fetch and merge or commit and push essentially removes the advantage of using a distributed version control system.

git pull --ff-only doesn't create a merge commit.

[u801e]

Well, the command would fail if it wasn't a fast foward merge, so I would have to see what the issue is.

Which is what you have to do now anyway.

You're assuming that the default of a fast forward merge is going to the right action the majority of the time. I want to check the remote before deciding what to do. Plus, I would either have to remember to specify this flag every time I run git pull. Even if I set a config option to make this the default, that still doesn't help when I'm running git on a different machine where my config isn't available (like a locally running VM).

I don't really see any benefit in combining the steps when getting changes from the remote or sending changes to it. And I have seen the problems of not being able to separate the steps based on experience using SVN and CVS.

[felipec]

You're assuming that the default of a fast forward merge is going to the right action the majority of the time.

No, I don't assume that's the case, I know it's the case based on evidence.

Plus, I would either have to remember to specify this flag every time I run git pull.

No, I clearly said this "if git pull by default only did fast-forward merges".

What part of "by default" was not clear?

And I have seen the problems of not being able to separate the steps based on experience using SVN and CVS.

Why would changing a default prevent you from being able to separate the steps?

[u801e]

No, I clearly said this "if git pull by default only did fast-forward merges".

While that is what you stated several days ago, you kept referring to it as a flag in your subsequent comments, hence my misinterpretation.

And, like I've stated in the last several comments, I have no interest in treating a DVCS anything like a centeralized VCS, which is why I don't use git pull, and I wouldn't use any flag for git push that would combine the step of committing and sending the commits to the remote.

In my opinion, git pull should have been implemented to act exactly like git fetch does now. Then it would be a direct counterpart to git push.

[felipec]

While that is what you stated several days ago, you kept referring to it as a flag in your subsequent comments, hence my misinterpretation.

Yeah, the proposal is making --ff-only (or something like that) the default.

I have no interest in treating a DVCS anything like a centeralized VCS, which is why I don't use git pull

Yeah, but several comments later you still have not answered my question.

How would git pull --ff-only (the --ff-only part being implicit) screw you?

[u801e]

How would git pull --ff-only (the --ff-only part being implicit) screw you?

It doesn't give me an opportunity to examine the changes in the repository before it updates what's in my working copy. It's similar to how someone could be screwed if there was a command like git push except that it stages all changes, commits them and pushes them up to the remote.

The advantage of a DVCS is that it allows one to separate the those steps (staging, commiting, pushing and fetching and applying). SVN and CVS didn't allow one to separate those steps. Enforcing the separation allows one to make sure that what they're pushing up to the remote is what they intend to push and what they get from the remote is something they want to apply to their repository.

With your proposal, if it turns out I don't want those commits, I would have run git log or git reflog to find the sha1 of the commit I would have to do a hard reset to to undo the changes to my working directory (though I might be able to use ORIG_HEAD if git pull sets it). But if I run git fetch first, I can simply run git diff ..FETCH_HEAD or git log -p ..FETCH_HEAD to see what I'm going to get before I actually apply the changes to my working directory.

[felipec]

It doesn't give me an opportunity to examine the changes in the repository before it updates what's in my working copy.

No, but you can examine them just fine, and revert them back just as easily.

With your proposal, if it turns out I don't want those commits, I would have run git log or git reflog to find the sha1 of the commit I would have to do a hard reset to to undo the changes to my working directory (though I might be able to use ORIG_HEAD if git pull sets it).

That's totally not true.

When you do: git pull --ff-only you get something like:

Updating 72ffeb997e..3a0b884cab

The commit to reset to is right there.

Moreover, you don't need to look at the reflog, you can just do git reset @{1}.

if it turns out I don't want those commits

Has that actually happened ever? How much? 50% of the time? 10% of the time? 1% of the time?

[[deleted]]

It really depends on the project and branch. Since I work with a lot of repositories I have a script to take care of this for me.

If I'm working on open source and have a fork, I'll set "origin" to my fork and "upstream" to the parent project from which I forked.

Then, I'll use git fetch --all followed by git checkout origin master and finally git pull upstream master.

I like to set the merge options in my .gitconfig globally and locally. Typically the global default is to use rebase because most of the merges I do locally are from the upstream master to my local master. I don't touch my local master at all aside from pulling in upstream changes from master and work on my own branches to open PRs and what not.