how do I resolve this merge manually + mergetool bug

how do I resolve this merge manually + mergetool bug

[Caleb Cushing]

#       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

http://xenoterracide.blogspot.com

Re: how do I resolve this merge manually + mergetool bug

[Junio C Hamano]

Caleb Cushing <xenoterracide@gmail.com> writes:

> #       unmerged:   profiles/package.mask
>
> on the remote package.mask is a file locally it is a directory.
> ...
> git rm :3:profiles/package.mask
> fatal: pathspec ':3:profiles/package.mask' did not match any files

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.

Re: how do I resolve this merge manually + mergetool bug

[Caleb Cushing]

On Tue, Feb 24, 2009 at 1:31 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
>    $ 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

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

> and then finally conclude the merge with:
>
>    $ git rm profiles/package.mask
>    $ git add profiles/package.mask/frotz

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

http://xenoterracide.blogspot.com

Re: how do I resolve this merge manually + mergetool bug

[Junio C Hamano]

Caleb Cushing <xenoterracide@gmail.com> writes:

> git rm profiles/package.mask
>
> rm 'profiles/package.mask'
> rm 'profiles/package.mask'
> rm 'profiles/package.mask/gentoo.org'

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.

Re: how do I resolve this merge manually + mergetool bug

[Caleb Cushing]

On Tue, Feb 24, 2009 at 2:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "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.

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

http://xenoterracide.blogspot.com

Re: how do I resolve this merge manually + mergetool bug

[Charles Bailey]

On Tue, Feb 24, 2009 at 01:04:23AM -0500, Caleb Cushing wrote:
> regardless of mergetools problems I'd like to know how to fix this
> merge without mergetool.

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.

-- 
Charles Bailey
http://ccgi.hashpling.plus.com/blog/

Re: how do I resolve this merge manually + mergetool bug

[Caleb Cushing]

On Tue, Feb 24, 2009 at 2:47 AM, Charles Bailey <charles@hashpling.org> wrote:
> I'll look at adding
> a test case to mergetool and see how easy it is to get it to handle
> this case better.

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).
-- 
Caleb Cushing

http://xenoterracide.blogspot.com

Re: how do I resolve this merge manually + mergetool bug

[Charles Bailey]

On Tue, Feb 24, 2009 at 03:32:50AM -0500, Caleb Cushing wrote:
> On Tue, Feb 24, 2009 at 2:47 AM, Charles Bailey <charles@hashpling.org> wrote:
> > I'll look at adding
> > a test case to mergetool and see how easy it is to get it to handle
> > this case better.
> 
> 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).

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.

-- 
Charles Bailey
http://ccgi.hashpling.plus.com/blog/