

Merge vs. Rebase – A deep dive into the mysteries of revision control - angersock
http://blog.experimentalworks.net/2009/03/merge-vs-rebase-a-deep-dive-into-the-mysteries-of-revision-control/

======
VeejayRampay
This is all nice and dandy (as usual with git tutorials, which I find to focus
on what works great), but what about a long-lived feature branch where you
need to get the changes from your master branch into your feature branch on a
regular basis? Are you going to merge master into your branch? Are you going
to rebase? Whatever choice you make, it's going to be kind of sucky
experience, awful merges or a long series of resolving conflicts for each
commit replayed on top of the HEAD of your main branch, with random git rebase
--skip and "conflicted" files that you edit only to discover that the file
actually doesn't contain any conflict.

What about the famous:

\+ EMPTY_LINE

\- EMPTY_LINE

That for some reason I still get every other day in git diff outputs?

What about deleting a branch? Tough shit son, the branch is not fully merged,
BOOYA! Want to pull? BANG, merge bubble. Oh, you decided to be smart about it
and to git pull --rebase instead? Nah sister, you've pushed that code before
and you're now rewriting the history and screwing with it.

I don't know, it feels like there are no good choices in git, there's no
"right way", there's no workflow that guarantees your peace of mind. It's
always a fight. And the solutions to those problems are something that I never
see in the git tutorials and examples. It feels like informercials, you really
want to buy into it and go create branches, engage into interactive rebases
and git bisect into nasty bugs but after a few shots at it, it becomes the
software equivalent of that exercise bike collecting dust in the basement you
pretend not to see on your way to the backup fridge. The one that reminds you
how much you suck.

(Most of this tongue in cheek, I think git is great, it's just frustrating
sometimes)

~~~
luckydude
We (BitKeeper guys) have fought with this sort of problem a lot. In theory we
should be better than git at this stuff and in some cases we actually are, but
in some cases we are worse.

One class of problems that OP referred to is when you pull non-rebased csets
into a cset that has been rebased. If the contents on both sides are identical
I believe Git will handle that nicely (as will BK).

Where it gets hard is if you have changes on top of the history past the
rebase and past the rebase point on the other branch. The version control
system will think all of that crap is unique when only a little of it is.

Here's an example:

GCA:

A; B; C; D;

Left branch:

A; A2; B; C;

Right branch:

if (whatever) { A; B; C; D; }

Everybody currently makes this sort of thing hard to merge, it looks like a
bigger change than it is.

We're fixing it but it's a huge pile of heuristics that make me vomit.

