git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* git merge strange result
@ 2011-12-01 15:36 Catalin(ux) M. BOIE
  2011-12-01 18:50 ` Jeff King
  0 siblings, 1 reply; 2+ messages in thread
From: Catalin(ux) M. BOIE @ 2011-12-01 15:36 UTC (permalink / raw)
  To: git

Hello!

Below is a script that reproduce what a coleague of mine found.
Seems that if in a branch we have a commit that is cherry-picked be 
master, than revert that commit in branch and merge branch in master, the 
revert is ignored. Is it normal?

Thank you very much!

#!/bin/bash

set -e

rm -rf buba1
mkdir buba1
cd buba1

git init
echo -e "aaa\nbbb\nccc" > file1
git add file1
git commit -m "c1"

echo "Create branch b1..."
git branch b1
echo

echo "Create a bad fix..."
sed --in-place -e 's/bbb/bad line/' file1
git add file1
git commit -m "bad commit"
cat file1
echo

echo "Cherry pick on b1..."
git checkout b1
git cherry-pick -x master
echo

echo "Reverting on b1"
git revert --no-edit b1
echo

echo "Switch to master"
git checkout master
echo

echo "merge-base is `git merge-base --all master b1 | git name-rev --stdin`"
echo

echo "diff between master and b1..."
git diff master b1
echo

echo "Merge b1 in master"
git merge --verbose --log b1

if [ "`grep bad file1`" = "" ]; then
 	echo "good!"
else
 	echo "bad!"
fi
# it should prind "good"

--
Catalin(ux) M. BOIE
http://kernel.embedromix.ro/

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: git merge strange result
  2011-12-01 15:36 git merge strange result Catalin(ux) M. BOIE
@ 2011-12-01 18:50 ` Jeff King
  0 siblings, 0 replies; 2+ messages in thread
From: Jeff King @ 2011-12-01 18:50 UTC (permalink / raw)
  To: Catalin(ux) M. BOIE; +Cc: git

On Thu, Dec 01, 2011 at 05:36:00PM +0200, Catalin(ux) M. BOIE wrote:

> Below is a script that reproduce what a coleague of mine found.
> Seems that if in a branch we have a commit that is cherry-picked be
> master, than revert that commit in branch and merge branch in master,
> the revert is ignored. Is it normal?

Yes, it's by design. When doing a merge, we look at three points: the
tip of the current branch, the tip of the branch to be merged, and the
point at which history diverged (the "merge base"). We don't look
individually at the commits that happened between the merge base and
each tip.

The non-conflicting case for a 3-way merge is that one side makes some
change, but the other side does nothing. In this case, we include the
change in the merge result. But remember that we are only looking at
endpoints. So what the actual merge code sees is that one side's version
of a file is identical to the merge base's version, and that the other
side's version is now different.

In your case, one side makes the change, but then restores the original
state. So from the perspective of the merge code, no change happened at
all on that side.

-Peff

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-12-01 18:50 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-01 15:36 git merge strange result Catalin(ux) M. BOIE
2011-12-01 18:50 ` Jeff King

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).