4 ms·
> I run my gr alias for git pull --rebase to bring in the new changes The mistake was blindly using git rebase. History rewriting (which includes not only reba
by cesarb 10y ago
> I run my gr alias for git pull --rebase to bring in the new changes
The mistake was blindly using git rebase. History rewriting (which includes not only rebase but also amend) should be done with care, and never on history which has already been published (with a few special exceptions, but unless you really know what you're doing -- don't).
The correct thing to do, since the commit was already pushed, would have been "git pull" without the --rebase, and then pushing the resulting merge commit. Getting in the habit of doing "git pull --rebase" every time is not a good idea; better have a "dirtier" history full of merges, than have to untangle messes like this one later.
- skolsuper 10y agoThe commit wasn't already pushed though. The problem was with the semantics of a 'tag' in git being immutable, and not being rebased along with the commit and the branch, then getting pushed anyway.
- zzalpha 10y agoI don't even like the habit of using "git pull". When training folks I start by introducing them to "git fetch" and manually merging or rebasing on the remote tracking branch so they're fully in control of the process while understanding what's going on. Only after people grok that do I mention "git pull", and only in passing while discouraging its use.
- rimantas 10y agoSo basically you want them each time to do the job that git pull does right 99.999% of the time?
- MichaelBurge 10y agoI don't know about him, but yes it's what I do too and I recommend it.
- svens_ 10y agoI agree with that. I have an alias for "git pull --ff-only", which I use often though. It's faster than manually doing the fetch and then merge/rebase. If it succeeds you're at the newest version, if not you can still decide whether to merge or rebase. This should be the default behavior for git pull in my opinion.