> 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.
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.
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).
13 comments
[ 4.9 ms ] story [ 198 ms ] threadI 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.
git reflog can easily rollback a rebase.
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.
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.
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).
http://stackoverflow.com/questions/15316601/in-what-cases-co...
The top-voted answer has a pretty handy alias: