|
| ▲ | flutetornado an hour ago | parent | 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. |
|
| ▲ | IgorPartola 2 hours ago | parent | 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. |
| |
| ▲ | marcellus23 2 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? | | |
| ▲ | IgorPartola 2 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. |
| |
| ▲ | clktmr 2 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. | | |
| ▲ | IgorPartola 2 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. |
| |
| ▲ | em-bee 2 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? | | |
| ▲ | IgorPartola 2 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. | | |
| ▲ | Sharlin 2 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. | | |
| ▲ | IgorPartola an hour ago | parent [-] | | Ah that’s fair. This is why I would do a `git merge main` instead of a rebase here. | | |
| ▲ | ljm an hour 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. |
|
|
|
|
|
|
| ▲ | afiori 2 hours ago | parent | 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. |
| |
| ▲ | Sharlin 2 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. | | |
| ▲ | orthoxerox an hour 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. | |
| ▲ | XorNot an hour 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" |
| |
| ▲ | devnotes77 2 hours ago | parent | prev [-] | | [dead] |
|
|
| ▲ | awesome_dude 2 hours ago | parent | 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... |
