mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Kaartic Sivaraam <>
To: Abhishek Kumar <>,
Cc:, Johannes Schindelin <>
Subject: Re: [GSoC][RFC] Convert mergetool to builtin
Date: Thu, 19 Mar 2020 14:12:16 +0530	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Abishek,

Just wanted to share a general suggestion which is not related to your 
proposal. In future, when you quote a portion of the e-mail retain the 
complete meta information about the quote (like the one you see below) 
or the person who wrote the quoted portion at the very least. It helps 
people who join late in the discussion to *quickly* get up-to-speed with 
the discussion.

Anyways, good luck with your proposal. :)

On 18-03-2020 22:00, Abhishek Kumar wrote:
>>> ### Conversion of mergetool--lib
>>> As mentioned earlier, conversion of the mergetool-related scripts has to be
>>> spread over 2-3 SoC or similar projects due to the size of scripts involved.
>>> Conversion of mergetool would set up most of the plumbing required for
>>> mergetool--lib and makes the subsequent conversion possible.
>> I wonder if it would be better to convert first
>> and then and that are using
>> it.
> I had been agonizing over this decision while I was initially writing
> the proposal.
> My justifications for over at the time were:
> 1. makes many more calls to git subcommands than mergetool--lib.
> Therefore, its performance improves from both moving from bash to C and use of
> git internals.
> 2. I had *incorrectly* counted overall lines to be over 1,700 with
> 1,200 lines for mergetool--lib + difftool--helper + mergetools/ whereas it
> actually stands at rather manageable 1,000 lines with mergetools/ being fairly
> formulaic.
> There are solid reasons to consider the conversion of mergetool--lib too:
> 1. The code path of difftool-helper would be entirely in C, improving its
> performance on Windows particularly well.
> 2. It has two well-defined entry points, which makes conversion straightforward
> and with less code churn.
> 3. It could be done with the more frequently-adopted approach of script
> calling the builtin.
> As it stands now, I am open to converting either scripts.
> I have CC'ed Johannes as well. I am sure he would like to weigh in
> this discussion.

  reply	other threads:[~2020-03-19  8:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-18 16:30 [GSoC][RFC] Convert mergetool to builtin Abhishek Kumar
2020-03-19  8:42 ` Kaartic Sivaraam [this message]
2020-03-22 11:27 ` Christian Couder
  -- strict thread matches above, loose matches on Subject: below --
2020-03-08 17:30 Abhishek Kumar
2020-03-12  1:15 ` Christian Couder

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:

  List information:

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

  git send-email \ \ \ \ \ \ \

* 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.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).