0

Is there a way to "remerge" from master at a certain commit, as if I had never tried to git merge master since that point in time?

Edit: I resolved my issue. Turns out I'm just new to git and was confused about basics of merging and conflicts. I'm rewriting this question now so that it makes sense to seasoned git users, but I'm going to keep some elements of my confusion / misguided thoughts, so that newbies having the same problem searching the same things, end up here.

tl;dr

  1. I panicked, backed up files, created a new branch, restored my files, and now I have diffs I don't recognize.

ntl;r

  1. I was working off a local branch over several days.
  2. A lot of people work on this repository. To keep in sync, I periodically git merge mastered.
  3. Something went really wrong, and panicking, I cp -Red to back up my source.
  4. I disowned that branch and created a new one from master.
  5. I cp -Red my backup back, intentionally overwriting the copy of the latest master.
  6. I did a git diff, only to see hundreds of diffs I didn't recognize.

Analysis

I realize my mistake. Just copying / clobbering files means: no git history. That is, all my individual incremental commits as well as merges of others' commits from master, got "flattened" into a meta-data-less, dumb copy of text files. Once "restoring" my backup, it looks to git like I just made one giant change, with no trail of what's what. And because at the time I made my backup, I hadn't fully git merge mastered, i.e. there were commits on the latest master I had never seen, I essentially reverted these from the latest master by clobbering with an old backup. Again: with no trail.

Proposed Solution

As a newbie, the solution to this, I thought, might be to: retrigger a git merge master from a point in time (a commit) that I know I did already merge, thereby generating conflicts. Then, I thought I could simply Accept Theirs on all conflicts, since for any file or code I didn't touch, a conflict can only mean an accidental reversion due to my outdated backup: I can blindly Accept Theirs.

This is why I asked for a way to retrigger a merge (and in the original question, blindly accept all theirs, but I see the mistake in that part).

Andrew Cheong
  • 29,362
  • 15
  • 90
  • 145
  • 1
    Possible duplicate of [Git resolve conflict using --ours/--theirs for all files](https://stackoverflow.com/questions/24743769/git-resolve-conflict-using-ours-theirs-for-all-files) – j4nw Mar 07 '18 at 20:15
  • No, that's the less significant part of the question... – Andrew Cheong Mar 07 '18 at 20:16
  • Could you draw a sketch of your current state, and a sketch of what you would like to reach ? – LeGEC Mar 07 '18 at 22:21
  • 1
    Tip: try [GIT Extensions](http://gitextensions.github.io/), makes advanced GIT handlings a lot easier. ([video example](https://www.youtube.com/watch?v=Kmc39RvuGM8) of merging) – Ron van der Heijden Mar 13 '18 at 09:07

1 Answers1

0

So, there was no need to find a way to retrigger a merge.

Unfortunately I cannot remember or figure how I did this next step, but maybe someone else can fill in what I'm missing.

Basically, I was able to use IntelliJ's VCS > Git > Merge Changes... (or was it Resolve Conflicts...) to go through all differences in a side-by-side view of three columns: my local copy, the "before," and the latest master. Anywhere I recognize my own changes, I accepted mine. Anywhere the diffs were foreign, I accepted theirs. There were few overlapping cases. Eventually this produced a clean merge.

Andrew Cheong
  • 29,362
  • 15
  • 90
  • 145