Mergetool generating blank files (1.5.3)

Mergetool generating blank files (1.5.3)

[Kelvie Wong]

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.

I am using version 1.5.3 and I have tried all of the different diff
tools (save opendiff) that are supported by git -- but in the middle
of a rebase, whenever I run the mergetool, the LOCAL, REMOTE, and BASE
temporary files that are created are all empty.  The BACKUP file
remains, and still has the proper 3-way-merge conflict syntax (with
<<<< ==== >>>>) and such, but the other files are all empty -- and
thus the mergetool of choice does not read it (it shows up empty there
too, of course).

What could I do to fix this?  I'm confident that there are conflicts
(git tells me so, and I end up manually going through all the files in
emacs anyways, but it's very tedious); or is there another tool that
reads the 3-way-merge syntax (the < = >'s) and lets me pick one or the
other, or do I have to write my own?

I know there's just something funky on my system, because someone else
doesn't seem to have this problem on his computer -- maybe it is
because I use the svn rebase, but it does that when I rebase onto
another branch too.

Thanks.

-- 
Kelvie

Re: Mergetool generating blank files (1.5.3)

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 944 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Mergetool generating blank files (1.5.3)

[Russ Brown]

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.

-- 

Russ

Re: Mergetool generating blank files (1.5.3)

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]

On Thu, Sep 27, 2007 at 07:00:39PM +0000, Russ Brown wrote:
> 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.

  Indeed, it seems that since the last time I tested it, it now does
diff3 merging. I should reevaluate it :)

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Mergetool generating blank files (1.5.3)

[Theodore Tso]

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.

						- Ted

Re: Mergetool generating blank files (1.5.3)

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

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 :)

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Mergetool generating blank files (1.5.3)

[Peter Baumann]

On Fri, Sep 28, 2007 at 12:28:25AM +0200, Pierre Habouzit wrote:
> 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.

-Peter

Re: Mergetool generating blank files (1.5.3)

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]

On Fri, Sep 28, 2007 at 05:15:03AM +0000, Peter Baumann wrote:
> 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.

  For what I've seen, it's how meld works, and I find it nice too. Meld
is quite slow (python + gnomeish doesn't help) but well, I don't merge
things that often, so like said I think I'll give it a try for a while
and see if it has what it takes :)

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Mergetool generating blank files (1.5.3)

[Jeff King]

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.

-Peff

Re: Mergetool generating blank files (1.5.3)

[Pierre Habouzit]

[-- Attachment #1: Type: text/plain, Size: 850 bytes --]

On Thu, Sep 27, 2007 at 07:12:01PM +0000, Jeff King wrote:
> 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.

  I'm sorry but I find that the UI is terrible.

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Mergetool generating blank files (1.5.3)

[Jeff King]

On Thu, Sep 27, 2007 at 09:16:14PM +0200, Pierre Habouzit wrote:

> > Huh? I use xxdiff all the time, and it works fine.
> 
>   I'm sorry but I find that the UI is terrible.

Fair enough.

-Peff

Re: Mergetool generating blank files (1.5.3)

[Kelvie Wong]

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.

But oh well, I guess the answer here is to write a script that does it.

Kelvie

On 9/27/07, Pierre Habouzit <madcoder@debian.org> 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).
>
> --
> ·O·  Pierre Habouzit
> ··O                                                madcoder@debian.org
> OOO                                                http://www.madism.org
>
>


-- 
Kelvie

Re: Mergetool generating blank files (1.5.3)

[Junio C Hamano]

"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.

Re: Mergetool generating blank files (1.5.3)

[Kelvie Wong]

On 9/27/07, Junio C Hamano <gitster@pobox.com> wrote:
> "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.
>

