-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-implement git add -i
as built-in
#1871
Comments
Okay, here goes a somewhat unstructured analysis toward coming up with a timeline. First things first: the most successful strategy to convert a script to a built-in appears to introduce a built-in helper first, extracting functionality from the script and then calling the helper from the script. A good example to follow is 3d5ec65. It introduces a new helper, written in C, and we should do the same, following the same naming convention git-stash--helper: we should call our helper git-add--helper. I would even recommend introducing the helper without any functionality first, just to get those changes out of the way: new file builtin/add--helper.c, then the associated changes in Now let's look at https://github.com/git/git/blob/v2.19.1/git-add--interactive.perl. There is already some logical code flow structuring by grace of having functions (or "subroutines", as Perl calls them, memorialized via the keyword sub). Let's see whether those functions give us a good structure for the conversion to follow. The first function is called
Since it is the first real code move, I would probably give this 1-3 days to get right.
I think I would give this a good 2 weeks to get right. The Same goes, unfortunately, for And as
So list_and_choose and its callees are the next task, and it is big. 3-4 weeks, I would guesstimate, maybe even more. I think this is the big one, though. There are a couple of *_cmd commands after that, which seem to basically rely on list_and_choose and then do only minimal things on top. Those functions would be the next tasks. Probably a couple of days, each, revert_cmd maybe a bit more (judging by its size). Then there are a lot of patch parsing/reassembling functions up until (and including) reassemble_patch, and they seem to pass around Perl arrays. I think that this is basically all needed for edit_hunk_manually, but I have not analyzed it all that well yet.
This concludes the timeline so far, as far as my best guess of a realistic one goes, and we'll have to take it from there, when we reach that point. |
Oh, and regression tests! There is |
This was started by @slavicaDj |
Progress can be seen at gitgitgadget#103 |
Actually, progress can be seen at gitgitgadget#170, gitgitgadget#171, gitgitgadget#172, gitgitgadget#173, gitgitgadget#174 and , gitgitgadget#175. Let's continue there. |
This is an outline for a feature, rather than a bug report.
One of the relatively few remaining scripted parts (after turning
rebase
,rebase -i
andstash
into built-in commands, which are still experimental but should replace the scripted versions before long), the next one in line seems to begit-add--interactive.perl
.Here is a head-start: https://public-inbox.org/git/1494907234-28903-1-git-send-email-bnmvco%40gmail.com/t
I shall fill in more details as I get around to analyze the source code and come up with a good project plan.
The text was updated successfully, but these errors were encountered: