3 ms·
> If you imagine a VCS where merges didn't exist I've certainly used VCSes where merges didn't exist as a first class citizen. They are a huge pain to use, sti
by WorldMaker 6y ago
> If you imagine a VCS where merges didn't exist
I've certainly used VCSes where merges didn't exist as a first class citizen. They are a huge pain to use, still have to deal with merges and merge conflicts somehow, even if they just push all that work onto the user.
Git presents a DAG as a data structure. Forcing it into a "straight line", in my opinion, is a silly amount of work when you can use the power of a DAG, including filtering/culling your "depth" views into the DAG to manage it.
I understand that a straight line is "cleaner" and often easier to read. I'd rather use the power of the DAG to query straight lines than do a lot of work up front to artificially make straight lines. I understand that this is a difference of opinion you are unlikely to share, that's fine, there's no "one workflow" for everyone.
- u801e 6y agoEven if you filter out the merge commits, then you're hiding some of the changes made when you look at the history of the branch. The other problem is that if you run git blame on a file and the line is referenced by one of those merge commits, then the commit message is next to useless. Those looking at the history want to know why that line is there (changed from a previous version or added). A commit message that explains the reason and allows you to see that line in a context of a logical change makes it much easier to determine whether the change you're planning to make will introduce a regression or lead to some other issue. A merge commit message with a mixture of changes that may pertain to any number of commits in the branch doesn't help and makes it harder to figure out what the change was.