#######################################
$ sh -x /usr/local/bin/git-mergetool --tool=meld
+ USAGE=[--tool=tool] [file to merge] ...
+ SUBDIRECTORY_OK=Yes
+ . git-sh-setup
+ unset CDPATH
+ [ -z  ]
+ LONG_USAGE=Usage: /usr/local/bin/git-mergetool [--tool=tool] [file
to merge] ...
+ [ -z Yes ]
+ git rev-parse --git-dir
+ GIT_DIR=/home/kelvie/src/trunk/.git
+ test -n /home/kelvie/src/trunk/.git
+ cd /home/kelvie/src/trunk/.git
+ pwd
+ GIT_DIR=/home/kelvie/src/trunk/.git
+ : /home/kelvie/src/trunk/.git/objects
+ require_work_tree
+ git rev-parse --is-inside-work-tree
+ test true = true
+ expr z--tool=meld : z-[^=]*=\(.*\)
+ merge_tool=meld
+ shift
+ break
+ test -z meld
+ test -z meld
+ type meld
+ test 0 -eq 0
+ git ls-files -u
+ sed -e s/^[^  ]*      //
+ sort -u
+ files=fmeprompter/src/qfmeparameterfloat.cpp
fmeprompter/src/qfmeparameterfloat.h
fmeprompter/src/qfmeparameterinteger.cpp
fmeprompter/src/qfmeparameterinteger.h
+ test -z fmeprompter/src/qfmeparameterfloat.cpp
fmeprompter/src/qfmeparameterfloat.h
fmeprompter/src/qfmeparameterinteger.cpp
fmeprompter/src/qfmeparameterinteger.h
+ echo Merging the files: fmeprompter/src/qfmeparameterfloat.cpp
fmeprompter/src/qfmeparameterfloat.h
fmeprompter/src/qfmeparameterinteger.cpp
fmeprompter/src/qfmeparameterinteger.h
Merging the files: fmeprompter/src/qfmeparameterfloat.cpp
fmeprompter/src/qfmeparameterfloat.h
fmeprompter/src/qfmeparameterinteger.cpp
fmeprompter/src/qfmeparameterinteger.h
+ git ls-files -u
+ sed -e s/^[^  ]*      //
+ sort -u
+ read i
+ printf \n

+ merge_file fmeprompter/src/qfmeparameterfloat.cpp
+ path=fmeprompter/src/qfmeparameterfloat.cpp
+ git ls-files -u -- fmeprompter/src/qfmeparameterfloat.cpp
+ f=100644 bd66831cc4c3fb2907bba0fa9bef6d3e696bf0a3 1
fmeprompter/src/qfmeparameterfloat.cpp
100644 10026c1391fc34485b54727f831ebecfde8711a5 2
fmeprompter/src/qfmeparameterfloat.cpp
100644 0d2e9decf73ae5f5e4143f3181b7c8435c20416c 3
fmeprompter/src/qfmeparameterfloat.cpp
+ test -z 100644 bd66831cc4c3fb2907bba0fa9bef6d3e696bf0a3 1
fmeprompter/src/qfmeparameterfloat.cpp
100644 10026c1391fc34485b54727f831ebecfde8711a5 2
fmeprompter/src/qfmeparameterfloat.cpp
100644 0d2e9decf73ae5f5e4143f3181b7c8435c20416c 3
fmeprompter/src/qfmeparameterfloat.cpp
+ BACKUP=fmeprompter/src/qfmeparameterfloat.cpp.BACKUP.4697
+ LOCAL=fmeprompter/src/qfmeparameterfloat.cpp.LOCAL.4697
+ REMOTE=fmeprompter/src/qfmeparameterfloat.cpp.REMOTE.4697
+ BASE=fmeprompter/src/qfmeparameterfloat.cpp.BASE.4697
+ mv -- fmeprompter/src/qfmeparameterfloat.cpp
fmeprompter/src/qfmeparameterfloat.cpp.BACKUP.4697
+ cp -- fmeprompter/src/qfmeparameterfloat.cpp.BACKUP.4697
fmeprompter/src/qfmeparameterfloat.cpp
+ git ls-files -u -- fmeprompter/src/qfmeparameterfloat.cpp
+ awk {if ($3==1) print $1;}
+ base_mode=100644
+ git ls-files -u -- fmeprompter/src/qfmeparameterfloat.cpp
+ awk {if ($3==2) print $1;}
+ local_mode=100644
+ git ls-files -u -- fmeprompter/src/qfmeparameterfloat.cpp
+ awk {if ($3==3) print $1;}
+ remote_mode=100644
+ base_present
+ test -n 100644
+ git cat-file blob :1:fmeprompter/src/qfmeparameterfloat.cpp
+ local_present
+ test -n 100644
+ git cat-file blob :2:fmeprompter/src/qfmeparameterfloat.cpp
+ remote_present
+ test -n 100644
+ git cat-file blob :3:fmeprompter/src/qfmeparameterfloat.cpp
+ test -z 100644 -o -z 100644
+ is_symlink 100644
+ test 100644 = 120000
+ is_symlink 100644
+ test 100644 = 120000
+ echo Normal merge conflict for 'fmeprompter/src/qfmeparameterfloat.cpp':
Normal merge conflict for 'fmeprompter/src/qfmeparameterfloat.cpp':
+ describe_file 100644 local fmeprompter/src/qfmeparameterfloat.cpp.LOCAL.4697
+ mode=100644
+ branch=local
+ file=fmeprompter/src/qfmeparameterfloat.cpp.LOCAL.4697
+ printf   {%s}:  local
  {local}: + test -z 100644
