Re: [GSoC] Regarding "Convert scripts to builtins"
Hi Wink, On Thu, 22 Mar 2018, Wink Saville wrote: > On Thu, Mar 22, 2018, 10:32 AM Johannes Schindelin > wrote: > > I now have a version 3: "[RFC PATCH v3 0/9] rebase-interactive:" Great! > Cheers, > Winthrop Lyon Saville III (I had to repsond with my full name although I > always use my nick name, Wink, just because Johannes seems so formal :) Yes, I am formal. All Germans are. It's a matter of form. Ciao, Johannes
Re: [GSoC] Regarding "Convert scripts to builtins"
On Thu, Mar 22, 2018, 10:32 AM Johannes Schindelin wrote: > > Hi Wink, > > > Please see "[RFC PATCH 0/3] rebase-interactive" and > > "[RFC PATCH v2 0/1] rebase-interactive: ...". I'm looking for > > advice on how to proceed. > > Sadly, I had almost no time to spend on the Git mailing list today, but I > will have a look tomorrow, okay? NP, I totally understand and, of course, I now have a version 3: "[RFC PATCH v3 0/9] rebase-interactive:" Cheers, Winthrop Lyon Saville III (I had to repsond with my full name although I always use my nick name, Wink, just because Johannes seems so formal :)
Re: [GSoC] Regarding "Convert scripts to builtins"
Hi Wink, On Wed, 21 Mar 2018, Wink Saville wrote: > I plead guilty to being the preson refactoring --preserve-merges. But > after reading this and seeing that --recreate-merges is coming and > possibly git-rebase--* moving to C I'm worried I'd be messing things up. Don't worry. We will just work together to avoid messing anything up. > Also, Eric Sunshine felt my v1 changes causes the blame information to > be obscured. So I created a v2 change which keeps everything in the > git-rebase--interactive.sh. Great! > Please see "[RFC PATCH 0/3] rebase-interactive" and > "[RFC PATCH v2 0/1] rebase-interactive: ...". I'm looking for > advice on how to proceed. Sadly, I had almost no time to spend on the Git mailing list today, but I will have a look tomorrow, okay? Ciao, Johannes
Re: [GSoC] Regarding "Convert scripts to builtins"
On Wed, Mar 21, 2018 at 5:32 AM, Johannes Schindelin wrote: > Hi Paul, > > Note! There is one exception, and it is not even a full script. As > everybody knows who follows my patch series on this here mailing list, I > consider --preserve-merges one of my stupidest design mistakes ever. To > undo this (or at least to alleviate the damage I caused), I already > submitted a patch series to introduce a superseding option: > --recreate-merges. This patch series is on hold due to the -rc phase of > v2.17 and will be kicked back into action after v2.17.0 final is out. As > it is my hope that --preserve-merges can be deprecated in favor of > --recreate-merges (and eventually even phased out of Git), I would be > totally cool with git-rebase--preserve-merges.sh being factored out of > git-rebase--interactive.sh before converting the latter to pure C, and > leaving the --preserve-merges script alone until the time when it is put > to rest. > > (While I was sleeping, leaving this mail unfinished, to be completed and > sent today, a patch series was sent to the mailing list that seems to > perform this refactoring of --preserve-merges into its own script.) I plead guilty to being the preson refactoring --preserve-merges. But after reading this and seeing that --recreate-merges is coming and possibly git-rebase--* moving to C I'm worried I'd be messing things up. Also, Eric Sunshine felt my v1 changes causes the blame information to be obscured. So I created a v2 change which keeps everything in the git-rebase--interactive.sh. Please see "[RFC PATCH 0/3] rebase-interactive" and "[RFC PATCH v2 0/1] rebase-interactive: ...". I'm looking for advice on how to proceed.
Re: [GSoC] Regarding "Convert scripts to builtins"
Hi Paul, On Mon, 19 Mar 2018, Paul Sebastian Ungureanu wrote: > I am interested in the "Convert scripts to builtins" project. I have > recently started to analyze it better and see exactly what it entails > and a few questions came to my mind. Great! > First of all, I find it difficult to pick which scripts would benefit > the most by being rewritten. Which ones do you use, personally? I'd go by that measure if I were you. Oh, and if you are not really familiar with Perl, you may want to stay away from those scripts. Perl was jokingly labeled a "write-only" programming language in my presence, and when I see some of my own Perl code, I would agree at least partially. > I am thinking of git bisect, git stash and git rebase since these are > maybe some of the most popular commands of Git. However, on the other > side, scripts like git-rebase--interactive.sh and git-bisect.sh are also > subject of other GSoC projects. Should I steer away from these projects > or can I consider them? I second Christian's suggestion: just apply for a couple projects you would like to work on. If there really should be a conflict with another strong proposal, we can always work something out. > Secondly, what is too little or too much? Judging by past GSoC's, even a moderately-sized script like git-bisect.sh is too much in one go. Break it down into smaller pieces, start by adding a --helper builtin (or continue by using one like git-bisect--helper), add things incrementally. If you get the proposed part done faster, I am sure you'll find tons of other things to do ;-) Now to your list of scripts. I reordered them so that I could group the list into logical chunks, and then ordered them by what would be my personal priority (most important scripts first). > * git/git-rebase--am.sh > * git/git-rebase--merge.sh These are pretty interesting, and also pretty small. They would be *prime* candidates for turning into builtins, methinks. As we already have a builtin rebase--helper, that would be a natural way to go: if you can analyze those scripts and figure out a natural progression of incremental steps to convert them (see e.g. https://github.com/git/git/compare/4e7524e012f...c44a4c650c which is how I moved some parts of git-rebase--interactive.sh into the rebase--helper: starting with the code generating the todo list, continuing with transform_todo_ids, then check_commit_sha, skip_unnecessary_picks and finally rearrange_squash), a very smooth timeline should fall right out of that analysis. One slight complication might be the fact that rebase--helper is really only catering to rebase -i so far. So `rebase--helper --continue` assumes that it should continue an interactive rebase. This assumption would have to be shunned, by adding a function that determines which type of rebase (if any) is currently in progress, and using that to figure out what function to call to handle the --continue. > * git/git-rebase.sh This script is a bit larger than rebase--am and rebase--merge combined, but the biggest reason *not* to start with it is: git-rebase.sh is just an orchestrator of the git-rebase--* scripts, doing little more than command-line parsing and then handing off to the respective "backends". Consequently, I would consider it to make most sense to convert the rebase--* scripts *first*, and only when that is done, convert git-rebase (renaming rebase--helper to rebase). Note! There is one exception, and it is not even a full script. As everybody knows who follows my patch series on this here mailing list, I consider --preserve-merges one of my stupidest design mistakes ever. To undo this (or at least to alleviate the damage I caused), I already submitted a patch series to introduce a superseding option: --recreate-merges. This patch series is on hold due to the -rc phase of v2.17 and will be kicked back into action after v2.17.0 final is out. As it is my hope that --preserve-merges can be deprecated in favor of --recreate-merges (and eventually even phased out of Git), I would be totally cool with git-rebase--preserve-merges.sh being factored out of git-rebase--interactive.sh before converting the latter to pure C, and leaving the --preserve-merges script alone until the time when it is put to rest. (While I was sleeping, leaving this mail unfinished, to be completed and sent today, a patch series was sent to the mailing list that seems to perform this refactoring of --preserve-merges into its own script.) > * git/git-add--interactive.perl I personally would *love* to see this converted. But it is a huge task, likely too big for a single GSoC project. But if you look at the code and figure out a natural way to break this project down into smaller, incremental conversions, that would be a way to go. > * git/git-bisect.sh -- there is a project about this > * git/git-rebase--interactive.sh -- there is a project about this > * git/git-submodule.sh -- there was a project about this Indeed, there are projects ab
Re: [GSoC] Regarding "Convert scripts to builtins"
On Tue, Mar 20, 2018 at 12:11 AM, Christian Couder wrote: > On Sun, Mar 18, 2018 at 11:15 PM, Paul Sebastian Ungureanu >> First of all, I find it difficult to pick which scripts would benefit >> the most by being rewritten. I am thinking of git bisect, git stash >> and git rebase since these are maybe some of the most popular commands >> of Git. However, on the other side, scripts like >> git-rebase--interactive.sh and git-bisect.sh are also subject of other >> GSoC projects. Should I steer away from these projects or can I >> consider them? > > If you are interested in converting these scripts, you should probably > ask publicly to the former GSoC students who have been working on > these projects if they still plan to continue working on them of if > they are ok to let you finish/continue their work. You will get extra > bonus points if they agree to help you or maybe co-mentor you. I realize that you were perhaps talking about other potential GSoC students who are also writing proposals about converting one of these scripts. If you care about the other proposals though, you should probably just write two proposals as we will have at most 2 GSoC students this year. Just try to have different possible mentors interested in your 2 proposals.
Re: [GSoC] Regarding "Convert scripts to builtins"
Hi, On Sun, Mar 18, 2018 at 11:15 PM, Paul Sebastian Ungureanu wrote: > Hello, > > I am interested in the "Convert scripts to builtins" project. I have > recently started to analyze it better and see exactly what it entails > and a few questions came to my mind. Great! As other potential GSoC students are also interested I'm adding them into Cc. > First of all, I find it difficult to pick which scripts would benefit > the most by being rewritten. I am thinking of git bisect, git stash > and git rebase since these are maybe some of the most popular commands > of Git. However, on the other side, scripts like > git-rebase--interactive.sh and git-bisect.sh are also subject of other > GSoC projects. Should I steer away from these projects or can I > consider them? If you are interested in converting these scripts, you should probably ask publicly to the former GSoC students who have been working on these projects if they still plan to continue working on them of if they are ok to let you finish/continue their work. You will get extra bonus points if they agree to help you or maybe co-mentor you. > Secondly, what is too little or too much? On one hand, I do want to do > my best and help the Git community as much as I can. On the other > hand, I do not want to have too much on my plate and not be able to > finish my project. Considering that mentors have already decided that > git rebase --interactive and git bisect are enough for two projects, > how could I quantify the time required for each command? Looking back > at the previous editions of GSoC I noticed that most projects were > focused on only one command. Yeah, I don't think it is a good idea to focus on more than one command per project. It could be possible if there were really small scripts to convert, but I think those have been already converted. It could perhaps be possible if 2 scripts were very similar, but I don't think there are similar enough scripts to convert. You can however submit more than one proposal, so you could for example submit one proposal to convert one script and another one to convert another script. > From my research, these are the scripts that could be subject of this > project. Which ones do you think could be the best choice for a > project of this kind? I think it is definitely a good idea to work on a script that has started to be converted. Make sure that no one is still actively working on converting it though. I think the scripts related to other versions control systems are not a good choice as they are not really part of the core of Git. It is also a good idea to choose scripts that potential mentors are familiar with. > * git/git-add--interactive.perl > * git/git-archimport.perl > * git/git-bisect.sh -- there is a project about this > * git/git-cvsexportcommit.perl > * git/git-cvsimport.perl > * git/git-cvsserver.perl > * git/git-difftool--helper.sh > * git/git-filter-branch.sh > * git/git-instaweb.sh > * git/git-merge-octopus.sh > * git/git-merge-one-file.sh > * git/git-merge-resolve.sh > * git/git-mergetool--lib.sh > * git/git-mergetool.sh > * git/git-quiltimport.sh > * git/git-rebase--am.sh > * git/git-rebase--interactive.sh -- there is a project about this > * git/git-rebase--merge.sh > * git/git-rebase.sh > * git/git-remote-testgit.sh > * git/git-request-pull.sh > * git/git-send-email.perl > * git/git-stash.sh > * git/git-submodule.sh -- there was a project about this > * git/git-svn.perl > * git/git-web--browse.sh It would be interesting to know the number of lines of code for each of these script, as it could give an idea about how big the task of fully converting the script could be. > I look forward to hearing from you. I will also submit a draft of my > proposal soon enough. Great! Christian.
