1

I've found a raft of answers here for the case when resetting and/or rebasing (and thus rewriting history) are allowed, but what can one do when you've freshly cloned a repo, checked out and pulled branch A and branch B, then on branch B and git merge A returns Already up to date. despite the fact git diff A clearly shows a non-trivial delta?

One way I know of is to back-merge B to A, correct the issue on A and then merge that to B (effectively a no-op on A). But that means changing the source branch, and I feel that shouldn't be necessary.

So, is there a way to tell git to merge everything from A so that B matches A without resetting/rebasing, without needing to do anything to A (since A is exactly as I want things to begin with), and without adding another commit to B that simply compounds the issue (as this is one way to cause the very problem I'm trying to solve)?

(To emphasize, this is from a freshly cloned and pulled repo, so I have no tricks to use (if this would create a merge commit at all, I could correct things and amend it before pushing, but the problem is there is no merge commit at all.)

I suspect there may not be, and the only clean way (given that I can't rewrite history in this case) will involve (back)merges to A. But, git is rich and full of wonders, so I thought it would be worth asking here.

MartyMacGyver
  • 9,483
  • 11
  • 47
  • 67
  • see https://stackoverflow.com/q/4911794/1256452 – torek Nov 15 '19 at 07:38
  • From branch B I've tried `git merge A --strategy=recursive -X=theirs` (or `ours`) to the same effect. The other strategies seem to resolve around some variation of rewriting history or checking out the differing files from A and committing them to B (which isn't as automatic as a merge might be but it does avoid backtracking to dev). However, I've seen side effects in that case, when the same file gets modified later and a normal merge becomes unduly complex. Perhaps merging back to A and then merging a fix from A to B is the only way to properly rectify the commit graph. – MartyMacGyver Nov 15 '19 at 08:02
  • No, don't use `-X` arguments. See VonC's massive compilation of equivalents to `-s theirs`. Also, see the *not*-accepted answers [here](https://stackoverflow.com/q/173919/1256452), especially [jthill's](https://stackoverflow.com/a/16526138/1256452). – torek Nov 15 '19 at 08:04
  • Can you post the commit logs for both branches? – BenKoshy Nov 15 '19 at 10:03
  • I don't understand why there is a material difference when there shouldn't be. Can you post a screen share video of what you're doing so wee can verify you haven't missed something? – BenKoshy Nov 15 '19 at 10:18

3 Answers3

1

The message means : B is ahead of A, so the merge action does not understand what it should merge.

(edit : re-read your question ... )

If you want to set the content back to "what it was in A" : this is not a merge action, this is a matter of setting back, on disk or in the index, the content to what it was in A.

  • if you have git version 2.23 or later : look at git restore A

  • if you have an older git :

    # apply the diff between B and A to B :
git diff -p B A | git apply --index -

# commit
git commit
LeGEC
  • 46,477
  • 5
  • 57
  • 104
0

My suggestion is to create a new branch and delete B (after cherry-picking what's needed from B, if necessary).

tymtam
  • 31,798
  • 8
  • 86
  • 126
-1

Try:

git checkout master
git reset --hard <branch>
git push --force origin master
Bru
  • 84
  • 5
  • This is exactly what I'm not looking for - I am specifically avoiding rewriting history on the remote server, and the reset is immaterial (there is nothing to reset - consider this a clean initial clone of some external repo that has this existing disjoint as described). – MartyMacGyver Nov 15 '19 at 07:44