+ is_symlink 100644
+ test 100644 = 120000
+ base_present
+ test -n 100644
+ echo modified
modified
+ describe_file 100644 remote fmeprompter/src/qfmeparameterfloat.cpp.REMOTE.4697
+ mode=100644
+ branch=remote
+ file=fmeprompter/src/qfmeparameterfloat.cpp.REMOTE.4697
+ printf   {%s}:  remote
  {remote}: + test -z 100644
+ is_symlink 100644
+ test 100644 = 120000
+ base_present
+ test -n 100644
+ echo modified
modified
+ printf Hit return to start merge resolution tool (%s):  meld
Hit return to start merge resolution tool (meld): + read ans

+ touch fmeprompter/src/qfmeparameterfloat.cpp.BACKUP.4697
+ meld -- fmeprompter/src/qfmeparameterfloat.cpp.LOCAL.4697
fmeprompter/src/qfmeparameterfloat.cpp
fmeprompter/src/qfmeparameterfloat.cpp.REMOTE.4697


And then meld starts up, with the original file in the middle, and two
blank files on the side, LOCAL and REMOTE respectively.
-- 
Kelvie

Re: Mergetool generating blank files (1.5.3)

[Junio C Hamano]

"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?

Re: Mergetool generating blank files (1.5.3)

[Kelvie Wong]

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

On 9/27/07, Junio C Hamano <gitster@pobox.com> wrote:
> "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?
>
>


-- 
Kelvie

Re: Mergetool generating blank files (1.5.3)

[Junio C Hamano]

"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.

Re: Mergetool generating blank files (1.5.3)

