← Back to context

Comment by pwdisswordfishy

1 month 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.

11 comments

pwdisswordfishy

Reply
Brian_K_White  1 month 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  1 month 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  1 month 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.

      1 reply →