Never* use Git pull [video] | Hacker News Reader

Never* use Git pull [video]

youtube.com

25 pointsbenfreu20 comments

I feel like this is "solving" a problem that doesn't exist in good workflows. How often are you pulling from a shared branch that you are making local commits to? Each of the people in the video should be branching off main and doing pull requests to get back into main.

All that shared branch needs is submodules to bump that workflow from Ultraviolent to Nightmare difficulty.

> How often are you pulling from a shared branch that you are making local commits to

When more than one dev is working on a feature branch? You could take feature/a, branch off feature/a.1 for your local work but at some point you gotta incorporate work from feature/a. Not so different from origin/main -> main.

git pull --ff-only should really be the default (changeable) behavior.

The other choice being git pull --rebase, with "git merge" being removed from the git suite.

> How often are you pulling from a shared branch that you are making local commits to?

Every working/hobbying day for the past decade and a half.

Got a chuckle from this one

Like anyone gives a raccoon's ass about what they "should" be doing.

I've not used "git pull" since 2010. I always "git fetch" remote objects, and rebase with an explicit "git rebase".

Isn't that what "git pull --rebase" does?

I've had it enabled by default for years and years. It's always what I want.

    [pull]
      rebase = true

I did that for several months in 2010. It's too error prone; you will forget to have that configured somewhere and get a merge by mistake.

So then I trained myself on "pull --rebase". I soon realized, I don't want to be combining fetch and rebase. The best way was to just scrub the pull command from the vocabulary.

It's fine nowadays but there was a time when "git pull --rebase" worked slightly differently to "git fetch" and "git rebase". I'd get conflicts with the former that I didn't get with the latter.

I don't rebase immediately after a git fetch. I look at what is new first. I might not rebase over all of it. E.g. the first three commits may have something I need to pick up, but then after that there may be something I don't want to integrate with yet.

Great explanation, just last week I was explaining these concepts to a new dev in our team. The visuals are really helpful to get the point across.

Finally someone can explain something in an understandable way. This guy should be an educator.

Awesome! I completely agree with this approach. I use a slightly different alias, but that's it.

It provides a clean commit history, without actually rewriting the commit history.

I wish more developers in the company used this approach.

don't forget autostash

alias gupa="git pull --rebase --autostash"

whoa, autostash is brilliant

I think that at the point in the workflow where you are ready to get some new changes from upstream and integrate with your local ones, you're probably going to have all your outstanding work in a commit.

A rebase that is part of a pull, together with auto-stash, doesn't make a whole lot of sense.

I've never run into the problem of not being able to rebase due to uncommitted changes, except in two situations:

- suddenly wanting to rewrite something in the branch, unrelated to the in-progress work.

- working in a badly structured project whose builds alter tracked files

isn’t this what —ff-only is for?

Reply on news.ycombinator.com