On Fri, Dec 19, 2008 at 09:11:57AM +0200, Hasso Tepper wrote: > YONETANI Tomokazu wrote: > > On Thu, Dec 18, 2008 at 12:39:06PM +0200, Hasso Tepper wrote: > > > 4) Now I have to switch to master and merge? This is how my journey > > > stopped: > > > > > > $ git checkout master > > > $ git merge --no-commit OPENPAM > > > > Since you know exactly which commit you want to merge, what about this? > > $ git merge --no-commit OPENPAM^ OPENPAM > > It doesn't complain, yeah, but I'm not sure whether it's a right thing to > do. Is it?
Well, I think both should give you the same result; the same changes and the same merge parents. We know that the common ancestor 7bce828 has already been committed to master as 863a10d, but... | $ GIT_MERGE_VERBOSITY=10 git merge --no-commit origin/vendor/OPENPAM | Merging HEAD with origin/vendor/OPENPAM | Merging: | 249a1dc wrong initializer in VFS_SET; maybe someone'll commit it :) | f23594c Import OpenPAM Hydrangea. | found 1 common ancestor(s): | 7bce828 Import pam_deny, pam_permit and pam_unix from FreeBSD, use them instead | CONFLICT (rename/delete): Renamed contrib/openpam/modules/pam_deny/pam_deny.c->lib/pam_module/pam_opieaccess/pam_opieaccess.c in HEAD and deleted in origin/vendor/OPENPAM | CONFLICT (rename/delete): Renamed contrib/openpam/modules/pam_permit/pam_permit.c->usr.bin/truss/extern.h in HEAD and deleted in origin/vendor/OPENPAM | Automatic merge failed; fix conflicts and then commit the result. for some reason git thinks a deletion and an addition of two unrelated files to be a rename (as others mentioned on commits@), I don't really know about this part. Anyway if you take the default merge method, you have to ignore this confusing message and commit. If you take the `octopus' method, you don't have to see the conflict in this case, but you need to know which versions to merge.
