2

I am using git as a version control system, and using git-flow as the branching model. I started a feature branch some weeks ago in order to maintain the system in a clean state while developping that feature. The main development continued on the develop branch, and changes from develop were merged periodically into the feature, to keep it up to date as much as possible.

However came the time where the feature was finished, and I used git-flow's finish feature to merge the feature back into develop. The merge was successfully done, but then I found out that some of the commits I made in develop were reverted by the merge commit!

Nowhere in develop or in the feature branch were these changes reverted, I can't see any commit that overwrote them. I just can't find anything. The only theory I have for the moment is that git is failing on me, but that would be extremely unlikely. Maybe I did some kind of wrong manipulation that made this situation come true?

I can trace back in the history when the commit was made. I can see that the changes from that commit were reverted by the merge commit. Nowhere in the branch I see a commit that reverts those changes. Yet they were reverted.

How is this even possible?

Improve this question
1
  • The 3-way merge algorithm is very straightforward. It compares the versions being merged with the most recent common ancestor and takes the modified version (if both are modified in the same part, it's a conflict). It works well, but if a merge is done not following the algorithm (e.g. by sloppy conflict resolution), the changes thus introduced will be carried to future merges. I am sure the reason could be found by inspecting the history, but there is no obvious general answer. Inspecting git log --left-right --boundary L...R for L and R being the commits merged would be a start.
    – Jan Hudec
    Nov 13, 2013 at 8:03

2 Answers 2

Reset to default
2

Finally, it was an error on my part. I recently migrated the projet from SVN to Git, and I had then feature branch in SVN and it was not in sync with the trunk when I made the migration.

I created the first commit in the develop branch with the trunk, and then started a new feature-branch with git, and commited the files as they where in the SVN feature branch.

The commit being newer on the feature branch, and because it was not in sync with the latest trunk changes, Git thought, and for a reason, that the reverted changes were made after the initial commit, bringing these changes in when I merge the branch back into develop.

I resolved this in a separate branch, with a lot of manual work, but now I know that it was not git's fault.

Improve this answer
1

I had also same problem, it is more safe to checkout a new temporary branch from your main branch, merge and test this temporary branch and merge, if you are sure you did not miss something, merge to your main branch.

If you have a working version of your code, convert it to a new release, or a branch with a descriptive tag and do not touch it, and go on with development branch.

And avoid direct merging as far as possible, instead use rebase command, before merging. it is like stash command.

Improve this answer
2
  • A branch in another repository is always a different branch. So as long as you don't merge in the central repository (which you usually can't because it is bare), you always have a temporary branch.
    – Jan Hudec
    Nov 13, 2013 at 7:46
  • rebase can be problematic too
    – wirrbel
    Nov 13, 2013 at 12:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.