Hacker News Reader

Comment by aeinbu | Hacker News Reader

> I always use VS Code for this step. Its merge conflict UI is the clearest I’ve found: it shows “Accept Current Change,” “Accept Incoming Change,” “Accept Both Changes,” and “Compare Changes” buttons right above each conflict.

I still get confused by vscode’s changing the terms used by Git. «Current» vs «incoming» are not clear, and can be understood to mean two different things.

- Is “current” what is on the branch I am rebasing on? Or is it my code? (It’s my code)

- Is “incoming” the code I’m adding to the repo? Or is it what i am rebasing on to? (Again, the latter is correct)

I find that many tools are trying to make Git easier to understand, but changing the terms is not so helpful. Since different tools seldom change to the same words, it just clutters any attempts to search for coherent information.

View on HN

Git's "ours"/"theirs" terminology is often confusing to newcomers, especially when from a certain (incorrect, but fairly common) point of view their meaning may appear to be swapped between merge and rebase. I think in an attempt to make the terminology less confusing UIs tend to reinvent it, but they always fail miserably, ending up with the same problem, just with slightly different words.

This constant reinvention makes the situation even worse, because now the terminology is not only confusing, but also inconsistent across different tools.

We use SVN at work and it's a nightmare there too, "mine" and "theirs" and whatnot. I frequently end up looking at historical versions just to verify which is which.

If I have a merge conflict I typically have to be very conscious about what was done in both versions, to make sure the combination works.

I wish for "working copy" and "from commit 1234 (branch xyz)" or something informative, rather than confusing catch-all terms.

Please tell me you are using Git-SVN or Hg-SVN. Using bare SVN as a client hasn't been necessary in over a decade.

Using SmartSVN which makes life a fair bit better but still keeps this confusing terminology.

We'll be migrating to Git this year though so.

For reference, the codebase is over 20 years old, and includes binary dependencies like libraries. Makes it easy to compile old versions when needed, not so easy on the repository size...

That terminology is identical in git, likely inspired by cvs and svn, so that bit probably won't improve.

It's inherently confusing to juggle different trees, and clearly you need some terminology for it. At least this one has become a bit of a standard.

Main reason is we have relatively few merge conflicts despite merging a lot. So I always forget between instances.

I think even presenting them as options makes it even more confusing to newcomers. Usually I find that neither is correct and there's a change on both sides I need to manually merge (so I don't even pay attention to the terminology), but I've seen co-workers just blindly choose their changes because it's familiar looking then get confused when it doesn't work right.

For merges current is the branch you are on, for rebases it helps to see them as a serie of cherry picks, so current would be the branch you would be on while doing the cherry pick equivalent to this step of the rebase.

Reply on news.ycombinator.com