Mergetool generating blank files (1.5.3)

> At work, I've been using a git-svn import for my daily workflow (still
> somewhat of a git newbie, but now has come to the point where it's
> tough to work without it), and while rebasing from svn (on a rather
> old branch), I found that the mergetool option does not work too well
> for me.

> On Thu, Sep 27, 2007 at 06:31:19PM +0000, Kelvie Wong wrote:
>> At work, I've been using a git-svn import for my daily workflow (still
>> somewhat of a git newbie, but now has come to the point where it's
>> tough to work without it), and while rebasing from svn (on a rather
>> old branch), I found that the mergetool option does not work too well
>> for me.
> 
>   Which tool are you using ? kdiff3 ? I've noticed that it often fails
> miserably, or worse, create bad merges silentely with it.
> 
>   And as none of the other merge tool that are supported are able to
> either do 3way merges, or have a decent UI (that definitely seems to be
> exclusive features) I've given up on git-mergetool (and to be fair, it
> sucks, because it could be _sooo_ useful sometimes).
> 

> Pierre Habouzit wrote:
> > On Thu, Sep 27, 2007 at 06:31:19PM +0000, Kelvie Wong wrote:
> >> At work, I've been using a git-svn import for my daily workflow (still
> >> somewhat of a git newbie, but now has come to the point where it's
> >> tough to work without it), and while rebasing from svn (on a rather
> >> old branch), I found that the mergetool option does not work too well
> >> for me.
> > 
> >   Which tool are you using ? kdiff3 ? I've noticed that it often fails
> > miserably, or worse, create bad merges silentely with it.
> > 
> >   And as none of the other merge tool that are supported are able to
> > either do 3way merges, or have a decent UI (that definitely seems to be
> > exclusive features) I've given up on git-mergetool (and to be fair, it
> > sucks, because it could be _sooo_ useful sometimes).
> > 
> 
> What about meld? That does 3-way merge, and the UI is fine.

> > >   And as none of the other merge tool that are supported are able to
> > > either do 3way merges, or have a decent UI (that definitely seems to be
> > > exclusive features) I've given up on git-mergetool (and to be fair, it
> > > sucks, because it could be _sooo_ useful sometimes).
> > > 
> > 
> > What about meld? That does 3-way merge, and the UI is fine.
> 
>   Indeed, it seems that since the last time I tested it, it now does
> diff3 merging. I should reevaluate it :)

> On Thu, Sep 27, 2007 at 09:11:25PM +0200, Pierre Habouzit wrote:
> > > >   And as none of the other merge tool that are supported are able to
> > > > either do 3way merges, or have a decent UI (that definitely seems to be
> > > > exclusive features) I've given up on git-mergetool (and to be fair, it
> > > > sucks, because it could be _sooo_ useful sometimes).
> > > > 
> > > 
> > > What about meld? That does 3-way merge, and the UI is fine.
> > 
> >   Indeed, it seems that since the last time I tested it, it now does
> > diff3 merging. I should reevaluate it :)
> 
> Pierre,
> 
> FYI, kdiff3, meld, xxdiff, opendiff (on MacOSX), and emerge all
> support 3-way merge.

> On Thu, Sep 27, 2007 at 10:23:26PM +0000, Theodore Tso wrote:
> > On Thu, Sep 27, 2007 at 09:11:25PM +0200, Pierre Habouzit wrote:
> > > > >   And as none of the other merge tool that are supported are able to
> > > > > either do 3way merges, or have a decent UI (that definitely seems to be
> > > > > exclusive features) I've given up on git-mergetool (and to be fair, it
> > > > > sucks, because it could be _sooo_ useful sometimes).
> > > > > 
> > > > 
> > > > What about meld? That does 3-way merge, and the UI is fine.
> > > 
> > >   Indeed, it seems that since the last time I tested it, it now does
> > > diff3 merging. I should reevaluate it :)
> > 
> > Pierre,
> > 
> > FYI, kdiff3, meld, xxdiff, opendiff (on MacOSX), and emerge all
> > support 3-way merge.
> 
>   I know, but:
>   * kdiff3 often take decisions behind your back, and results in broken
>     merges, so it's a no-go ;
>   * xxdiff has (IMHO) a very bad and non-intuitive UI, I never get to
>     make it work ;
>   * I don't use macos (opendiff) ;
>   * emerge is emacs right ? :)
> 
>   Though I gave meld another chance, and it works really better than it
> used to, so I may give it a try :) Let's hope I won't be disappointed by
> meld :)
> 

> FWIW, xxdiff has support to handle halfway merged files, so that if git
> could merge some hunks already for you (e.g. rerere kicked in), you
> don't have to redo the _whole_ merge by hand, just call
> 
> 	xxdiff -U file/with/mergemarkers/inside
> 
> and it will do the right thing. Not sure if the other tools could handle
> it, but any pointers appreciated, because it often happens to me that
> only one hunk out of several wasn't merged automatically by git. And
> mergetool wants to always redo the whole merge, which isn't the best it
> can do.

