Re: git

[Robert <http://dummy.us.eu.org/robert>]

 > From: Jonathan Payne <http://www.payne-family.org/~jonathan>
 > Date: Mon, 28 May 2012 15:09:24 +0100
 >
 > Rebase is save in certain contexts and I have to admit I cannot remember 
 > entirely. It's explained in the little online book I recommended. Seriously 
 > give it a try. It's free unless you donate.
 > 
 > I use git pull --rebase now as well. Otherwise git creates merges for no good 
 > reason and the history looks really bad.

I understand the motivation.  But, when I tried "git pull --rebase foo"
(someone else's branch), that's when I fell into the merge rathole, never
to return.

I really wish it worked, but I think git tries to be smart about how to do
the merges and it ends up being too smart for me.  I'd rather stick to the
"dumb merge" and not risk going into a long set of merges, even if history
is unnecessarily duplicated.

That said, I'll look at the online book and buy the oreilly book.

 > But you cannot rebase everything. From 
 > Pro Git:
 > 
 > > 4.6.3. The Perils of Rebasing
 > > 
 > > Ahh, but the bliss of rebasing isn?t without its drawbacks, which can be 
 > > summed up in a single line:
 > > 
 > > Do not rebase commits that you have pushed to a public repository.
 > > 
 > > If you follow that guideline, you?ll be fine. If you don?t, people will hate 
 > > you, and you?ll be scorned by friends and family.
 >
 > So if you create some commits and push them to some public repository, and then 
 > you rebase those commits and push them again, well that really messes people up 
 > because rebasing commits apparently abandons your commits and creates new ones 
 > that are similar.
 > 
 > So I just do: git pull --rebase, which I think is quite safe because I am not 
 > using the rebase command specifically, which allows you to rebase stuff into 
 > other repositories apparently.
 > 
 > But yeah, what the heck!? Crazy stuff.
 > 
 > JP