Stop using Git pull, install git-up. | Hacker News Reader

Stop using Git pull, install git-up.

github.com

18 pointsvolent13 comments

> which means git push will shout at you for being behind on branches you don't particularly care about right now.

I think that behavior has been changed in recent git, so by default it only pushes the branch you are on? (And the default is settable either way, even in slightly less recent versions).

But I can see some workflows git-up would be useful for. For me, not useful enough to deal with installing a plugin (with all that entails, including risk of bugs). Plus, while rebase is sometimes what you want, sometimes I really do want a pull, and the consequences of doing a rebase when you wanted a pull can be disastrous and hard to undo, and I'd be scared of a tool that defaulted to rebases everywhere.

>the consequences of doing a rebase when you wanted a pull can be disastrous and hard to undo

git reflog can easily rollback a rebase.

I realize it can be done, I generally don't find it easy, cause I have to remind myself how to do it, and it is a somewhat manual process of making sure you've found the right point to rollback to, etc.

And of course, if you've made subsequent commits after the rebase but before you notice the mistake -- still can be done, but less and less easy.

On the other hand, if you pull when you meant to rebase, that's somewhat easier and less error-prone to switch. For me anyway. ymmv.

Yes, the default since git 2.0 is simple push which just pushes the branch you are on. It can also be set since I think git 1.8.

I don't understand the issues that are being presented by this plugin and I really don't like the tone of the whole thing. If you understand push and pull the workflow is pretty simple, even in large groups.

Why use something that's tested and known to work when you can use a plugin no one's ever heard of with a glib, vaguely insulting description and no Windows support?

Merge commits from pulls really bothered me at first, but as I've used git more I've realized that the hoops you jump through to always rebase and avoid them aren't always worth it. A merge commit might clutter up your git log, but it does more accurately describe what happened.

Further discussion on why 'git pull' can be considered harmful here:

http://stackoverflow.com/questions/15316601/in-what-cases-co...

The top-voted answer has a pretty handy alias:

  git config --global alias.up '!git remote update -p; git merge --ff-only @{u}'

"Best practice is to delete your Hacker News account before installing" you won't get a lot of upvotes...

It isn't particularly hard not to use git pull,

    git fetch origin
    git rebase origin/develop

This is really the only sane way to develop once you're past a certain team size.

[How] is this different from `git pull --rebase`?

I'm not sure if its different, but when you call `git pull` with no extra arguments (i.e. you don't specify the remote or the branch) then it behaves differently depending which branch you're on, and what your local Git config is. So, personally, I prefer to always be fully explicit in my Git commands.

And does calling `git pull --rebase` just rebase your current branch against its remote equivalent? But usually I find myself working on a feature branch that is often rebased against a parent branch, `develop` (for example).

Or just do git fetch && git rebase origin/whatever or git fetch && git checkout origin/whatever if you just plan to use code(simple update mechanism).

Reply on news.ycombinator.com