5 ms·

New to me was discovering within the last month that git-merge doesn't have a merge strategy of "null": don't try to resolve any merge conflicts, because I've a

New to me was discovering within the last month that git-merge doesn't have a merge strategy of "null": don't try to resolve any merge conflicts, because I've already taken care of them; just know that this is a merge between the current branch and the one specified on the command-line, so be a dutiful little tool and just add it to your records. Don't try to "help". Don't fuck with the index or the worktree. Just record that this is happening. That's it. Nothing else.

Brian_K_White 9mo ago
What does that even mean? There already is reset hard.
- pwdisswordfishy 9mo ago
  What do you mean, "What does it mean?" It means what I wrote. > There already is reset hard. That's not... remotely relevant? What does that have to do with merging? We're talking about merging.
  - Brian_K_White 9mo ago
    Neither of these are answers or explainations. So you said nothing, and then said nothing again. I also "mean what I wrote". Man that was sure easy to say. It's almost like saying nothing at all. Which is anyone's righ to do, but it's not an argument, nor a definition of terms, nor communication at all. Well, it does communicate one thing.
    - pwdisswordfishy 9mo ago
      This: > don't try to resolve any merge conflicts ... Don't try to "help". Don't fuck with the index or the worktree. ... certainly is "nothing" in the literal sense--that that's what is desired of git-merge to do, but it's not "nothing" in the sense that you're saying. git reset --hard has nothing to do with merging. Nothing. They're not even in the same class of operations. It's absolutely irrelevant to this use case. And saying so isn't "not an argument" or not communicating anything at all. git reset --hard does not in any sense effect a merge. What more needs to be (or can be) said? If you want someone to help explain something to you, it's up to you to give them an anchor point that they can use to bridge the gap in understanding. As it stands, it's you who's given nothing at all, so one can only repeat what has already been described-- A resolution strategy for merge conflicts that involves doing nothing: nothing to the files in the current directory, staging nothing to be committed, and in fact not even bothering to check for conflicts in the first place. Just notate that it's going to be a merge between two parents X and Y, and wait for the human so they have an opportunity to resolve the conflicts by hand (if they haven't already), for them to add the changes to the staging area, and for them to issue the git-commit command that completes the merge between X and Y. What's unclear about this?
      - kbolino 9mo ago
        I think this is what you want: git merge -s ours --no-ff --no-commit <branch> This will initiate a merge, take nothing from the incoming branch, and allow you to decide how to proceed. This leaves git waiting for your next commit, and the two branches will be considered merged when that commit happens. What you may want to do next is: git checkout -p <branch> This will interactively review each incoming change, giving you the power to decide how each one should be handled. Once you've completed that process, commit the result and the merge is done.
        deleted 9mo ago
        [deleted]
      - deleted 9mo ago
        [deleted]
      - seba_dos1 9mo ago
        You know that you can edit your merge commits any way you want and you don't have to rely on resolution strategies to do it for you, right?
        pwdisswordfishy 9mo ago
        Right. That's the entire basis for the discussion here. So why is this a question?
        seba_dos1 9mo ago
        Because you already have all the needed tools to handle your special little edge case (in multiple ways!), so the discussion seems rather pointless.
        pwdisswordfishy 9mo ago
        You are confused. It's frightening that someone would be able to reach a point this deep into the discussion and think that "You know that you can edit your merge commits any way you want and you don't have to rely on resolution strategies to do it for you" is revealing something new or insightful.
- kbolino 9mo ago
  The name "null" is confusing; you have to pick something. However, I think what is desired here is the "theirs" strategy, i.e. to replace the current branch's tree entirely with the incoming branch's tree. The end result would be similar to a hard reset onto the incoming branch, except that it would also create a merge commit. Unfortunately, the "theirs" strategy does not exist, even though the "ours" strategy does exist, apparently to avoid confusion with the "theirs" option [1], but it is possible to emulate it with a sequence of commands [2]. [1]: https://git-scm.com/docs/merge-strategies#Documentation/merge-strategies.txt-theirs https://git-scm.com/docs/merge-strategies#Documentation/merg... [2]: https://stackoverflow.com/a/4969679/814422 https://stackoverflow.com/a/4969679/814422
