upvote

points

by kungito3 hours ago |
comments
upvoteby flutetornado1 hours ago|
next
[-]
I ended up creating a personal vim plugin for merges one night because of a frustrating merge experience and never being able to remember what is what. It presents just two diff panes at top to reduce the cognitive load and a navigation list in a third split below to switch between diffs or final buffer (local/remote, base/local, base/remote and final). The list has branch names next to local/remote so you always know what is what. And most of the time the local/remote diff is what I am interested in so that’s what it shows first.
reply
upvoteby IgorPartola3 hours ago|
prev|
next
[-]
Let’s see if I get this wrong after 25 years of git:

ours means what is in my local codebase.

theirs means what is being merged into my local codebase.

I find it best to avoid merge conflicts than to try to resolve them. Strategies that keep branches short lived and frequently merging main into them helps a lot.

reply
upvoteby marcellus232 hours ago|
parent|
next
[-]
That's kind of the simplest case, though, where "theirs" and "ours" makes obvious sense.

What if I'm rebasing a branch onto another? Is "ours" the branch being rebased, or the other one? Or if I'm applying a stash?

reply
upvoteby IgorPartola2 hours ago|
parent|
[-]
> What if I'm rebasing a branch onto another?

Just checkout the branch you are merging/rebasing into before doing it.

> Or if I'm applying a stash?

The stash is in that case effectively a remote branch you are merging into your local codebase. ours is your local, theirs is the stash.

reply
upvoteby clktmr2 hours ago|
parent|
prev|
next
[-]
The thing is, you'll typically switch to master to merge your own branch. This makes your own branch 'theirs', which is where the confusion comes from.
reply
upvoteby IgorPartola2 hours ago|
parent|
[-]
Not me. I typically merge main onto a feature branch where all the conflicts are resolved in a sane way. Then I checkout main and merge the feature branch into it with no conflicts.

As a bonus I can then also merge the feature branch into main as a squash commit, ditching the history of a feature branch for one large commit that implements the feature. There is no point in having half implemented and/or buggy commits from the feature branch clogging up my main history. Nobody should ever need to revert main to that state and if I really really need to look at that particular code commit I can still find it in the feature branch history.

reply
upvoteby throwaway77837 minutes ago|
parent|
[-]
Yep. This is the only model that has worked well for me for more than a decade.
reply
upvoteby em-bee2 hours ago|
parent|
prev|
[-]
a better (more confusing) example:

i have a branch and i want to merge that branch into main.

is ours the branch and main theirs? or is ours main, and the branch theirs?

reply
upvoteby IgorPartola2 hours ago|
parent|
[-]
I always checkout the branch I am merging something into. I was vaguely aware I could have main checked out but merge foo into bar but have never once done that.
reply
upvoteby Sharlin2 hours ago|
parent|
[-]

  git checkout mybranch
  git rebase main
A conflict happens. Now "ours" is main and "theirs" is mybranch, even though from your perspective you're still on mybranch. Git isn't, however.
reply
upvoteby IgorPartola2 hours ago|
parent|
[-]
Ah that’s fair. This is why I would do a `git merge main` instead of a rebase here.
reply
upvoteby ljm1 hours ago|
parent|
[-]
I have met more than one person who would doggedly tolerate rebase, not even using rerere, instead of doing a simple ‘git merge --no-ff’ to one-shot it, not understanding that rebase touches every commit in the diff between main and not simply the latest change on HEAD.

Not a problem if you are a purist on linear history.

reply
upvoteby afiori2 hours ago|
prev|
next
[-]
iirc ours is always the commit the merge is starting from. the issue is that with a merge your current commit is the merging commit while with a rebase it is reversed.

I suspect that this could be because the rebase command is implemented as a serie of merges/cherry-picks from the target branch.

reply
upvoteby Sharlin2 hours ago|
parent|
next
[-]

  git checkout mybranch
  git rebase main
Now git takes main and starts cloning (cherry-picking, as you said) commits from mybranch on top of it. From git's viewpoint it's working on top of main, so if a conflict occurs, main is "ours" and mybranch is "theirs". But from your viewpoint you're still on mybranch, and indeed are left on mybranch when the rebase is complete. (It's a different mybranch, of course; once the rebase is completed, git moves mybranch to point to the new (detached) HEAD.) Which makes "ours" and "theirs" exactly the opposite of what the user expects.
reply
upvoteby orthoxerox1 hours ago|
parent|
next
[-]
I had to make an alias for rebasing, because I kept doing the opposite:

    git checkout master #check out the branch to apply commits to
    git rebase mybranch #Apply all commits from mybranch
Now I just write

    rebase-current-branch
and it does what I want: fetches origin/master and rebases my working branch on top of it.

But "ours"/"theirs" still keeps tripping me up.

reply
upvoteby XorNot1 hours ago|
parent|
prev|
[-]
Man do I hate this behavior because it would be really some by just using the branch names rather then "ours" and "theirs"
reply
upvoteby awesome_dude2 hours ago|
prev|
[-]
This is one of my pain points, and one time I googled and got the real answer (which is why it's such a pain point).

That answer is "It depends on the context"

> The reason the "ours" and "theirs" notions get swapped around during rebase is that rebase works by doing a series of cherry-picks, into an anonymous branch (detached HEAD mode). The target branch is the anonymous branch, and the merge-from branch is your original (pre-rebase) branch: so "--ours" means the anonymous one rebase is building while "--theirs" means "our branch being rebased".[0]

[0] https://stackoverflow.com/questions/25576415/what-is-the-pre...

reply