how do I resolve this merge manually + mergetool bug

#       unmerged:   profiles/package.mask

on the remote package.mask is a file locally it is a directory.

I need to know how I can resolve this merge without mergetool as currently mergetool doesn't handle it well.

I want to delete the remote version of package.mask

tried:

git rm :3:profiles/package.mask fatal: pathspec ':3:profiles/package.mask' did not match any files

mergetool will move my directory to a backup directory if I tell it to delete package.mask it doesn't move the directory back into place, if I tell it to use the remote version it obviously copies it into place... I'd be ok if when I told it to delete it, it restored the directory from backup.

regardless of mergetools problems I'd like to know how to fix this merge without mergetool.

Caleb Cushing <xenoterracide@gmail.com> writes:

The answer most likely is this but don't do this just yet:

    $ git rm profiles/package.mask

With this, you are saying "For the path profiles/package.mask, the correct resolution is not to have it". There is no room for the stage number to get into the picture when you are talking about the final result.

But I am suspecting that this is because you moved it to somewhere (perhaps to profiles/package.mask/frotz) while the remote side kept it intact or modified it in place. If that is the case, and if the remote side made an in-place change, you would want to port the change over to the path you moved the contents to before you actually remove it, so before running the above "git rm", I would do something like.

    $ git cat-file blob :1:profiles/package.mask >original
    $ git cat-file blob :3:profiles/package.mask >theirs
    $ git cat-file blob profiles/package.mask/frotz >mine
    $ git merge-file mine original theirs
    $ diff -u profiles/package.mask/frotz mine ;# eyeball the merge result
    $ cat mine >profiles/package.mask/frotz

and then finally conclude the merge with:

    $ git rm profiles/package.mask
    $ git add profiles/package.mask/frotz

But if the remote side did not change anything (i.e. original == theirs), then you do not have to do the file-level merge to update the contents you moved to a different path.

On Tue, Feb 24, 2009 at 1:31 AM, Junio C Hamano <gitster@pobox.com> wrote:

so do all this if theirs is different? (at the moment I know it isn't)

git rm profiles/package.mask

rm 'profiles/package.mask' rm 'profiles/package.mask' rm 'profiles/package.mask/gentoo.org' rm 'profiles/package.mask/java-overlay' rm 'profiles/package.mask/perl-experimental' rm 'profiles/package.mask/regen2.org' rm 'profiles/package.mask/sunrise' fatal: git rm: profiles/package.mask: Is a directory

and git status still shows..

#       unmerged:   profiles/package.mask

Caleb Cushing <xenoterracide@gmail.com> writes:

Ahh, ok, "git rm" Porcelain may well be buggy; I almost never use it myself.

"git update-index --force-remove profiles/package.mask" should work better. I tend to trust plumbing a lot more than Porcelain for these corner cases.

On Tue, Feb 24, 2009 at 2:16 AM, Junio C Hamano <gitster@pobox.com> wrote:

works. awesome! thanks for the help, I've been banging my head against how to do this (without pain++ ) for a couple of days.

On Tue, Feb 24, 2009 at 01:04:23AM -0500, Caleb Cushing wrote:

I see you've now resolved this without mergetool, I'll look at adding a test case to mergetool and see how easy it is to get it to handle this case better.

On Tue, Feb 24, 2009 at 2:47 AM, Charles Bailey <charles@hashpling.org> wrote:

few weeks back I created a patch for mergetool, it was rejected ultimately on the basis that it had to cleanup temporary files and in reality this was a problem with a lot of mergetool, the suggestion was made that mergetool needs refactoring. I believe this problem is a similar symptom. basically mergetool should touch my files before I tell it what to do. if it has to move and back up my files before deciding then at the very least it should copy them back into place if I delete the remote. preferably in this case though it would just delete the remote or backup my local files and copy the remote in after I told it what to do (or maybe even delete my local files).

On Tue, Feb 24, 2009 at 03:32:50AM -0500, Caleb Cushing wrote:

Coincidentally, last night I started looking at a mergetool refactoring but more with unifying the handling of temporaries and actions between the different types of merge (symlink, deleted file and 'normal').

I'm more of the opinion that in any non-trivial case (i.e. not a regular file/file merge), it *shouldn't* do anything until you tell it what you want it to do. Clearly, between a tree and a blob, mergetool is not going to be able to invoke a mergetool on set of three blobs, but it should work out what it can do before prompting for a choice from the user of what they want it to do.