0

I made extensive changes to an open-source project with a large codebase, mostly using an interactive find-and-replace, then filed a GitHub PR and forgot about it. Two years later, they're taking a new look at the old PR, so I merged the current main branch back onto my changes and pushed out the result.

The problem is that in the interim, a lot of the fixes I made were addressed by other commits, but their fix differs from mine in an unimportant way -- whitespace, comment wording, etc. I want to make it easier to review my PR by reducing the number of changed files, but I don't want to hand copy individual path names for each file containing trivial changes, into something like git checkout main -- path/to/similar-file.ext, which would also risk overwriting an important change without realizing it.

Is there a clever command line that will show me each individual change (not whole-file-at-once) between one branch (main) and another (my-feature) with an interactive prompt to keep one or the other, similar to interactive cherry-pick? I'd also be happy with a solution that uses GitHub's PR interface, or VSCode.

Coderer
  • 25,844
  • 28
  • 99
  • 154
  • don't merge `main` into your feature branch, `rebase` your feature branch to current main, fix the conflicts, add the changed files to a commit and file a new PR – rioV8 Apr 12 '22 at 10:34
  • I don't see how `rebase` instead of `merge` makes a difference. If I've changed 50 files in `my-feature` they're still changed after a rebase. The point is to step through each change (after the merge or rebase) and decide whether to keep it, or leave it as-is from `main`. – Coderer Apr 12 '22 at 11:10
  • it keeps the git history clean, then use the `Stage Selected Changes` to stage what you want to commit and revert file for all the other changes – rioV8 Apr 12 '22 at 11:19
  • Maybe I'm invoking `rebase` wrong? I did `git checkout my-feature; git rebase main`. There were conflicts, so I resolved them, `git add fixed-file.ext; git rebase --continue`, repeat until rebase finishes. When would I "stage selected changes"? – Coderer Apr 12 '22 at 12:07
  • yes, you should now have all the changes you want to be made, because in resolving the conflicts you have selected the `main` branch versions that only had whitespace diffs – rioV8 Apr 12 '22 at 13:10
  • When I ran `git rebase main`, the merge favored my local (trivial) whitespace/punctuation changes and didn't ask me which to use. That's the whole problem, I guess. – Coderer Apr 13 '22 at 09:24
  • it should flag any difference on the same lines as a conflict or does git have a setting to ignore whitespace, some files use whitespace (YAML,Python,....) and automatic choosing a punctuation difference is not what I want – rioV8 Apr 13 '22 at 11:20
  • It wasn't strictly whitespace, for example in a JSDoc comment the `main` branch might have had `@returns {string|undefined}` where I had written `@returns {undefined|string}`. I don't know why the change automatically resolved in favor of `feature-branch`, but it did. – Coderer Apr 13 '22 at 12:36

1 Answers1

0

I was able to do what I wanted using this answer, as long as I was OK with losing the associated commit history. In short:

# my-feature branch has a mix of important and trivial changes
git checkout main

# new name for branch with only selected changes
git checkout -b my-feature-retry

# Use "--patch" flag for interactive prompt for each incoming change from my-feature
git checkout -p my-feature

# answer prompt for each change, uses same interface from `git add --interactive`

# Any change where you answered "Y" will be staged and ready to commit
git status
Coderer
  • 25,844
  • 28
  • 99
  • 154