undefined | Better HN

0 pointsCentigonal4y ago0 comments

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).

0 comments

2 comments · 2 top-level

astrange4y 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.

yen2234y 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.

j / k navigate · click thread line to collapse