5 ms·

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 fin

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 7mo ago
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 7mo ago
  > 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.
- sheept 7mo ago
  "Ours" and "theirs" make sense in most cases (since "ours" refers to the HEAD you're merging into). Rebases are the sole exception (in typical use) because ours/theirs is reversed, since you're merging HEAD into the other branch. Personally, I prefer merge commits over rebases if possible; they make PRs harder for others to review by breaking the "see changes since last review" feature. Git generally works better without rebases and squash commits.
  - sebmellen 7mo ago
    Wow, interesting to see such a diametrically opposed view. We’ve banned merge commits internally and our entire workflow is rebase driven. Generally, I find that rebases are far better at keeping Git history clean and clearly allowing you to see the diff between the base you’re merging into and the changes you’ve made.
    - Ajedi32 7mo ago
      Yes, I prefer that approach as well because it allows the person who authored the change to do all the work of deciding how to resolve conflicts up front (and allows reviewers to review that conflict resolution) instead of forcing whoever eventually does the merge to figure everything out after the fact. It also removes conflicts from the history so you never have to think about them later after the rebase/merge process is finished.
    - ulrikrasmussen 7mo ago
      "Clean" is not the same as "useful". You have to be really, really disciplined to not make a superficially looking "clean" history which may appear linear but which is actually total nonsense. For example, if one is frequently doing "fix after rebase" commits, then they are doing it wrong and are making a history which is much less useful than a seemingly more complicated merge based history. Rebased histories are only clean if they also tell a true story after the rebase, but if you push "rebase fixes" onto the end of your history, then it means that prior rebased commits no longer make any sense because they e.g. use APIs that aren't actually there. Giving up and squashing everything to one commit is almost better in this case because it at least won't throw off someone who is trying to make sense of the history in the future. I think that rebasing has won over merges mostly because the tools for navigating git histories suck SO HARD. I have used Perforce at a previous job, and their graphical tools for navigating a merge based history are excellent and were really useful for doing code archeology.
      - sebmellen 7mo ago
        Generally our pattern is that every PR gets rebased into sensible commits. So in a way we are doing "squash commits" but the method is an interactive rebase. This keeps our history very pretty and clean, and simultaneously easy to grok and navigate. My favorite git GUI is Sublime Merge.
  - KPGv2 7mo ago
    > Git generally works better without rebases and squash commits. If squash commits make Git harder for you, that's a tell that your branches are trying to do too many things before merging back into main.
    - ralferoo 7mo ago
      I don't know. Even when I'm working on my own private repositories across several machines, I really, really dislike regular merges. You get an ugly commit message and I can never get git log to show me the information I actually want to see. For me, rebasing is the simplest and easiest to understand, and it allows you to squash some of your commits so that it's one commit per feature / bug-fix / logical unit of work. I'll also frequently rebase and squash commits in my work branch too, where I've temporarily committed something and then fixed a bug before it's been pushed into main, I'll just reorder and squash the relevant commits into one.
      - andy_ppp 7mo ago
        I completely agree, since doing rebase our history looks fantastic and it makes finding things, cherrypicking and generating changelogs really simple. Why not be neat, it's cost us nothing and you can make yourself a tutorial on Claude if you don't understand rebasing pretty easily.
    - andy_ppp 7mo ago
      Don't do squash commits, just rebase -i your branch before merging so you only have one commit. It's pretty trivial to do.
em-bee 7mo ago
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 7mo ago
  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 7mo ago
    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 7mo ago
      Ah that’s fair. This is why I would do a `git merge main` instead of a rebase here.
      - ljm 7mo ago
        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.
        em-bee 7mo ago
        not understanding that rebase touches every commit in the diff it sounds like that's a problem for you. why would that be? i prefer rebase and fast forward, but i am fully aware that rebase rewrites all commits.
clktmr 7mo ago
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 7mo ago
  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.
  - throwaway7783 7mo ago
    Yep. This is the only model that has worked well for me for more than a decade.
  - KPGv2 7mo ago
    This is what I do, and I was taught by an experienced Git user over a decade ago. I've been doing it ever since. All my merges into main are fast forwards.
KPGv2 7mo ago
> ours means what is in my local codebase Since it's always one person doing a merge, why isn't it "mine" instead of "ours"? There aren't five of us at my computer collaboratively merging in a PR. There is one person doing it. "Ours" makes it sound like some branch everyone who's working on the repo already has access to, not the active branch on my machine.
- itintheory 7mo ago
  That's between you and git.
imiric 7mo ago
> Let’s see if I get this wrong after 25 years of git You used it 5 years before Linus? Impressive!
- IgorPartola 7mo ago
  Haha yes. You caught me :) I was wondering when someone was going to point it out. I actually have only been using it since about 2009 after a brief flirtation with SVN and a horrible breakup with CVS.

