4 ms·

I disagree with this. I think the basic concept of Git is beautiful, but the implementation of some of the derivative operations are distinctly inelegant. For

I disagree with this. I think the basic concept of Git is beautiful, but the implementation of some of the derivative operations are distinctly inelegant. For example, I hate the use of "ours" and "theirs" in merges and rebases. I understand the theory of why it works the way it does and why it's different when merging versus rebasing, but I just think it's downright confusing, and I still have to double check every time to make sure I accept the right changes. I don't understand why they couldn't just use the branch name (or branch + commit hash).

yen223 4y ago
Something that comes to mind is that Github, as part of a "papercuts" initiative to fix small things, added an arrow that points from the "theirs" branch to the "our" branch in pull requests. That was such a huge improvement for me.
astrange 4y ago
One thing that confuses me about Git (but I guess isn't unique to it) is what happens when you merge and "git show" the merge commit. It seems the classes of changes are: - things that were the same on both sides so aren't in the diff - things that were different but auto merged, and aren't in the diff - things that were different, were auto merged, and are in the diff - merge conflicts But how did it distinguish the last 3? And how does it get so confident about #2 that it doesn't show them and there isn't a single command to show them? When hg was more popular I knew someone working on Google Code who told me it was better because it didn't have rebases, but I'm pretty rebases and linear history are safer than this.