Re: Git in Outreachy?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Christian,

On Sat, 19 Sep 2020, Christian Couder wrote:

> On Wed, Sep 16, 2020 at 10:27 PM Johannes Schindelin
> <Johannes.Schindelin@xxxxxx> wrote:
>
> > On Wed, 16 Sep 2020, Christian Couder wrote:
>
> > > 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.
>
> Yeah, I agree this is an issue.
>
> > As to converting the scripts to config files, I'd rather have them
> > hard-coded in the source code.
>
> I am not sure what are the pros and cons of hardcoding vs config files
> in this case.

The thing is: `make install` does not install a Git config. That's why I
want the defaults hard-coded.

Of course, it should be possible to override those hard-coded defaults via
the config. That should go without saying.

Ciao,
Dscho

> My opinion is that config files would make it easier for people to
> contribute what's needed for new tools, while hardcoding might make it
> more easily extensible for us and might reduce backward compatibility
> issues.
>
> > 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`.
>
> Thanks for your opinion on this. For now I think it needs to be
> discussed more before we could suggest it as a project.
>
> Best,
> Christian.
>




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux