5 ms·

That still have an issue with the vocabulary. Things like "theirs/our" is still out of touch but it's already better than a loose spatial analogy on some repres

That still have an issue with the vocabulary. Things like "theirs/our" is still out of touch but it's already better than a loose spatial analogy on some representation of the DAG. Something like base, that is "common base", looks far more apt to my mind. In the same vein, endogenous/exogenous would be far more precise, or at least aligned with the concern at stake. Maybe "local/alien" might be a less pompous vocabulary to convey the same idea.

kungito 7mo ago
After 15 years i still cant remember which is which. I get annoyed every time. Maybe I should invest 15 minutes finally to remember properly
- IgorPartola 7mo ago
  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.
  - 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.
- afiori 7mo ago
  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.
  - devnotes77 7mo ago
    [dead]
  - Sharlin 7mo ago
    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.
    - XorNot 7mo ago
      Man do I hate this behavior because it would be really some by just using the branch names rather then "ours" and "theirs"
      - Sharlin 7mo ago
        Agreed. Even when the branch is the same, it would always be distinguishable by <remote-name>/<branch-name> vs. just <branch-name>.
    - orthoxerox 7mo ago
      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.
- awesome_dude 7mo ago
  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-precise-meaning-of-ours-and-theirs-in-git https://stackoverflow.com/questions/25576415/what-is-the-pre...
- flutetornado 7mo ago
  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.
- mamcx 7mo ago
  Seriously! Why not show the names of the branch + short Id (and when is not direct name, at least "this is from NAME")
  - sheept 7mo ago
    doesn't it? Next to the conflict markers, it'll display HEAD, the ref name, or the short commit hash.
    - cerved 7mo ago
      It does
    - KPGv2 7mo ago
      I'll be honest, as a fairly skilled and experienced programmer who isn't a git expert, I know what HEAD means, but when I'm rebasing I really have no idea. It all seems to work out in the end because my collaborative work is simple and usually 2–3 people only, so I'm never rebasing against a ton of commits I lack context for (because 90% of them are my commits since I'm usually dealing with PRs to my open source projects rather than someone else's). HEAD is "the thing we're editing now" but that's not terribly useful when rebasing since you're repeatedly editing a fake history.
      - lmm 7mo ago
        I avoid this problem by not rebasing.
        jimbobimbo 7mo ago
        Seriously! I have too many years of software development experience, but I use Visual Studio UX to handle pretty much all git operations. And always merge. I have better things to do in my life than "internalizing" anything that doesn't matter in the grand scheme of things.
        7mo ago
- tome 7mo ago
  It doesn't matter which is which. The resolution will be the same regardless.
- abm53 7mo ago
  [dead]
- goku12 7mo ago
  I was thinking about creating a TUI application that points out what each part in the conflict indicator corresponds to. This idea is primarily meant for rebases where the HEAD and the ID of the updated commits change constantly. Think of it as a map view of the rebase process, that improves your situational awareness by presenting all the relevant information simultaneously. That could trivially work for merges too.
wakawaka28 7mo ago
>Maybe "local/alien" might be a less pompous vocabulary to convey the same idea. That is more alien and just as contrived. If you merge branches that you made, they're both local and "ours". You just have to remember that "ours" is the branch you are on, and "theirs" is the other one. I have no idea what happens in an octopus merge but anyway, the option exists to show commit titles along with markers to help you keep it straight.
- psychoslave 7mo ago
  Indeed, thanks. Something that carry the meaning "the branch we want to use as a starting point" and "the other branch we want to integrate in the previous one" is what I had in mind, but it might not fit all situations in git merge/rebase.
  - wakawaka28 7mo ago
    Assuming you have to start on one of the branches being merged, "current" is a good name for the one you started on. "Other" is good enough for the other one. By the way I found out that octopus merges never succeed in case of conflicts. I'm not even sure if prerecorded resolutions work in that case. You're supposed to do a series of normal merges instead if you have conflicts.

kungito 7mo ago

After 15 years i still cant remember which is which. I get annoyed every time. Maybe I should invest 15 minutes finally to remember properly

IgorPartola 7mo ago
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.
- 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.
afiori 7mo ago
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.
- devnotes77 7mo ago
  [dead]
- Sharlin 7mo ago
  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.
  - XorNot 7mo ago
    Man do I hate this behavior because it would be really some by just using the branch names rather then "ours" and "theirs"
    - Sharlin 7mo ago
      Agreed. Even when the branch is the same, it would always be distinguishable by <remote-name>/<branch-name> vs. just <branch-name>.
  - orthoxerox 7mo ago
    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.
awesome_dude 7mo ago
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-precise-meaning-of-ours-and-theirs-in-git https://stackoverflow.com/questions/25576415/what-is-the-pre...
flutetornado 7mo ago
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.
mamcx 7mo ago
Seriously! Why not show the names of the branch + short Id (and when is not direct name, at least "this is from NAME")
- sheept 7mo ago
  doesn't it? Next to the conflict markers, it'll display HEAD, the ref name, or the short commit hash.
  - cerved 7mo ago
    It does
  - KPGv2 7mo ago
    I'll be honest, as a fairly skilled and experienced programmer who isn't a git expert, I know what HEAD means, but when I'm rebasing I really have no idea. It all seems to work out in the end because my collaborative work is simple and usually 2–3 people only, so I'm never rebasing against a ton of commits I lack context for (because 90% of them are my commits since I'm usually dealing with PRs to my open source projects rather than someone else's). HEAD is "the thing we're editing now" but that's not terribly useful when rebasing since you're repeatedly editing a fake history.
    - lmm 7mo ago
      I avoid this problem by not rebasing.
      - jimbobimbo 7mo ago
        Seriously! I have too many years of software development experience, but I use Visual Studio UX to handle pretty much all git operations. And always merge. I have better things to do in my life than "internalizing" anything that doesn't matter in the grand scheme of things.
        7mo ago
tome 7mo ago
It doesn't matter which is which. The resolution will be the same regardless.
abm53 7mo ago
[dead]
goku12 7mo ago
I was thinking about creating a TUI application that points out what each part in the conflict indicator corresponds to. This idea is primarily meant for rebases where the HEAD and the ID of the updated commits change constantly. Think of it as a map view of the rebase process, that improves your situational awareness by presenting all the relevant information simultaneously. That could trivially work for merges too.

wakawaka28 7mo ago

>Maybe "local/alien" might be a less pompous vocabulary to convey the same idea. That is more alien and just as contrived. If you merge branches that you made, they're both local and "ours". You just have to remember that "ours" is the branch you are on, and "theirs" is the other one. I have no idea what happens in an octopus merge but anyway, the option exists to show commit titles along with markers to help you keep it straight.

psychoslave 7mo ago
Indeed, thanks. Something that carry the meaning "the branch we want to use as a starting point" and "the other branch we want to integrate in the previous one" is what I had in mind, but it might not fit all situations in git merge/rebase.
- wakawaka28 7mo ago
  Assuming you have to start on one of the branches being merged, "current" is a good name for the one you started on. "Other" is good enough for the other one. By the way I found out that octopus merges never succeed in case of conflicts. I'm not even sure if prerecorded resolutions work in that case. You're supposed to do a series of normal merges instead if you have conflicts.