All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Heidelberg <markus.heidelberg@web.de>
To: David Aguilar <davvid@gmail.com>
Cc: Git mailing list <git@vger.kernel.org>
Subject: Re: [PATCH] contrib: add 'git difftool' for launching common merge  tools
Date: Mon, 19 Jan 2009 06:03:06 +0100	[thread overview]
Message-ID: <200901190603.06506.markus.heidelberg@web.de> (raw)
In-Reply-To: <402731c90901181634u32b39c87t6e88d9efef0d3485@mail.gmail.com>

David Aguilar, 19.01.2009:
> On Sun, Jan 18, 2009 at 11:25 AM, Markus Heidelberg
> <markus.heidelberg@web.de> wrote:
> > David Aguilar, 16.01.2009:
> >> +     meld|vimdiff)
> >> +             "$merge_tool_path" "$LOCAL" "$REMOTE"
> >> +             ;;
> >> +
> >> +     gvimdiff)
> >> +             "$merge_tool_path" -f "$LOCAL" "$REMOTE"
> >> +             ;;
> >
> > Maybe use '-c "wincmd l"' for Vim as in my patch for git-mergetool to
> > automatically place the cursor in the editable file? Useful for editing,
> > if git-difftool is used to diff a file from the working tree.
> >
> > See http://thread.gmane.org/gmane.comp.version-control.git/106109
> 
> 
> Very cool.  When you have unstaged changes git diff sends the local
> filename as the 2nd argument so I changed the vim command to "wincmd
> r" so that vim places the cursor on the right hand side.

Well, in "wincmd l" "l" doesn't mean "left", it doesn't mean "put the
cursor into the left window", it just moves the cursor into the next
right window. So "wincmd r" doesn't mean "put the cursor into the right
window", but "rotate the window" (see :help ctrl-w_r).

So with "wincmd r" the local file would be moved to the left side and
the index file to the right side, still containing the cursor. Not what
we want.

With "wincmd l" the local file would stay on the right side, the index
file on the left side, but the cursor would move from the left to the
right side. Now we can edit the local file.

> > You have deleted all the '-' chars from git-command, but when using it as the
> > name I think it's the preferred method, only when used as command then without
> > slash.
> 
> I was wondering about that.  I think I tried to follow the lead from
> the git-diff.txt documentation, but "diff" is a builtin and thus
> doesn't have an actual git-diff, so I see why they should be
> different.

Hmm, I don't think it makes a difference, whether it's a builtin or not.
git-diff only exists behind the scenes, invoking it as "git-diff"
doesn't work anymore with default settings. On the other hand, I can
also invoke "git difftool" without the slash, git can find it. The same
way I can for example call "git svn", which also isn't a builtin.

Markus

  reply	other threads:[~2009-01-19  5:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-16  8:00 [PATCH] contrib: add 'git difftool' for launching common merge tools David Aguilar
2009-01-18 19:25 ` Markus Heidelberg
2009-01-19  0:25   ` [PATCH v2] contrib: add 'git-difftool' for launching common diff tools David Aguilar
2009-01-19  4:45     ` Markus Heidelberg
2009-01-19  0:34   ` [PATCH] contrib: add 'git difftool' for launching common merge tools David Aguilar
2009-01-19  5:03     ` Markus Heidelberg [this message]
2009-01-19  5:32       ` David Aguilar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200901190603.06506.markus.heidelberg@web.de \
    --to=markus.heidelberg@web.de \
    --cc=davvid@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.