>   Which tool are you using ? kdiff3 ? I've noticed that it often fails
> miserably, or worse, create bad merges silentely with it.
> 
>   And as none of the other merge tool that are supported are able to
> either do 3way merges, or have a decent UI (that definitely seems to be
> exclusive features) I've given up on git-mergetool (and to be fair, it
> sucks, because it could be _sooo_ useful sometimes).

> On Thu, Sep 27, 2007 at 08:57:07PM +0200, Pierre Habouzit wrote:
> 
> >   Which tool are you using ? kdiff3 ? I've noticed that it often fails
> > miserably, or worse, create bad merges silentely with it.
> > 
> >   And as none of the other merge tool that are supported are able to
> > either do 3way merges, or have a decent UI (that definitely seems to be
> > exclusive features) I've given up on git-mergetool (and to be fair, it
> > sucks, because it could be _sooo_ useful sometimes).
> 
> Huh? I use xxdiff all the time, and it works fine.

> On Thu, Sep 27, 2007 at 06:31:19PM +0000, Kelvie Wong wrote:
> > At work, I've been using a git-svn import for my daily workflow (still
> > somewhat of a git newbie, but now has come to the point where it's
> > tough to work without it), and while rebasing from svn (on a rather
> > old branch), I found that the mergetool option does not work too well
> > for me.
>
>   Which tool are you using ? kdiff3 ? I've noticed that it often fails
> miserably, or worse, create bad merges silentely with it.
>
>   And as none of the other merge tool that are supported are able to
> either do 3way merges, or have a decent UI (that definitely seems to be
> exclusive features) I've given up on git-mergetool (and to be fair, it
> sucks, because it could be _sooo_ useful sometimes).
>
> --
> ·O·  Pierre Habouzit
> ··O                                                madcoder@debian.org
> OOO                                                http://www.madism.org
>
>

> I've tried all of the ones that were supported, the result is the same
> -- blank files in all three windows.
>
> It is because git mergetool fails to generate these files for whatever
> reason (the filebasename.{REMOTE,LOCAL,BASE}.* files).  I don't know
> why this happens.

> "Kelvie Wong" <kelvie@ieee.org> writes:
>
> > I've tried all of the ones that were supported, the result is the same
> > -- blank files in all three windows.
> >
> > It is because git mergetool fails to generate these files for whatever
> > reason (the filebasename.{REMOTE,LOCAL,BASE}.* files).  I don't know
> > why this happens.
>
> Can you run git-mergetool under "sh -x"?
>
> That is,
>
>         $ sh -x git-mergetool
>
> around ll.160-170 these files are created.
>

> "Kelvie Wong" <kelvie@ieee.org> writes:
>
> > And then meld starts up, with the original file in the middle, and two
> > blank files on the side, LOCAL and REMOTE respectively.
>
> Wild guess.  Are you running this from a subdirectory?  I have a
> mild suspicion that mergetool is not subdirectory safe.  Can you
> try running it from the toplevel of the work tree?
>
>

> Egads, it's alive!
>
> I was in a subdirectory (most of my work is in that one subdirectory
> anyways :p), but running it on the top level did indeed work as
> expected.
>
> Thanks,

> "Kelvie Wong" <kelvie@ieee.org> writes:
>
>> Egads, it's alive!
>>
>> I was in a subdirectory (most of my work is in that one subdirectory
>> anyways :p), but running it on the top level did indeed work as
>> expected.
>>
>> Thanks,
>
> Thanks for spotting a bug.  It claims to be subdirectory safe at
> the top of the script but apparently it isn't.
>
> And I do not see a reason why it cannot be made subdirectory
> safe.