marcellus23 7mo ago

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 7mo ago
> 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.
sheept 7mo ago
"Ours" and "theirs" make sense in most cases (since "ours" refers to the HEAD you're merging into). Rebases are the sole exception (in typical use) because ours/theirs is reversed, since you're merging HEAD into the other branch. Personally, I prefer merge commits over rebases if possible; they make PRs harder for others to review by breaking the "see changes since last review" feature. Git generally works better without rebases and squash commits.
- sebmellen 7mo ago
  Wow, interesting to see such a diametrically opposed view. We’ve banned merge commits internally and our entire workflow is rebase driven. Generally, I find that rebases are far better at keeping Git history clean and clearly allowing you to see the diff between the base you’re merging into and the changes you’ve made.
  - Ajedi32 7mo ago
    Yes, I prefer that approach as well because it allows the person who authored the change to do all the work of deciding how to resolve conflicts up front (and allows reviewers to review that conflict resolution) instead of forcing whoever eventually does the merge to figure everything out after the fact. It also removes conflicts from the history so you never have to think about them later after the rebase/merge process is finished.
  - ulrikrasmussen 7mo ago
    "Clean" is not the same as "useful". You have to be really, really disciplined to not make a superficially looking "clean" history which may appear linear but which is actually total nonsense. For example, if one is frequently doing "fix after rebase" commits, then they are doing it wrong and are making a history which is much less useful than a seemingly more complicated merge based history. Rebased histories are only clean if they also tell a true story after the rebase, but if you push "rebase fixes" onto the end of your history, then it means that prior rebased commits no longer make any sense because they e.g. use APIs that aren't actually there. Giving up and squashing everything to one commit is almost better in this case because it at least won't throw off someone who is trying to make sense of the history in the future. I think that rebasing has won over merges mostly because the tools for navigating git histories suck SO HARD. I have used Perforce at a previous job, and their graphical tools for navigating a merge based history are excellent and were really useful for doing code archeology.
    - sebmellen 7mo ago
      Generally our pattern is that every PR gets rebased into sensible commits. So in a way we are doing "squash commits" but the method is an interactive rebase. This keeps our history very pretty and clean, and simultaneously easy to grok and navigate. My favorite git GUI is Sublime Merge.
- KPGv2 7mo ago
  > Git generally works better without rebases and squash commits. If squash commits make Git harder for you, that's a tell that your branches are trying to do too many things before merging back into main.
  - ralferoo 7mo ago
    I don't know. Even when I'm working on my own private repositories across several machines, I really, really dislike regular merges. You get an ugly commit message and I can never get git log to show me the information I actually want to see. For me, rebasing is the simplest and easiest to understand, and it allows you to squash some of your commits so that it's one commit per feature / bug-fix / logical unit of work. I'll also frequently rebase and squash commits in my work branch too, where I've temporarily committed something and then fixed a bug before it's been pushed into main, I'll just reorder and squash the relevant commits into one.
    - andy_ppp 7mo ago
      I completely agree, since doing rebase our history looks fantastic and it makes finding things, cherrypicking and generating changelogs really simple. Why not be neat, it's cost us nothing and you can make yourself a tutorial on Claude if you don't understand rebasing pretty easily.
  - andy_ppp 7mo ago
    Don't do squash commits, just rebase -i your branch before merging so you only have one commit. It's pretty trivial to do.

em-bee 7mo ago

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 7mo ago
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 7mo ago
  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 7mo ago
    Ah that’s fair. This is why I would do a `git merge main` instead of a rebase here.
    - ljm 7mo ago
      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.
      - em-bee 7mo ago
        not understanding that rebase touches every commit in the diff it sounds like that's a problem for you. why would that be? i prefer rebase and fast forward, but i am fully aware that rebase rewrites all commits.

clktmr 7mo ago

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 7mo ago
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.
- throwaway7783 7mo ago
  Yep. This is the only model that has worked well for me for more than a decade.
- KPGv2 7mo ago
  This is what I do, and I was taught by an experienced Git user over a decade ago. I've been doing it ever since. All my merges into main are fast forwards.

KPGv2 7mo ago

> ours means what is in my local codebase Since it's always one person doing a merge, why isn't it "mine" instead of "ours"? There aren't five of us at my computer collaboratively merging in a PR. There is one person doing it. "Ours" makes it sound like some branch everyone who's working on the repo already has access to, not the active branch on my machine.

itintheory 7mo ago
That's between you and git.

imiric 7mo ago

> Let’s see if I get this wrong after 25 years of git You used it 5 years before Linus? Impressive!

IgorPartola 7mo ago
Haha yes. You caught me :) I was wondering when someone was going to point it out. I actually have only been using it since about 2009 after a brief flirtation with SVN and a horrible breakup with CVS.