From: Claudia.Ignat@loria.fr
To: git@vger.kernel.org
Subject: Octopus merge
Date: Thu, 26 Nov 2009 16:56:02 +0100 [thread overview]
Message-ID: <4B0EA512.1050001@loria.fr> (raw)
Hello,
I have problems on understanding the results of octopus merge in the
following scenario.
Workspaces ws2, ws3, ws4 and ws5 are clones of the workspace ws1.
Suppose the current workspace is ws3 and some changes are done in
parallel in all these 4 workspaces. Further suppose that changes of ws2
and ws3 are conflicting, while the changes in ws4 and ws5 are neither
conflicting between them nor with ws2 and ws3.
While I am in the current workspace ws3 I perform the merge
git merge ws4 ws2 ws5
Obviously I obtain conflicts between changes in ws3 and ws2 which I fix
manually and afterwards I commit the new version of ws3. It seems
strange that the commit object has only one parent, while including the
changes of ws4.
If instead I perform
git merge ws4 ws5 ws2
and fix manually the conflicts and performing the commit, the commit
object has 4 parents (ws3,ws4,ws5 and ws2).
I provide below the script illustrating the first scenario:
# !/bin/bash
TEST_NAME="TP1" # name of the working directory
rm -rf ${TEST_NAME} # cleaning working directory
mkdir -p ${TEST_NAME}
cd ${TEST_NAME}
# initialising initial git workspace
mkdir ws1
cd ws1
git init
# adding a file to ws1
# commit changes
echo -e -n "1\n2\n3\n4\n5\n" > file.txt
git add file.txt
git commit -m "ws1 | add 12345"
cd ..
# cloning three times ws1 (as ws2, ws3 and ws4)
git clone ws1 ws2
git clone ws1 ws3
git clone ws1 ws4
git clone ws1 ws5
# updating file.txt in ws2 (insert X at line 3, then write and quit 'ed')
# commit changes
cd ws2
echo -e "3i\nX\n.\nw\nq\n" | ed file.txt
git add file.txt
git commit -m "ws2 | insert 12X345"
cd ..
# updating file.txt in ws3 (insert Y at line 3, then write and quit 'ed')
# commit changes
cd ws3
echo -e "3i\nY\n.\nw\nq\n" | ed file.txt
git add file.txt
git commit -m "ws3 | insert 12Y345"
cd ..
cd ws4
echo -e -n "U1\n2\n3\n4\n5\n" > u.txt
git add u.txt
git commit -m "ws4 | add u.txt"
cd ..
cd ws5
echo -e -n "W1\n2\n3\n4\n5\n" > w.txt
git add w.txt
git commit -m "ws5 | add w.txt"
cd ..
# ws3 pull from ws2 ws4 ws5
cd ws3
git remote add bws2 ../ws2
git remote add bws4 ../ws4
git remote add bws5 ../ws5
git fetch bws2
git fetch bws4
git fetch bws5
git merge bws4/master bws2/master bws5/master
cd ..
# resolve conflict in ws3
cd ws3
echo -e '7d\n5d\n3d\n.\nw\nq\n' | ed file.txt
git add file.txt
git commit -m "ws3| in file.txt solve conflict (kept XY) "
cd ..
Could somebody please explain me these results? I suspect a bug in
octopus merge. I am using version 1.6.3.3 of git.
Thank you in advance.
Best regards,
Claudia Ignat
next reply other threads:[~2009-11-26 16:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-26 15:56 Claudia.Ignat [this message]
2009-11-26 16:44 ` Octopus merge Thomas Rast
2009-11-26 16:52 ` Michael J Gruber
2009-12-09 15:10 ` Claudia.Ignat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4B0EA512.1050001@loria.fr \
--to=claudia.ignat@loria.fr \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).