On 08/28/2009 03:37 PM, seanh wrote:
In response to Matthieu and Paolo, I'm not sure I understand the git
internals involved in the discussion around merge --squash, I had a
feeling this would produce a 'merge' that git in some sense would 'not
know about', since it sounds complex and I don't understand it I don't
think I want to go there.
Yes, the problem is that git does not track what happens when you do
"git merge --squash", which makes it harder to do merges after some time
(because of conflicts).
The solution I gave (and Matthieu explained how it works, even though
it's very technical) is a way to "explain" git what you did. If you try
it on a fake example with gitk, you should understand it better.
mkdir test
cd test
# import
git init
echo a > test
git add a
git commit -m1
# some changes happen in your local "fine grained" branch
git checkout -b local
echo b > test
git commit -a -m2
echo c >> test
git commit -a -m3 ##<<<
# the magic incantation brings those commit to master
# (first two commands) and teaches git what happened (last two)
git checkout master
git merge --squash local; git commit -m'merge 1' ##<<<
git checkout local
git merge master ##<<<
# more local changes
sed -i s/b/d/ test
git commit -a -m4
echo z >> test
git commit -a -m5 ##<<<
# the magic incantation, again
git checkout master
git merge --squash local; git commit -m'merge 1' ##<<<
git checkout local
git merge master ##<<<
Use gitk at the points indicated with ##<<<
It is actually very similar to what you chose to do. My commits to
master, in practice, are your tags. You may want to see how gitk's
graphs looks in both scenarios, and choose the one that you prefer.
Hope this helps!
Paolo
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html