Hoo boy is it fun to figure out where things went wrong when the real commit history was thrown away to make it look prettier. Especially a mistake from a merge conflict.

▲

hinkley 4 days ago | parent [-]

I had to stop two devs from fisticuffs. One of them used merge and manufactured a bug in the other’s code and was making a stink about it in the middle of the cubicles.

Merges lie I worse ways than rebase does. Hands down. With rebase I break my own shit. With merge I can break yours. Since your code is already merges into trunk, it has fewer eyes on it now and it’s on me to make sure my code works with yours and not vice versa.

▲

anonymars 4 days ago | parent [-]

I don't follow. In either case two branches are combined into one:

With a merge commit anyone can see each original path, and the merge result (with its author), and even try the three-way merge again. With a rebase, the original context is lost (the original commits were replaced by the rebased versions).

A rebase is a lossy projection of the same operation. A rebase lies about its history, a merge does not.

▲

hinkley 4 days ago | parent [-]

Merge with conflicts can be resolved with changes in code that don’t belong to the person who resolved the merge, and are not attributed to the person who resolved the merge. Git blame shows someone else as the person who introduced the bug. When you do a rebase you’re only modifying your own commits, or those of someone sharing your branch.

	▲	anonymars 3 days ago \| parent [-]
		I'd really like to see an example of what you mean. Are you saying a git blame is attributing code to a person who did not write that code? Are cherry picks involved (which also screw up history)? https://devblogs.microsoft.com/oldnewthing/20180313-00/?p=98...