Reimplement git subtree as a built-in

[dscho]

The git subtree command is currently implemented as a shell script and it lives inside contrib/subtree/. There was previously an attempt to move it out of contrib/, but there was the concern of adding yet another scripted command (with all the problems that brings with it).

Using the OPT_SUBCOMMAND infrastructure, this project is about reimplementing the individual subcommands one by one.

In contrast to earlier projects that converted shell scripts to pure C versions, we want to be mindful to avoid too-literal translations. For example, instead of using the --grep= argument of the revision walking machinery, we will want to implement a precise search through the commit messages via strstr() and avoid spawning a new process. And instead of near-duplicating the logic of find_latest_squash and find_existing_splits, there are probably better ways to do this in C, ways that avoid code duplication.

However, just like previous conversions, this project could start by renaming git-subtree.sh to git-subtree--helper.sh while moving it to the top-level, moving the test script to t/ and implementing a builtin/subtree.c that simply shells out to the helper. That way, subcommands can be converted incrementally (and even independently).

[phil-blain]

I'm a little bit unsure about that idea, given the general lack of interest from mailing list regulars for any bug report in git subtree...

Moving it out of contrib does imply (at least to me) some sort of "support", which I'm not sure the project would be interested in providing.

Just my 2 cents...

[dscho]

@phil-blain the lack of interest might very well be explained by git subtree living in contrib/.

FWIW Git for Windows ships with git subtree for I don't know how long, so there is kind of some support already.

[dscho]

Besides, there was https://lore.kernel.org/git/[email protected]/, so there is interest in getting this command into mainline.

[vinayakdsci]

Hey! If possible, I would be very happy to work on this issue.

[dscho]

@vinayakdsci excellent! Are you already a little bit familiar with Git's source code? Do you have a preferred development environment? In other words: how can I help?

[vinayakdsci]

Thanks a lot for replying, @dscho! I have read the Git documentation and developer guide, and the source code thoroughly. Should I introduce myself on the mailing list, too?

[dscho]

Should I introduce myself on the mailing list, too?

You can do that, but it's no requirement.

[dscho]

I have read the Git documentation and developer guide, and the source code thoroughly.

Even more important, I think, would be to look at the commit history where new builtins were added. git log --diff-filter=A builtin/ should be a good start.

[vinayakdsci]

Got it. I'll start right away.

[vinayakdsci]

Hey @dscho! I have been trying to follow your advice to make progress, but it looks like I am stuck in a mess.
Could you help? I am unable to understand where to place the shell file for the subtree command.
(Once that is done, I'll try to call it through C code placed in builtin/)

[dscho]

I am unable to understand where to place the shell file for the subtree command.
(Once that is done, I'll try to call it through C code placed in builtin/)

The idea is not to move the shell file. The idea is to re-implement what the shell script does, in C...

[dscho]

@vinayakdsci here are a couple of commits that demonstrate what will need to be done for this ticket: git/git@main...dscho:git:turn-subtree-into-a-built-in^

Make no mistake, this is not an easy project. It will require effort and care, it's not something you can wing by merely copying files around and then adding a tiny bit of glue.

[vinayakdsci]

@dscho okay! I am sorry for the late reply.
The commits are a great starting point. I understand that it is not easy, what I meant was to move the sh file to the top level, and then implement C code incrementally. But these commits are really a good base to start from. Thanks!

[dscho]

In the past, we indeed tried this incremental approach, but it encourages too literal a translation from shell to C, which results in suboptimal code...