2

I have a branch called master and a branch called feature. A week ago I merged feature into master but then realized the feature wasn't really ready yet, so I reverted the merge.

Now I'm ready to merge feature into master again, but only some files were merged - because Git is looking at the history and thinks that the master revert should take precedence and not include a bunch of files that exist in feature that I really do want.

What I want is a way to interactively look at the diff between the two branches and select which files I want to keep, deal with any merge conflicts, etc. But git merge refuses to acknowledge any difference between these two branches.

How can I accomplish this?

Matthew
  • 7,605
  • 7
  • 39
  • 39

1 Answers1

2

I found this interesting Git revert

The beauty about this problem is, the best feature ot git revert is creating the problem. The biggest advantage of using git revert from git reset is

It doesn’t change the project history, which makes it a “safe” operation for commits that have already been published to a shared repository. For details about why altering shared history is dangerous, please see the git reset page.

git revert in itself is a commit. You should have used git reset --hard, I am guessing you had a reason for using git revert.

It's important to understand that git revert undoes a single commit—it does not “revert” back to the previous state of a project by removing all subsequent commits.

To undo a merge before you push commits.

git revert -m 1 <commit>

But remember the real problem here is, you have to revert the revert before you want to commit the brach again, or re-merge it again.

Anyways, I have found a wonderful person on this planet, who explained in detailed exactly the same problem. Yes, Exactly the same problem. I am excited to present him here:

Linux Torvalds explaining the git-revert conflict

I have a master branch. We have a branch off of that that some developers are doing work on. They claim it is ready. We merge it into the master branch. It breaks something so we revert the merge. They make changes to the code. they get it to a point where they say it is ok and we merge again.

When examined, we find that code changes made before the revert are not in the master branch, but code changes after are in the master branch.

This might also help you:

Re-doing a reverted merge in Git

Community
  • 1
  • 1