Re: Git commit path vs rebase path

[Ramsay Jones <ramsay@ramsay1.demon.co.uk>]

Johannes Sixt wrote:
> Am 5/14/2012 0:58, schrieb Ramsay Jones:
>> BTW, Johannes, earlier you said commit be39048 ("git-sh-setup.sh: Add an pwd()
>> function for MinGW", 17-04-2012) would fix the problem on MinGW; I'm not so
>> sure it will. 
> 
>> [...] problem (*which MinGW shares*) is that the
>> pwd() function is defined *after* the code that sets $GIT_DIR from which the
>> rebase state directory name is derived (see git-sh-setup.sh lines 223-239).
> 
> Good catch!
> 
> Nevertheless, if I set GIT_EDITOR to "notepad", 'git rebase -i' works to
> some degree. Leaving aside that it does not understand LF line endings, it
> opens the git-rebase-todo file; I can edit and save it. That is, it looks
> like a usable Windows style path was passed to Notepad. (This is with
> MinGW git, of course.)
> 

I was about to, confidently, proclaim that it should fail when
you run that rebase from a subdirectory ... Unfortunately, it
seems to work! *ahem*

The reason I was confident, is simply that I have seen this
pattern:

    p= ...some path...
    p=$(cd "$p" && pwd)

many times while debugging scripts on MinGW, so I 'know' that if
p is initially a relative path, then the result is an absolute
windows path. For example, while cwd is /home/ramsay/git then:

    .git => C:/msysgit/msysgit/home/ramsay/git/.git

Whereas if p is initially an absolute windows path, then the result
is a POSIX-like path, viz:

    C:/msysgit/msysgit/home/ramsay/git/.git => /usr/home/ramsay/git/.git

If you combine that with the behaviour of 'git rev-parse', thus:

    $ cd /home/ramsay/git
    $ git rev-parse --git-dir
    .git
    $ cd xdiff
    $ git rev-parse --git-dir
    C:/msysgit/msysgit/home/ramsay/git/.git
    $

you should see "git rebase -i" invoking the editor with a POSIX
path.

[BTW, I have noticed that I sometimes get different behaviour when
I type this stuff into an interactive shell. :(]

Anyway, a bit of debugging shows that I was right, kinda! :-D

I placed a "set -x" in git-sh-setup (line 222) just before the code
to set up GIT_DIR and ran git-rebase like so:

    $ cd /home/ramsay/git
    $ GIT_EDITOR=false ./bin-wrappers/git rebase -i master uname >ttt 2>&1
    $ cd xdiff
    $ GIT_EDITOR=false ../bin-wrappers/git rebase -i master uname >sss 2>&1
    $ diff ../ttt sss | more

which showed that in the subdirectory case, git was indeed invoking
the editor with a POSIX-like path. (The output files, ttt and sss, show
some other interesting/odd behaviour).

['uname' is an old branch of mine that, currently, is based on v1.7.10]

The reason it works, despite the above, is clear if you now run:

    $ GIT_EDITOR=args ../bin-wrappers/git rebase -i master uname

    ...

    +++ git var GIT_EDITOR
    ++ GIT_SEQUENCE_EDITOR=args
    ++ eval args '"$@"'
    +++ args /usr/home/ramsay/git/.git/rebase-merge/git-rebase-todo
    argv[0] = 'C:\msysgit\msysgit\home\ramsay\bin\args.exe'
    argv[1] = 'C:/msysgit/msysgit/home/ramsay/git/.git/rebase-merge/git-rebase-todo'

    ++ die_abort 'Could not execute editor'
    ++ rm -rf /usr/home/ramsay/git/.git/rebase-merge
    ++ die 'Could not execute editor'
    ++ die_with_status 1 'Could not execute editor'
    ++ status=1
    ++ shift
    ++ echo 'Could not execute editor'
    Could not execute editor
    ++ exit 1

[I'm sure you can guess what the args program looks like!]

So, the msys "path munging" of program arguments saves the day!

HTH

ATB,
Ramsay Jones