[Junio C Hamano]

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 () {

Re: Mergetool generating blank files (1.5.3)

[Kelvie Wong]

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

Re: Mergetool generating blank files (1.5.3)

[Kelvie Wong]

On 9/27/07, Kelvie Wong <kelvie@ieee.org> wrote:
> 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
>

Hrm, on closer inspection, the old version of the mergetool script did this too.

It looks like the bug I mentioned does get fixed by that, and this is
a bug in emacs (or the way it's called).
-- 
Kelvie

Re: Mergetool generating blank files (1.5.3)

[Junio C Hamano]

"Kelvie Wong" <kelvie@ieee.org> writes:

>> > 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?

Actually, it seems that mergetool can take paths arguments, and
they need to be adjusted, so here is a fixed patch.

---
 git-mergetool.sh |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/git-mergetool.sh b/git-mergetool.sh
index a0e44f7..56ec993 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -12,6 +12,8 @@ USAGE='[--tool=tool] [file to merge] ...'
 SUBDIRECTORY_OK=Yes
 . git-sh-setup
 require_work_tree
+directory_prefix=$(git rev-parse --show-prefix)
+cd_to_toplevel
 
 # Returns true if the mode reflects a symlink
 is_symlink () {
@@ -378,7 +380,7 @@ if test $# -eq 0 ; then
 else
 	while test $# -gt 0; do
 		printf "\n"
-		merge_file "$1"
+		merge_file "$directory_prefix$1"
 		shift
 	done
 fi

Re: Mergetool generating blank files (1.5.3)

[Junio C Hamano]

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':"

Re: Mergetool generating blank files (1.5.3)

[Kelvie Wong]

On 9/27/07, Junio C Hamano <gitster@pobox.com> wrote:
> 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':"
>

--- a/git-mergetool       2007-09-24 09:08:23.000000000 -0700
+++ b/git-mergetool        2007-09-27 15:04:15.000000000 -0700
@@ -12,6 +12,7 @@
 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 @@
     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':"
@@ -251,7 +252,7 @@
            ;;
        emerge)
            if base_present ; then
-               emacs -f emerge-files-with-ancestor-command "$LOCAL"
"$REMOTE" "$BASE" "$path"
+               emacs -f emerge-files-with-ancestor-command "$LOCAL"
"$REMOTE" "$BASE" "$(basename "$path")"
            else
                emacs -f emerge-files-command "$LOCAL" "$REMOTE"
"$(basename "$path")"
            fi



Finally got it to work.  emacs (at least the version I'm using,
22.1.1) seems to set the $PWD via its first argument, that is,
$LOCAL's directory, and when it goes to save, it tries to save $path
on top of that.

The updated patch above would be just to use the basename, that is, if
it is certain that $LOCAL and $path will always reside in the same
directory -- and I believe, but am not certain, that this is the case.

Also, I am not sure if this is specific to my version of Emacs, so
perhaps some further testing is required.

-- 
Kelvie

Re: Mergetool generating blank files (1.5.3)

[Theodore Tso]

On Thu, Sep 27, 2007 at 03:23:44PM -0700, Kelvie Wong wrote:
> Finally got it to work.  emacs (at least the version I'm using,
> 22.1.1) seems to set the $PWD via its first argument, that is,
> $LOCAL's directory, and when it goes to save, it tries to save $path
> on top of that.

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.

> The updated patch above would be just to use the basename, that is, if
> it is certain that $LOCAL and $path will always reside in the same
> directory -- and I believe, but am not certain, that this is the case.

> Also, I am not sure if this is specific to my version of Emacs, so
> perhaps some further testing is required.

Yep, I've checked both emacs21 and emacs23-snapshot, and they both use
write-file, so this seems to be a long-standing bug (and I would call
it that) in emerge.el.  So a patch like what you suggested is probably
going to be needed.

						- Ted

Re: Mergetool generating blank files (1.5.3)

[Kelvie Wong]

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 :(

-- 
Kelvie

Re: Mergetool generating blank files (1.5.3)

[David Kastrup]

"Kelvie Wong" <kelvie@ieee.org> writes:

> 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 :(

It does.  For every buffer.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Mergetool generating blank files (1.5.3)

[Theodore Tso]

On Thu, Sep 27, 2007 at 02:41:23PM -0700, Junio C Hamano wrote:
> 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>

Acked-by: "Theodore Ts'o" <tytso@mit.edu>

						- Ted

Re: Mergetool generating blank files (1.5.3)

[David Kågedal]

"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.
>
> 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.

Since you are already using Emacs, let me suggest you use smerge
(together with ediff).

Use M-x smerge-mode and go over the conflicts and select which one you
want with C-c ^ m (for "mine") or C-c ^ o (for "other") or one of the
commands.  Or press C-c ^ E to run a three-window merge.

Or use the last directly by running M-x smerge-ediff.

-- 
David Kågedal