News for hackers. Stuff that matters.
Re:Git rebase and the golden rule explained by esaym on Sunday February 28, 2016 @05:48PM (#11192767)
Posts like these make me feel like I don't know anything about git even though I've been using it forever.

I normally always do git pull --rebase. Is that bad or what is being talked about here? I never liked normal 'git pull' as it muddies up the logs with merge commit messages if there are changes upstream.

Most docs say pull with rebase is cleaner[1]

[1]http://gitready.com/advanced/2009/02/11/pull-with-rebase.htm...

Re:Git rebase and the golden rule explained by keymon on Friday March 04, 2016 @08:42PM (#11228022)
Yes, I do use git pull --rebase constantly when pairing. If everybody uses it, no problems, just simply works.

I have been seen only issues and completely messed up git histories when some other colleague completely refused to do pull+rebase, arguing was not professional.

So, in my experience, you will have problems if in your team does pull+rebase and other does a simple pull :)

Re:Git rebase and the golden rule explained by hbogert on Monday February 29, 2016 @06:47AM (#11194906)
There is nothing wrong in itself with keeping up-to-date with master by rebasing. That's not the issue which is described by the link. The main problem is that the feature branch is being actively developed on by multiple persons.

The problem arises when, you rebase commits which have already been shared. The smoking gun is that you need to force-push, i.e., rewriting someone else's history (in other words "messing" up someone's chain of commits.)

Re:Git rebase and the golden rule explained by pmoriarty on Sunday February 28, 2016 @06:15PM (#11192854)
Instead of doing a "git pull", some people[1] advise doing a "git fetch" followed by a "git merge".

[1] - http://longair.net/blog/2009/04/16/git-fetch-and-merge/