valleyer 9mo ago
Doesn't `git merge -s ours` do this? This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the ort merge strategy.

Brian_K_White 9mo ago

What does that even mean? There already is reset hard.

pwdisswordfishy 9mo ago
What do you mean, "What does it mean?" It means what I wrote. > There already is reset hard. That's not... remotely relevant? What does that have to do with merging? We're talking about merging.
- Brian_K_White 9mo ago
  Neither of these are answers or explainations. So you said nothing, and then said nothing again. I also "mean what I wrote". Man that was sure easy to say. It's almost like saying nothing at all. Which is anyone's righ to do, but it's not an argument, nor a definition of terms, nor communication at all. Well, it does communicate one thing.
  - pwdisswordfishy 9mo ago
    This: > don't try to resolve any merge conflicts ... Don't try to "help". Don't fuck with the index or the worktree. ... certainly is "nothing" in the literal sense--that that's what is desired of git-merge to do, but it's not "nothing" in the sense that you're saying. git reset --hard has nothing to do with merging. Nothing. They're not even in the same class of operations. It's absolutely irrelevant to this use case. And saying so isn't "not an argument" or not communicating anything at all. git reset --hard does not in any sense effect a merge. What more needs to be (or can be) said? If you want someone to help explain something to you, it's up to you to give them an anchor point that they can use to bridge the gap in understanding. As it stands, it's you who's given nothing at all, so one can only repeat what has already been described-- A resolution strategy for merge conflicts that involves doing nothing: nothing to the files in the current directory, staging nothing to be committed, and in fact not even bothering to check for conflicts in the first place. Just notate that it's going to be a merge between two parents X and Y, and wait for the human so they have an opportunity to resolve the conflicts by hand (if they haven't already), for them to add the changes to the staging area, and for them to issue the git-commit command that completes the merge between X and Y. What's unclear about this?
    - kbolino 9mo ago
      I think this is what you want: git merge -s ours --no-ff --no-commit <branch> This will initiate a merge, take nothing from the incoming branch, and allow you to decide how to proceed. This leaves git waiting for your next commit, and the two branches will be considered merged when that commit happens. What you may want to do next is: git checkout -p <branch> This will interactively review each incoming change, giving you the power to decide how each one should be handled. Once you've completed that process, commit the result and the merge is done.
      - deleted 9mo ago
        [deleted]
    - deleted 9mo ago
      [deleted]
    - seba_dos1 9mo ago
      You know that you can edit your merge commits any way you want and you don't have to rely on resolution strategies to do it for you, right?
      - pwdisswordfishy 9mo ago
        Right. That's the entire basis for the discussion here. So why is this a question?
        seba_dos1 9mo ago
        Because you already have all the needed tools to handle your special little edge case (in multiple ways!), so the discussion seems rather pointless.
        pwdisswordfishy 9mo ago
        You are confused. It's frightening that someone would be able to reach a point this deep into the discussion and think that "You know that you can edit your merge commits any way you want and you don't have to rely on resolution strategies to do it for you" is revealing something new or insightful.
kbolino 9mo ago
The name "null" is confusing; you have to pick something. However, I think what is desired here is the "theirs" strategy, i.e. to replace the current branch's tree entirely with the incoming branch's tree. The end result would be similar to a hard reset onto the incoming branch, except that it would also create a merge commit. Unfortunately, the "theirs" strategy does not exist, even though the "ours" strategy does exist, apparently to avoid confusion with the "theirs" option [1], but it is possible to emulate it with a sequence of commands [2]. [1]: https://git-scm.com/docs/merge-strategies#Documentation/merge-strategies.txt-theirs https://git-scm.com/docs/merge-strategies#Documentation/merg... [2]: https://stackoverflow.com/a/4969679/814422 https://stackoverflow.com/a/4969679/814422

valleyer 9mo ago

Doesn't `git merge -s ours` do this? This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the ort merge strategy.