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/merg...

[2]: https://stackoverflow.com/a/4969679/814422

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.

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.

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?

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.

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?

Right. That's the entire basis for the discussion here. So why is this a question?

Because you already have all the needed tools to handle your special little edge case (in multiple ways!), so the discussion seems rather pointless.

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.

So it is pointless indeed, gotcha.

Your zero-insight comment was, indeed, pointless.