1

I have a feature branch that I want to rebase on main with conflicts that need to be resolved. I want to resolve these conflicts in a separate commit to my original changes. My branch has two commits, A and B. Commit A includes changes with merge conflicts. Commit B doesn't. After my rebase, I want a commit history that looks like this:

(main) -> Commit A non-conflicting changes only -> Commit A merge resolution changes only -> Commit B.

I want to apply rebased commits that have merge conflicts as 2 separate commits, which git rebase doesn't permit. Is there another way to achieve the history outlined above?

Improve this question
8
  • If you prefer cherry picking on a new branch from the target branch of your code versions compositions, git-cherry-pick(1) supports more than one commit as well. E.g. How to git cherrypick all changes introduced in specific branch and likely many other compositions are possible. Commented Sep 1 at 6:56
  • Right now it's unclear what you want - you just write that you are looking for "better alternatives". What would make an alternative better? Your current approach works - so what are you looking for? Voting to close until Q is edited. Commented Sep 1 at 7:31
  • This might help: stackoverflow.com/questions/73658025/… Commented Sep 1 at 9:01
  • 1
    "I want to resolve these conflicts in a separate commit to my original changes." I suspect an XY problem here. What do you try to achieve/avoid here? Commented Sep 1 at 9:08
  • It would be a strange workflow to leave conflict markers in a commit for posterity. Do you intend to squash the commits with the resolutions into the commit that introduced the conflict markers later? Commented Sep 1 at 9:29

2 Answers 2

Reset to default
1

This method works, but doesn't feel particularly elegant. Are there any better alternatives?

IMHO there are, and one of them is you resolve the conflicts per each conflicting commit during interactive rebase (git rebase (--interactive | -i) ....

This technique also allows you to run project specific tests for each commit, which will give you a better picture than "with/without conflicts".

Git itself has you covered as it can search for conflict markers and if hooked properly, refuses commits containing them. As git is a distributed system, this can make especially sense when a remote refuses commits containing them when receiving.

I'm aware that any way to do this will result in a 'broken' state of the codebase at the first commit, which I am fine with.

While it is always an option to version "broken" code (code with conflicts), rebasing is actually about rewriting the history to keep that out.

And therefore, it may be unexpected to use the Git version control system for that.

Therefore IMHO no need to be fine with it apart for your current self, as in versions, you are only re-iterating conflicts and populate them albeit the version control system already told you they are there (and were if you solve them during rebase).

Strictly spoken: If you're fine without elegance, don't ask for it. There is no silver bullet "to have a conflict and eat it, too".

Concluding:

The technique you're making use of looks more like a standard merge without rebase and resolving the conflicts on the merge to me. That being said, perhaps decide on what you'd like to achieve and then choose the right strategy for it: intermediate merges with conflict resolution or rewriting history with rebase.

Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

"interactive rebase" - resolving conflicts in the commit they occur in is exactly what I'm trying to avoid, because the end result is a commit that includes both non-conflict resolution changes with conflict resolution changes with no way to tell which is which. "That being said, perhaps decide on what you'd like to achieve and then choose the right strategy for it" - ideally, I want to be able to commit all lines/files that have no conflict, and leave the conflict files in my working directory. Then, I resolve the conflicts, and commit again.
@easely: And what prevents you to commit non-conflicting file's lines only? You can make two commits out of one during interactive rebase.
0

Try git rebase --continue and then check is it working or not. It will be better if you provide some snapshots

Improve this answer

2 Comments

git rebase --continue doesn't work. You must edit all merge conflicts and then mark them as resolved using git add
@easely: That is true, but "does not work" may also be a strong hint that you may want to learn why git-rebase(1) refuses here. If you prefer cherry-picking instead of rebase - e.g. to explore deeper on your own project - I've commented directly under your question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.