Re: Git in Outreachy?

From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Christian Couder <christian.couder@gmail.com>
Cc: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>,
	Jeff King <peff@peff.net>, git <git@vger.kernel.org>,
	Christian Couder <chriscool@tuxfamily.org>
Subject: Re: Git in Outreachy?
Date: Wed, 16 Sep 2020 22:27:40 +0200 (CEST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2009162206580.56@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <CAP8UFD0_75zR3xoBzbVZjgTY2+KvORLFNMZ36s8+m6KZyNTXPg@mail.gmail.com>

Hi Christian,

On Wed, 16 Sep 2020, Christian Couder wrote:

> On Mon, Sep 7, 2020 at 8:55 PM Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Mon, 7 Sep 2020, Kaartic Sivaraam wrote:
> >
> > > On 28-08-2020 12:26, Jeff King wrote:
> > >
> > > > I would appreciate help to find project ideas though. Are there
> > > > still scripts that are worth converting to C (excluding
> > > > git-bisect.sh and git-submodule.sh that are still worked on)?
> > >
> > > I think Dscho's e-mail linked below gives a nice overview of the
> > > various scripts and their likely status as of Jan2020:
> > >
> > > https://lore.kernel.org/git/nycvar.QRO.7.76.6.2001301154170.46@tvgsbejvaqbjf.bet/
> > >
> > > I'm guessing only the status of submodule has changed as it's being
> > > worked on now.
> >
> > No, not quite. The `git-merge-*.sh` ones I called "trivial" are already
> > being worked on by Alban Gruin:
> > https://lore.kernel.org/git/20200901105705.6059-1-alban.gruin@gmail.com/
> >
> > And `git-legacy-stash.sh` is no more, as of v2.27.0~180^2.
> >
> > But yes, other than that, my summary still holds.
>
> To summarize more, it seems to me that only the following scripts
> could be worth converting:
>
> git-difftool--helper.sh
> git-mergetool--lib.sh
> git-mergetool.sh
>
> I wonder if they are really worth converting though, as they should
> probably all be converted together and we would likely also need to
> convert the scripts in mergetools/ at the same time. And then there
> should be a way to still easily configure things for users. So perhaps
> a better way to approach this would be first to convert the scripts in
> mergetools/ into config files.

The biggest problem is that they're all entangled.
`git-difftool--helper.sh` sources `git-mergetool--lib.sh` and uses quite a
bit of its machinery.

As to converting the scripts to config files, I'd rather have them
hard-coded in the source code. Something along those lines:

struct mergetool {
	const char *can_merge;
	const char *can_diff;
	const char *diff_cmd
	const char *merge_cmd;
	const char *translate_merge_tool_path;
	const char *list_tool_variants;
	const char *exit_code_trustable;
} araxis = {
	.diff_cmd = "\"$merge_tool_path"\ -wait -2 \"$LOCAL\" \"$REMOTE\" >/dev/null 2>&1",
	.merge_cmd = "if $base_present\n"
		"then\n"
		" \"$merge_tool_path\" -wait -merge -3 -a1"
		"  \"$BASE\" \"$LOCAL\" \"$REMOTE\" \"$MERGED\" >/dev/null 2>&1\n"
		"else\n"
                " \"$merge_tool_path\" -wait -2"
		"  \"$LOCAL\" \"$REMOTE\" \"$MERGED\" >/dev/null 2>&1\n"
		"fi",
	.translate_merge_tool_path = "echo compare"
}, [...]

I would then probably try to implement the bare minimum for the
`difftool--helper` command to work (re-implementing in C only the parts of
`mergetool--lib` that are necessary), and only in a next patch series work
on `mergetool`.

Ciao,
Dscho