4 ms·
I don't get why people hate merges so much; it records the history of what actually happened, which seems like a nice default. I find it can be helpful for trac
by dilap 13y ago
I don't get why people hate merges so much; it records the history of what actually happened, which seems like a nice default. I find it can be helpful for tracking regressions, even on private branches that never get pushed.
- jheriko 13y agome too. the only reason i can see is laziness when looking at history because merges clutter it, but even then the fix should be in some front-end tool and not git itself. as a real world example bitbucket added a cool feature recently where they grey out merge commits. personally i love rich and complete history, including merge commits - any practice that damages that is something i'll be highly reticent about adopting. irl i generally don't need to time travel to achieve my goals...
- sdesol 13y ago"as a real world example bitbucket added a cool feature recently where they grey out merge commits" Interesting. I went a different route by making it very easy for users to dissect a merge commit. For example, if you click on the "Find included commits" link in the first commit at: http://ny.testdrive.gitsense.com/index?#pid=13&cid=20&trail= http://ny.testdrive.gitsense.com/index?#pid=13&cid=20&trail= you'll be able to see all the commits that it included.
- YZF 13y agoThe problem isn't history. The problem is meaningless history. If I'm working on file X and meanwhile file Y changes on the remote repository and those have nothing to do with each other you shouldn't need to do a merge. Merges should reflect situations where related changes happen concurrently. Otherwise it's just clutter and you can no longer separate the "true" merges from the noise.