From: John Keeping <john@keeping.me.uk>
To: David Aguilar <davvid@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Feb 2013, #01; Fri, 1)
Date: Sun, 3 Feb 2013 13:02:37 +0000 [thread overview]
Message-ID: <20130203130237.GS1342@serenity.lan> (raw)
In-Reply-To: <CAJDDKr6bPjKwe3NitvGCec2LyesY3yL=UtN85Bsox-bGWN=qeA@mail.gmail.com>
On Sun, Feb 03, 2013 at 04:13:22AM -0800, David Aguilar wrote:
> On Sat, Feb 2, 2013 at 9:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > Regarding these two topics....
> >
> >> * da/mergetool-docs (2013-01-30) 7 commits
> >> - doc: generate a list of valid merge tools
> >> - mergetool--lib: list user configured tools in '--tool-help'
> >> - fixup! doc: generate a list of valid merge tools
> >> - fixup! mergetool--lib: add functions for finding available tools
> >> - mergetool--lib: add functions for finding available tools
> >> - mergetool--lib: improve the help text in guess_merge_tool()
> >> - mergetool--lib: simplify command expressions
> >> (this branch uses jk/mergetool.)
> >>
> >> Build on top of the clean-up done by jk/mergetool and automatically
> >> generate the list of mergetool and difftool backends the build
> >> supports to be included in the documentation.
> >>
> >> Will merge to 'next', after squashing the fixup! commits from John
> >> Keeping.
> >>
> >>
> >> * jk/mergetool (2013-01-28) 8 commits
> >> - mergetools: simplify how we handle "vim" and "defaults"
> >> - mergetool--lib: don't call "exit" in setup_tool
> >> - mergetool--lib: improve show_tool_help() output
> >> - mergetools/vim: remove redundant diff command
> >> - git-difftool: use git-mergetool--lib for "--tool-help"
> >> - git-mergetool: don't hardcode 'mergetool' in show_tool_help
> >> - git-mergetool: remove redundant assignment
> >> - git-mergetool: move show_tool_help to mergetool--lib
> >> (this branch is used by da/mergetool-docs.)
> >>
> >> Cleans up mergetool/difftool combo.
> >>
> >> This is looking ready for 'next'.
> >
> > Do the tips of these two topics look reasonable to both of you, or
> > are there anything you sent but I missed?
>
> It looks good to go. The additional "|| :" in the makefile is a nice
> touchup that made it more robust too.
Looks good to me as well.
John
next prev parent reply other threads:[~2013-02-03 13:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-01 22:09 What's cooking in git.git (Feb 2013, #01; Fri, 1) Junio C Hamano
2013-02-03 5:44 ` Junio C Hamano
2013-02-03 12:13 ` David Aguilar
2013-02-03 13:02 ` John Keeping [this message]
2013-02-03 19:43 ` Junio C Hamano
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=20130203130237.GS1342@serenity.lan \
--to=john@keeping.me.uk \
--cc=davvid@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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.