> Junio C Hamano <gitster@pobox.com> writes:
>
> > "Kelvie Wong" <kelvie@ieee.org> writes:
> >
> >> Egads, it's alive!
> >>
> >> I was in a subdirectory (most of my work is in that one subdirectory
> >> anyways :p), but running it on the top level did indeed work as
> >> expected.
> >>
> >> Thanks,
> >
> > Thanks for spotting a bug.  It claims to be subdirectory safe at
> > the top of the script but apparently it isn't.
> >
> > And I do not see a reason why it cannot be made subdirectory
> > safe.
>
> It _could_ be just the matter of doing this, although I cannot
> test it right now (at work and have no access to any of the
> backends).  Care to try it from a subdirectory and report
> failure or success?
>
> ---
>
>  git-mergetool.sh |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index a0e44f7..018db58 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -12,6 +12,7 @@ USAGE='[--tool=tool] [file to merge] ...'
>  SUBDIRECTORY_OK=Yes
>  . git-sh-setup
>  require_work_tree
> +cd_to_toplevel
>
>  # Returns true if the mode reflects a symlink
>  is_symlink () {
>

> On 9/27/07, Junio C Hamano <gitster@pobox.com> wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > > "Kelvie Wong" <kelvie@ieee.org> writes:
> > >
> > >> Egads, it's alive!
> > >>
> > >> I was in a subdirectory (most of my work is in that one subdirectory
> > >> anyways :p), but running it on the top level did indeed work as
> > >> expected.
> > >>
> > >> Thanks,
> > >
> > > Thanks for spotting a bug.  It claims to be subdirectory safe at
> > > the top of the script but apparently it isn't.
> > >
> > > And I do not see a reason why it cannot be made subdirectory
> > > safe.
> >
> > It _could_ be just the matter of doing this, although I cannot
> > test it right now (at work and have no access to any of the
> > backends).  Care to try it from a subdirectory and report
> > failure or success?
> >
> > ---
> >
> >  git-mergetool.sh |    1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/git-mergetool.sh b/git-mergetool.sh
> > index a0e44f7..018db58 100755
> > --- a/git-mergetool.sh
> > +++ b/git-mergetool.sh
> > @@ -12,6 +12,7 @@ USAGE='[--tool=tool] [file to merge] ...'
> >  SUBDIRECTORY_OK=Yes
> >  . git-sh-setup
> >  require_work_tree
> > +cd_to_toplevel
> >
> >  # Returns true if the mode reflects a symlink
> >  is_symlink () {
> >
>
> At least with emerge, this isn't so simple -- emacs tries to save it
> as ${absolute_PWD}/${PWD_relative_to_toplevel}/$filename
> (which of course doesn't exist yet).
>
> In meld it works fine, however; haven't tried the other ones.
> --
> Kelvie
>

> When mergetool is run from a subdirectory, "ls-files -u" nicely
> limits the output to conflicted files in that directory, but
> we need to give the full path to cat-file plumbing to grab the
> contents of stages.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
>
>  * I earlier sent one with cd_to_toplevel but I think the
>    approach in this patch is nicer.
>
>  git-mergetool.sh |    7 ++++---
>  1 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index a0e44f7..3b1ec13 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -12,6 +12,7 @@ USAGE='[--tool=tool] [file to merge] ...'
>  SUBDIRECTORY_OK=Yes
>  . git-sh-setup
>  require_work_tree
> +prefix=$(git rev-parse --show-prefix)
>
>  # Returns true if the mode reflects a symlink
>  is_symlink () {
> @@ -162,9 +163,9 @@ merge_file () {
>      local_mode=`git ls-files -u -- "$path" | awk '{if ($3==2) print $1;}'`
>      remote_mode=`git ls-files -u -- "$path" | awk '{if ($3==3) print $1;}'`
>
> -    base_present   && git cat-file blob ":1:$path" > "$BASE" 2>/dev/null
> -    local_present  && git cat-file blob ":2:$path" > "$LOCAL" 2>/dev/null
> -    remote_present && git cat-file blob ":3:$path" > "$REMOTE" 2>/dev/null
> +    base_present   && git cat-file blob ":1:$prefix$path" >"$BASE" 2>/dev/null
> +    local_present  && git cat-file blob ":2:$prefix$path" >"$LOCAL" 2>/dev/null
> +    remote_present && git cat-file blob ":3:$prefix$path" >"$REMOTE" 2>/dev/null
>
>      if test -z "$local_mode" -o -z "$remote_mode"; then
>         echo "Deleted merge conflict for '$path':"
>

> It's not that emacs sets $PWD via its first argument, but the output
> file is passed from emerge-files*-command to stashed in the per-buffer
> variable emerge-file-out, which in turn gets passed to the emacs lisp
> file write-file, which is what gets run when you run C-x C-w --- and
> write-file interprets a relative pathname based on the containing
> directory of the existing buffer.
>                                                 - Ted
>

> On 9/27/07, Theodore Tso <tytso@mit.edu> wrote:
>
>> It's not that emacs sets $PWD via its first argument, but the output
>> file is passed from emerge-files*-command to stashed in the per-buffer
>> variable emerge-file-out, which in turn gets passed to the emacs lisp
>> file write-file, which is what gets run when you run C-x C-w --- and
>> write-file interprets a relative pathname based on the containing
>> directory of the existing buffer.
>>                                                 - Ted
>>
>
> Ah yes, I just started reading up on elisp a little while ago :)
>
> I'd always assumed that emacs kept an internal "pwd" variable (i.e.
> what's displayed with M-x pwd), but I guess my way of thinking is
> archaic and deprecated :(

> When mergetool is run from a subdirectory, "ls-files -u" nicely
> limits the output to conflicted files in that directory, but
> we need to give the full path to cat-file plumbing to grab the
> contents of stages.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>

> I've tried all of the ones that were supported, the result is the same
> -- blank files in all three windows.
>
> It is because git mergetool fails to generate these files for whatever
> reason (the filebasename.{REMOTE,LOCAL,BASE}.* files).  I don't know
> why this happens.
>
> As for merge utilities, all I need is something that looks for the
> first <<<<<, and lets me choose which version I want (either top or
> bottom), plain and simple :/  I don't even need/want a gui.