{"thread":{"id":"48077","subject":"[GSoC] Regarding \"Convert scripts to builtins\"","startedAt":"2018-03-18T22:15:48Z","lastAt":"2018-03-23T09:49:01Z","messageCount":8,"participants":["Paul Sebastian Ungureanu","Christian Couder","Johannes Schindelin","Wink Saville"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"342115","messageId":"CADzBBBb0KDVJiX2WSNW=vC6b6paWoK=5XrnZNAY+pwpcu-t9JA@mail.gmail.com","threadId":"48077","inReplyTo":null,"subject":"[GSoC] Regarding \"Convert scripts to builtins\"","fromName":"Paul Sebastian Ungureanu","fromEmail":"ungureanupaulsebastian@gmail.com","sentAt":"2018-03-18T22:15:42Z","receivedAt":"2018-03-18T22:15:48Z","isPatch":false,"sender":{"key":"ungureanupaulsebastian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/24317622?v=4"},"body":"Hello,\n\nI am interested in the \"Convert scripts to builtins\" project. I have\nrecently started to analyze it better and see exactly what it entails\nand a few questions came to my mind.\n\nFirst of all, I find it difficult to pick which scripts would benefit\nthe most by being rewritten. I am thinking of git bisect, git stash\nand git rebase since these are maybe some of the most popular commands\nof Git. However, on the other side, scripts like\ngit-rebase--interactive.sh and git-bisect.sh are also subject of other\nGSoC projects. Should I steer away from these projects or can I\nconsider them?\n\nSecondly, what is too little or too much? On one hand, I do want to do\nmy best and help the Git community as much as I can. On the other\nhand, I do not want to have too much on my plate and not be able to\nfinish my project. Considering that mentors have already decided that\ngit rebase --interactive and git bisect are enough for two projects,\nhow could I quantify the time required for each command? Looking back\nat the previous editions of GSoC I noticed that most projects were\nfocused on only one command.\n\nFrom my research, these are the scripts that could be subject of this\nproject. Which ones do you think could be the best choice for a\nproject of this kind?\n\n * git/git-add--interactive.perl\n * git/git-archimport.perl\n * git/git-bisect.sh -- there is a project about this\n * git/git-cvsexportcommit.perl\n * git/git-cvsimport.perl\n * git/git-cvsserver.perl\n * git/git-difftool--helper.sh\n * git/git-filter-branch.sh\n * git/git-instaweb.sh\n * git/git-merge-octopus.sh\n * git/git-merge-one-file.sh\n * git/git-merge-resolve.sh\n * git/git-mergetool--lib.sh\n * git/git-mergetool.sh\n * git/git-quiltimport.sh\n * git/git-rebase--am.sh\n * git/git-rebase--interactive.sh -- there is a project about this\n * git/git-rebase--merge.sh\n * git/git-rebase.sh\n * git/git-remote-testgit.sh\n * git/git-request-pull.sh\n * git/git-send-email.perl\n * git/git-stash.sh\n * git/git-submodule.sh -- there was a project about this\n * git/git-svn.perl\n * git/git-web--browse.sh\n\nI look forward to hearing from you. I will also submit a draft of my\nproposal soon enough.\n\nBest regards,\nPaul Ungureanu\n"},{"id":"342263","messageId":"CAP8UFD0aQxSZVRfOHUP80H+677zoNWPU1pdg7v4Qk+gKXCG8eg@mail.gmail.com","threadId":"48077","inReplyTo":"CADzBBBb0KDVJiX2WSNW=vC6b6paWoK=5XrnZNAY+pwpcu-t9JA@mail.gmail.com","subject":"Re: [GSoC] Regarding \"Convert scripts to builtins\"","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2018-03-19T23:11:50Z","receivedAt":"2018-03-19T23:11:57Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi,\n\nOn Sun, Mar 18, 2018 at 11:15 PM, Paul Sebastian Ungureanu\n<ungureanupaulsebastian@gmail.com> wrote:\n> Hello,\n>\n> I am interested in the \"Convert scripts to builtins\" project. I have\n> recently started to analyze it better and see exactly what it entails\n> and a few questions came to my mind.\n\nGreat! As other potential GSoC students are also interested I'm adding\nthem into Cc.\n\n> First of all, I find it difficult to pick which scripts would benefit\n> the most by being rewritten. I am thinking of git bisect, git stash\n> and git rebase since these are maybe some of the most popular commands\n> of Git. However, on the other side, scripts like\n> git-rebase--interactive.sh and git-bisect.sh are also subject of other\n> GSoC projects. Should I steer away from these projects or can I\n> consider them?\n\nIf you are interested in converting these scripts, you should probably\nask publicly to the former GSoC students who have been working on\nthese projects if they still plan to continue working on them of if\nthey are ok to let you finish/continue their work. You will get extra\nbonus points if they agree to help you or maybe co-mentor you.\n\n> Secondly, what is too little or too much? On one hand, I do want to do\n> my best and help the Git community as much as I can. On the other\n> hand, I do not want to have too much on my plate and not be able to\n> finish my project. Considering that mentors have already decided that\n> git rebase --interactive and git bisect are enough for two projects,\n> how could I quantify the time required for each command? Looking back\n> at the previous editions of GSoC I noticed that most projects were\n> focused on only one command.\n\nYeah, I don't think it is a good idea to focus on more than one\ncommand per project. It could be possible if there were really small\nscripts to convert, but I think those have been already converted. It\ncould perhaps be possible if 2 scripts were very similar, but I don't\nthink there are similar enough scripts to convert.\n\nYou can however submit more than one proposal, so you could for\nexample submit one proposal to convert one script and another one to\nconvert another script.\n\n> From my research, these are the scripts that could be subject of this\n> project. Which ones do you think could be the best choice for a\n> project of this kind?\n\nI think it is definitely a good idea to work on a script that has\nstarted to be converted. Make sure that no one is still actively\nworking on converting it though.\n\nI think the scripts related to other versions control systems are not\na good choice as they are not really part of the core of Git.\n\nIt is also a good idea to choose scripts that potential mentors are\nfamiliar with.\n\n>  * git/git-add--interactive.perl\n>  * git/git-archimport.perl\n>  * git/git-bisect.sh -- there is a project about this\n>  * git/git-cvsexportcommit.perl\n>  * git/git-cvsimport.perl\n>  * git/git-cvsserver.perl\n>  * git/git-difftool--helper.sh\n>  * git/git-filter-branch.sh\n>  * git/git-instaweb.sh\n>  * git/git-merge-octopus.sh\n>  * git/git-merge-one-file.sh\n>  * git/git-merge-resolve.sh\n>  * git/git-mergetool--lib.sh\n>  * git/git-mergetool.sh\n>  * git/git-quiltimport.sh\n>  * git/git-rebase--am.sh\n>  * git/git-rebase--interactive.sh -- there is a project about this\n>  * git/git-rebase--merge.sh\n>  * git/git-rebase.sh\n>  * git/git-remote-testgit.sh\n>  * git/git-request-pull.sh\n>  * git/git-send-email.perl\n>  * git/git-stash.sh\n>  * git/git-submodule.sh -- there was a project about this\n>  * git/git-svn.perl\n>  * git/git-web--browse.sh\n\nIt would be interesting to know the number of lines of code for each\nof these script, as it could give an idea about how big the task of\nfully converting the script could be.\n\n> I look forward to hearing from you. I will also submit a draft of my\n> proposal soon enough.\n\nGreat!\n\nChristian.\n"},{"id":"342268","messageId":"CAP8UFD2j71GJsnrd8y=Wj3a+TrX6UQePOZXE1LFFiqjd3_a-0w@mail.gmail.com","threadId":"48077","inReplyTo":"CAP8UFD0aQxSZVRfOHUP80H+677zoNWPU1pdg7v4Qk+gKXCG8eg@mail.gmail.com","subject":"Re: [GSoC] Regarding \"Convert scripts to builtins\"","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2018-03-19T23:41:13Z","receivedAt":"2018-03-19T23:41:19Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Mar 20, 2018 at 12:11 AM, Christian Couder\n<christian.couder@gmail.com> wrote:\n> On Sun, Mar 18, 2018 at 11:15 PM, Paul Sebastian Ungureanu\n>> First of all, I find it difficult to pick which scripts would benefit\n>> the most by being rewritten. I am thinking of git bisect, git stash\n>> and git rebase since these are maybe some of the most popular commands\n>> of Git. However, on the other side, scripts like\n>> git-rebase--interactive.sh and git-bisect.sh are also subject of other\n>> GSoC projects. Should I steer away from these projects or can I\n>> consider them?\n>\n> If you are interested in converting these scripts, you should probably\n> ask publicly to the former GSoC students who have been working on\n> these projects if they still plan to continue working on them of if\n> they are ok to let you finish/continue their work. You will get extra\n> bonus points if they agree to help you or maybe co-mentor you.\n\nI realize that you were perhaps talking about other potential GSoC\nstudents who are also writing proposals about converting one of these\nscripts. If you care about the other proposals though, you should\nprobably just write two proposals as we will have at most 2 GSoC\nstudents this year. Just try to have different possible mentors\ninterested in your 2 proposals.\n"},{"id":"342405","messageId":"nycvar.QRO.7.76.6.1803211242190.77@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"48077","inReplyTo":"CADzBBBb0KDVJiX2WSNW=vC6b6paWoK=5XrnZNAY+pwpcu-t9JA@mail.gmail.com","subject":"Re: [GSoC] Regarding \"Convert scripts to builtins\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-03-21T12:32:30Z","receivedAt":"2018-03-21T12:32:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Paul,\n\nOn Mon, 19 Mar 2018, Paul Sebastian Ungureanu wrote:\n\n> I am interested in the \"Convert scripts to builtins\" project. I have\n> recently started to analyze it better and see exactly what it entails\n> and a few questions came to my mind.\n\nGreat!\n\n> First of all, I find it difficult to pick which scripts would benefit\n> the most by being rewritten.\n\nWhich ones do you use, personally? I'd go by that measure if I were you.\n\nOh, and if you are not really familiar with Perl, you may want to stay\naway from those scripts. Perl was jokingly labeled a \"write-only\"\nprogramming language in my presence, and when I see some of my own Perl\ncode, I would agree at least partially.\n\n> I am thinking of git bisect, git stash and git rebase since these are\n> maybe some of the most popular commands of Git. However, on the other\n> side, scripts like git-rebase--interactive.sh and git-bisect.sh are also\n> subject of other GSoC projects. Should I steer away from these projects\n> or can I consider them?\n\nI second Christian's suggestion: just apply for a couple projects you\nwould like to work on. If there really should be a conflict with another\nstrong proposal, we can always work something out.\n\n> Secondly, what is too little or too much?\n\nJudging by past GSoC's, even a moderately-sized script like git-bisect.sh\nis too much in one go. Break it down into smaller pieces, start by adding\na --helper builtin (or continue by using one like git-bisect--helper), add\nthings incrementally.\n\nIf you get the proposed part done faster, I am sure you'll find tons of\nother things to do ;-)\n\nNow to your list of scripts. I reordered them so that I could group the\nlist into logical chunks, and then ordered them by what would be my\npersonal priority (most important scripts first).\n\n>  * git/git-rebase--am.sh\n>  * git/git-rebase--merge.sh\n\nThese are pretty interesting, and also pretty small. They would be *prime*\ncandidates for turning into builtins, methinks.\n\nAs we already have a builtin rebase--helper, that would be a natural way\nto go: if you can analyze those scripts and figure out a natural\nprogression of incremental steps to convert them (see e.g.\nhttps://github.com/git/git/compare/4e7524e012f...c44a4c650c which is how I\nmoved some parts of git-rebase--interactive.sh into the rebase--helper:\nstarting with the code generating the todo list, continuing with\ntransform_todo_ids, then check_commit_sha, skip_unnecessary_picks and\nfinally rearrange_squash), a very smooth timeline should fall right out of\nthat analysis.\n\nOne slight complication might be the fact that rebase--helper is really\nonly catering to rebase -i so far. So `rebase--helper --continue` assumes\nthat it should continue an interactive rebase. This assumption would\nhave to be shunned, by adding a function that determines which type of\nrebase (if any) is currently in progress, and using that to figure out\nwhat function to call to handle the --continue.\n\n>  * git/git-rebase.sh\n\nThis script is a bit larger than rebase--am and rebase--merge combined,\nbut the biggest reason *not* to start with it is: git-rebase.sh is just an\norchestrator of the git-rebase--* scripts, doing little more than\ncommand-line parsing and then handing off to the respective \"backends\".\n\nConsequently, I would consider it to make most sense to convert the\nrebase--* scripts *first*, and only when that is done, convert git-rebase\n(renaming rebase--helper to rebase).\n\nNote! There is one exception, and it is not even a full script. As\neverybody knows who follows my patch series on this here mailing list, I\nconsider --preserve-merges one of my stupidest design mistakes ever. To\nundo this (or at least to alleviate the damage I caused), I already\nsubmitted a patch series to introduce a superseding option:\n--recreate-merges. This patch series is on hold due to the -rc phase of\nv2.17 and will be kicked back into action after v2.17.0 final is out. As\nit is my hope that --preserve-merges can be deprecated in favor of\n--recreate-merges (and eventually even phased out of Git), I would be\ntotally cool with git-rebase--preserve-merges.sh being factored out of\ngit-rebase--interactive.sh before converting the latter to pure C, and\nleaving the --preserve-merges script alone until the time when it is put\nto rest.\n\n(While I was sleeping, leaving this mail unfinished, to be completed and\nsent today, a patch series was sent to the mailing list that seems to\nperform this refactoring of --preserve-merges into its own script.)\n\n>  * git/git-add--interactive.perl\n\nI personally would *love* to see this converted. But it is a huge task,\nlikely too big for a single GSoC project. But if you look at the code and\nfigure out a natural way to break this project down into smaller,\nincremental conversions, that would be a way to go.\n\n>  * git/git-bisect.sh -- there is a project about this\n>  * git/git-rebase--interactive.sh -- there is a project about this\n>  * git/git-submodule.sh -- there was a project about this\n\nIndeed, there are projects about this, although the rebase -i effort is\npushed forward by non-GSoC developers, while the bisect/submodule effort\nis/was mainly backed by GSoC students.\n\nAs Christian suggested: either propose something else, or talk to the\npeople who touched these projects last, to coordinate.\n\n>  * git/git-stash.sh\n\nThere have been two efforts about this:\n\nhttps://github.com/git-for-windows/git/pull/508\n\nand\n\nhttps://public-inbox.org/git/20171110231314.30711-1-joel@teichroeb.net/\n\nBoth have died down, and I feel really bad about that because I wanted to\nmake time to help, and failed.\n\nNevertheless, they provide a huge head start into converting stash into a\nbuiltin.\n\nHaving said that, I feel that there are still current developments going\non that would possibly interfere with the project to convert stash to C.\n\n>  * git/git-merge-octopus.sh\n>  * git/git-merge-resolve.sh\n\nThese merge strategies seem to be used not all that much, at least I never\nheard about speed issues on Windows ;-)\n\nTherefore it is my impression that the effort to convert scripts to\nportable C is probably better spent elsewhere.\n\nOn the other hand, they are really small, and should be really quick to\nconvert.\n\n>  * git/git-merge-one-file.sh\n\nHaving this as a builtin would not really matter right now, because there\nis a design problem in the only two callers: both `git merge-octopus` and\n`git merge-resolve` call `git-merge-one-file` in the *dashed* form, i.e.\nnot as a subcommand of `git`.\n\nThe reason is that the `git merge-index` command expects a *merge program*\nas command-line argument, not a Git builtin.\n\nOn the other hand, this script could be converted into pure C (say, as\nmerge-one-file.c in libgit.a), then used in merge-index *directly* (i.e.\nwithout spawning anything) when the command-line argument is\n`git-merge-one-file`. And then that function could be also used in a new\nbuiltin merge-one-file. A nice three-commit progression.\n\nWhile t7605-merge-resolve.sh is not super-extensive, I would wager a bet\nthat it is extensive enough to help this project.\n\n>  * git/git-filter-branch.sh\n\nThe `filter-branch` script is not used all that often, as far as I can\ntell. If there is ever interest in a faster/more robust version of that\ncommand (by converting it to C), I highly recommend looking at the\nrewrite-commits patch series posted a long time ago:\n\nhttps://public-inbox.org/git/11842671631744-git-send-email-skimo@liacs.nl/\n\nIt should be relatively straight-forward to rebase that patch series, and\nthen to modify it to be command-line compatible to filter-branch.\n\n>  * git/git-difftool--helper.sh\n>  * git/git-mergetool--lib.sh\n>  * git/git-mergetool.sh\n\nIIRC from my difftool work, the difftool--helper is used also from\nmergetool, so logically these belong together.\n\nFrom my experience on the Git mailing list, I would expect a lot of\npushback here because it is really easy to add/modify the mergetool script\nin order to add new helpers, and that would be a lot less easy in a\nbuiltin.\n\nWe would have to design a flexible-enough config way to add/modify\nmergetool backends to increase the chances that this conversion would be\naccepted.\n\n>  * git/git-web--browse.sh\n\nLikewise, this one benefits from being easily modified. It *is* annoying,\nof course, to wait for a second or two to have a web page opened, in\nparticular on Windows, where the help format is HTML.\n\nBut probably not worth picking a battle over.\n\n>  * git/git-instaweb.sh\n\nThis script tries to set up a GitWeb server as quickly and as painlessly\nas possible, on a developer's machine. It does have quite a hefty\nrequirement in that a web server software (such as Apache) needs to be\ninstalled. It does support a couple other web server software, none of\nwhich is typically installed e.g. on a Windows machine.\n\nPlus, this script is even less useful right now because it does not even\noffer cloning/pushing via http-backend.\n\nIn my mind, this script is not worth converting. If I were maintaining\nGit, I would probably deprecate it and remove it in two or four major\nversions.\n\n>  * git/git-archimport.perl\n>  * git/git-cvsexportcommit.perl\n>  * git/git-cvsimport.perl\n>  * git/git-cvsserver.perl\n>  * git/git-quiltimport.sh\n>  * git/git-svn.perl\n\nThese are integrations with other SCM software that may not be all that\nprevalent anymore. In particular, the CVS business seems to have died\ndown. I have not heard of any Arch user using archimport, either.\n\nSubversion is still strong, though, but converting git-svn would be a\nproject that even I would shy away from: it is just too big.\n\nOh, and I notice you forgot git-p4.py ;-)\n\n>  * git/git-request-pull.sh\n>  * git/git-send-email.perl\n\nIf I understand correctly, and I am rather certain that I do, these Git\ncommands are included in Git mainly for the benefit of the Linux project.\n\nThe `git send-email` script turned out to be useful *also* when working on\nthe Git, the Cygwin and the BusyBox mailing lists.\n\nI am not sure that they serve any greater purpose, so in my opinion they\ncan stay scripts forever. The `send-email` script in particular would be\nquite involved to convert due to the many, many idiosyncracies with all of\nthe possible options you have via (E)SMTP.\n\n>  * git/git-remote-testgit.sh\n\nThis one is completely pointless to convert, as it is only intended to be\nused in Git's own test suite.\n\n> I look forward to hearing from you. I will also submit a draft of my\n> proposal soon enough.\n\nSoon enough ;-)\n\nI look forward to it!\n\nCiao,\nJohannes\n"},{"id":"342443","messageId":"CAKk8isrOMMm0zyJ1JtH3aDm=tF5hwokZ0Wzn=D1BQ1R-qEPicw@mail.gmail.com","threadId":"48077","inReplyTo":"nycvar.QRO.7.76.6.1803211242190.77@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","subject":"Re: [GSoC] Regarding \"Convert scripts to builtins\"","fromName":"Wink Saville","fromEmail":"wink@saville.com","sentAt":"2018-03-21T19:17:49Z","receivedAt":"2018-03-21T19:18:16Z","isPatch":false,"sender":{"key":"wink@saville.com","avatar":"https://avatars.githubusercontent.com/u/1024284?v=4"},"body":"On Wed, Mar 21, 2018 at 5:32 AM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi Paul,\n>\n\n> Note! There is one exception, and it is not even a full script. As\n> everybody knows who follows my patch series on this here mailing list, I\n> consider --preserve-merges one of my stupidest design mistakes ever. To\n> undo this (or at least to alleviate the damage I caused), I already\n> submitted a patch series to introduce a superseding option:\n> --recreate-merges. This patch series is on hold due to the -rc phase of\n> v2.17 and will be kicked back into action after v2.17.0 final is out. As\n> it is my hope that --preserve-merges can be deprecated in favor of\n> --recreate-merges (and eventually even phased out of Git), I would be\n> totally cool with git-rebase--preserve-merges.sh being factored out of\n> git-rebase--interactive.sh before converting the latter to pure C, and\n> leaving the --preserve-merges script alone until the time when it is put\n> to rest.\n>\n> (While I was sleeping, leaving this mail unfinished, to be completed and\n> sent today, a patch series was sent to the mailing list that seems to\n> perform this refactoring of --preserve-merges into its own script.)\n\nI plead guilty to being the preson refactoring --preserve-merges. But after\nreading this and seeing that --recreate-merges is coming and possibly\ngit-rebase--* moving to C I'm worried I'd be messing things up.\n\nAlso, Eric Sunshine felt my v1 changes causes the blame information to\nbe obscured. So I created a v2 change which keeps everything in the\ngit-rebase--interactive.sh.\n\nPlease see \"[RFC PATCH 0/3] rebase-interactive\" and\n\"[RFC PATCH v2 0/1] rebase-interactive: ...\". I'm looking for\nadvice on how to proceed.\n"},{"id":"342525","messageId":"nycvar.QRO.7.76.6.1803221831120.77@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"48077","inReplyTo":"CAKk8isrOMMm0zyJ1JtH3aDm=tF5hwokZ0Wzn=D1BQ1R-qEPicw@mail.gmail.com","subject":"Re: [GSoC] Regarding \"Convert scripts to builtins\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-03-22T17:32:11Z","receivedAt":"2018-03-22T17:32:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Wink,\n\nOn Wed, 21 Mar 2018, Wink Saville wrote:\n\n> I plead guilty to being the preson refactoring --preserve-merges. But\n> after reading this and seeing that --recreate-merges is coming and\n> possibly git-rebase--* moving to C I'm worried I'd be messing things up.\n\nDon't worry. We will just work together to avoid messing anything up.\n\n> Also, Eric Sunshine felt my v1 changes causes the blame information to\n> be obscured. So I created a v2 change which keeps everything in the\n> git-rebase--interactive.sh.\n\nGreat!\n\n> Please see \"[RFC PATCH 0/3] rebase-interactive\" and\n> \"[RFC PATCH v2 0/1] rebase-interactive: ...\". I'm looking for\n> advice on how to proceed.\n\nSadly, I had almost no time to spend on the Git mailing list today, but I\nwill have a look tomorrow, okay?\n\nCiao,\nJohannes\n"},{"id":"342531","messageId":"CAKk8isqH4uRdf4dXKpxMkNoJqpabztWNPgELqtLbSupR+_C=SA@mail.gmail.com","threadId":"48077","inReplyTo":"nycvar.QRO.7.76.6.1803221831120.77@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","subject":"Re: [GSoC] Regarding \"Convert scripts to builtins\"","fromName":"Wink Saville","fromEmail":"wink@saville.com","sentAt":"2018-03-22T17:50:43Z","receivedAt":"2018-03-22T17:51:20Z","isPatch":false,"sender":{"key":"wink@saville.com","avatar":"https://avatars.githubusercontent.com/u/1024284?v=4"},"body":"On Thu, Mar 22, 2018, 10:32 AM Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n>\n> Hi Wink,\n\n\n>\n> > Please see \"[RFC PATCH 0/3] rebase-interactive\" and\n> > \"[RFC PATCH v2 0/1] rebase-interactive: ...\". I'm looking for\n> > advice on how to proceed.\n>\n> Sadly, I had almost no time to spend on the Git mailing list today, but I\n> will have a look tomorrow, okay?\n\n\nNP, I totally understand and, of course, I now have a\nversion 3: \"[RFC PATCH v3 0/9] rebase-interactive:\"\n\nCheers,\nWinthrop Lyon Saville III (I had to repsond with my full name although I\nalways use my nick name, Wink, just because Johannes seems so formal :)\n"},{"id":"342574","messageId":"nycvar.QRO.7.76.6.1803231048110.77@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz","threadId":"48077","inReplyTo":"CAKk8isqH4uRdf4dXKpxMkNoJqpabztWNPgELqtLbSupR+_C=SA@mail.gmail.com","subject":"Re: [GSoC] Regarding \"Convert scripts to builtins\"","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2018-03-23T09:48:53Z","receivedAt":"2018-03-23T09:49:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Wink,\n\nOn Thu, 22 Mar 2018, Wink Saville wrote:\n\n> On Thu, Mar 22, 2018, 10:32 AM Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> \n> I now have a version 3: \"[RFC PATCH v3 0/9] rebase-interactive:\"\n\nGreat!\n\n> Cheers,\n> Winthrop Lyon Saville III (I had to repsond with my full name although I\n> always use my nick name, Wink, just because Johannes seems so formal :)\n\nYes, I am formal. All Germans are. It's a matter of form.\n\nCiao,\nJohannes\n"}]}