git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Derrick Stolee <stolee@gmail.com>
Cc: Jakub Narebski <jnareb@gmail.com>,
	Shourya Shukla <shouryashukla.oo@gmail.com>,
	christian.couder@gmail.com, t.gummerer@gmail.com,
	git@vger.kernel.org, gitster@pobox.com
Subject: Re: Converting scripted commands to built-ins, was Re: [GSoC] Exploring Previous year Projects
Date: Fri, 31 Jan 2020 10:32:17 +0100 (CET)
Message-ID: <nycvar.QRO.7.76.6.2001311007590.46@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <39a8c249-f0bc-fb0f-2ed5-5ecceb6d4789@gmail.com>

Hi Stolee,

On Thu, 30 Jan 2020, Derrick Stolee wrote:

> On 1/30/2020 6:10 AM, Johannes Schindelin wrote:
> > Large parts of `git submodule` are already implemented in `git
> > submodule--helper`, so that's a head start (thanks Stephan Beller!).
>
> As I recall, a bit part of what prevented more going into submodule--helper
> was isolating the_repository and allowing multiple repositories in-memory
> at once. That effort has stalled since Stephan has moved to other things.
> (I will also admit that perhaps I am wrong: is it complete, rather than
> stalled?)

There was definitely a push toward using `the_repository` in more places,
essentially making the entire code base a bit more object-oriented. My
impression is that this effort has largely stalled since Stephan and Duy
moved to other things.

However, this push is not exactly necessary to make `git submodule` a
built-in, much like `git push` can be a built-in even if it has to work on
two different repositories when run locally: it simply spawns a `git
receive-pack` in the repository to push to, rather than handling two
repositories in the same memory space.

The same is true for `git submodule`, of course: it can very easily spawn
processes for all the submodules. And that's what the `submodule--helper`
already does ;-)

> I would be happy to see more progress in this area, and it could be a
> good way to get familiar with the codebase and submitting patches.

I am of two minds here. On the one hand, I am eager to get rid of issues
such as https://github.com/git-for-windows/git/issues/1661, i.e. issues
that are solely due to Git requiring a Unix shell interpreter to run some
subcommands.

On the other hand... it is well known, I believe, what I think of
the design of Git's submodules feature. Putting an effort into making them
easier to use will not change this design.

In my mind, it would make more sense to focus on making partial clone and
sparse checkout a thing, and then combine it with a built-in version of
`git subtree` to include dependencies' commit history. Yes, I do suspect
that git-subtrac is going the wrong direction from git-subtree.

> > Realistically, I think that it would be possible for a GSoC student
> > who is already very familiar with the code base and with submodules to
> > finish the conversion of `git submodule` in one season.
>
> Even assuming the most generous definition of "very familiar" I'm not sure
> this is the case. But I also don't meet the bar of "very familiar" when it
> comes to the submodule code.

Hmm. I guess you're right, and it actually matches my earlier assessment:
https://lore.kernel.org/git/nycvar.QRO.7.76.6.1904031957480.41@tvgsbejvaqbjf.bet/

While it would be more satisfying for a prolific student to "complete" the
conversion in 3 months, it does not _have_ to be rushed that way. There
are tons of things to learn along the way, which is also part of GSoC's
mission.

The good news is that it is not an all-or-nothing project. Just like the
conversion of `git rebase` to C, which took several years, and the effort
of several contributors (implementing merge-recursive in C, then the
sequencer, then letting most of `rebase -i` be performed by the sequencer,
then the built-in `git am`, then the two GSoC projects to convert `git
rebase` and `git rebase -i`, extracting and deprecating `rebase -p` and of
course implementing the replacement for it: `rebase -r`), `git submodule`
_can_ and should be converted incrementally.

> So, I'm sending this message just to say "DRAGONS BE HERE" and recommend
> taking on a smaller project.

I can get behind that pretty good advice ;-)

Thanks for weighing in,
Dscho

  reply index

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-29 17:12 Shourya Shukla
2020-01-29 19:15 ` Jakub Narebski
2020-01-30 11:10   ` Converting scripted commands to built-ins, was " Johannes Schindelin
2020-01-30 15:14     ` Derrick Stolee
2020-01-31  9:32       ` Johannes Schindelin [this message]
2020-01-31  9:57         ` Johannes Schindelin

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.2001311007590.46@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=shouryashukla.oo@gmail.com \
    --cc=stolee@gmail.com \
    --cc=t.gummerer@gmail.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

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git