{"thread":{"id":"50392","subject":"GSoC 2019: Git's application submitted","startedAt":"2019-02-04T09:17:01Z","lastAt":"2019-03-18T16:37:45Z","messageCount":29,"participants":["Christian Couder","Thomas Gummerer","Johannes Schindelin","Оля Тележная","Elijah Newren","Duy Nguyen","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"368446","messageId":"CAP8UFD2kt=Rv4pC67q0s+CKjgmBON_KkK09igfwe-0709Di2RQ@mail.gmail.com","threadId":"50392","inReplyTo":null,"subject":"GSoC 2019: Git's application submitted","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-02-04T09:16:41Z","receivedAt":"2019-02-04T09:17:01Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"Hi everyone,\n\nThere are now ideas, micro-projects and organization application pages\nfor GSoC 2019 on https://git.github.io/\n\nIt would be nice to have a few more project ideas.\nhttps://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible\nprojects:\n\n- Unify ref-filter formats with other --pretty formats (which is new)\n- git log --oneline improvements\n\nas I didn't feel that the others were still relevant, though I might be wrong.\n\nAs Olga and Thomas told me at the Git Merge that they could be ok to\nco-mentor with me, they are listed as possible mentors for both of\nthese projects.\n\nAnyway feel free to comment and suggest improvements on those pages,\nespecially the micro-projects and ideas one. Pull requests on\nhttps://github.com/git/git.github.io/ are very much appreciated.\n\nThe application has been submitted on\nhttps://summerofcode.withgoogle.com, but it will not be complete until\nsomeone else volunteers as an org admin. I volunteered, but they\nrequire \"at least 2 and at most 5 Organization Administrators\".\n\nSo another org admin is needed before Wednesday February 6th, as this\nis the deadline. Invitations have been sent to Peff, Thomas, Olga and\nMatthieu, but anyone can do it and it requires a very low amount of\nwork.\n\nThanks,\nChristian.\n"},{"id":"368457","messageId":"CAP8UFD3QCaSu8z4MdGks7E7zMrFpvcuWdFz_Zyr4yKhV+=XV7A@mail.gmail.com","threadId":"50392","inReplyTo":"CAL21Bm=K6zZ=APkiP3A_X7xVoOfx-MY2435YMp5y1ztE-xyYtg@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-02-04T12:54:38Z","receivedAt":"2019-02-04T12:54:53Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Feb 4, 2019 at 11:28 AM Оля Тележная <olyatelezhnaya@gmail.com> wrote:\n>\n> пн, 4 февр. 2019 г., 10:16 Christian Couder christian.couder@gmail.com:\n>>\n>> The application has been submitted on\n>> https://summerofcode.withgoogle.com, but it will not be complete until\n>> someone else volunteers as an org admin. I volunteered, but they\n>> require \"at least 2 and at most 5 Organization Administrators\".\n>\n> Thank you,\n> I filled the form in.\n\nThank you Olga!\n\nThe application is complete now, though of course we can still add org\nadmins and improve our \"ideas\" and \"microprojects\" pages.\n"},{"id":"368494","messageId":"20190204215251.GB6085@hank.intra.tgummerer.com","threadId":"50392","inReplyTo":"CAP8UFD2kt=Rv4pC67q0s+CKjgmBON_KkK09igfwe-0709Di2RQ@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2019-02-04T21:52:51Z","receivedAt":"2019-02-04T21:52:57Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 02/04, Christian Couder wrote:\n> Hi everyone,\n> \n> There are now ideas, micro-projects and organization application pages\n> for GSoC 2019 on https://git.github.io/\n> \n> It would be nice to have a few more project ideas.\n> https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible\n> projects:\n\nThanks for putting this together.  I'm going to have a look at the\nproject list over the next couple of days.\n\n> - Unify ref-filter formats with other --pretty formats (which is new)\n> - git log --oneline improvements\n> \n> as I didn't feel that the others were still relevant, though I might be wrong.\n> \n> As Olga and Thomas told me at the Git Merge that they could be ok to\n> co-mentor with me, they are listed as possible mentors for both of\n> these projects.\n\nYes, I am indeed happy to co-mentor a student with you, or someone\nelse experienced in mentoring.\n\n> Anyway feel free to comment and suggest improvements on those pages,\n> especially the micro-projects and ideas one. Pull requests on\n> https://github.com/git/git.github.io/ are very much appreciated.\n> \n> The application has been submitted on\n> https://summerofcode.withgoogle.com, but it will not be complete until\n> someone else volunteers as an org admin. I volunteered, but they\n> require \"at least 2 and at most 5 Organization Administrators\".\n> \n> So another org admin is needed before Wednesday February 6th, as this\n> is the deadline. Invitations have been sent to Peff, Thomas, Olga and\n> Matthieu, but anyone can do it and it requires a very low amount of\n> work.\n> \n> Thanks,\n> Christian.\n"},{"id":"368547","messageId":"20190205211736.GD6085@hank.intra.tgummerer.com","threadId":"50392","inReplyTo":"20190204215251.GB6085@hank.intra.tgummerer.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2019-02-05T21:17:36Z","receivedAt":"2019-02-05T21:17:41Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"[Dropped Stefan from the Cc list, as his email bounces]\n\nOn 02/04, Thomas Gummerer wrote:\n> On 02/04, Christian Couder wrote:\n> > It would be nice to have a few more project ideas.\n> > https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible\n> > projects:\n> \n> Thanks for putting this together.  I'm going to have a look at the\n> project list over the next couple of days.\n\nHere's an idea, that I think could make a good GSoC project.  Dscho\nmentioned this to me at Git Merge, and I liked the idea, but I'd like\nto get some feedback on the list first before adding it to the project\nlist, to get others opinions on the feasibility.\n\nThe idea is to add an option to 'git stash push', so it can stash\nmerge conflicts, and restore them with 'git stash pop'.  The various\nstages of the files could be represented as commits, and the stash\ncommit would be an octopus merge of those commits, so they could be\nre-created later.  The same idea can also be extended to store staged\nvs. unstaged changes, so we can re-create the index state as it was\nbefore creating the stash.\n\nThoughts?\n"},{"id":"368548","messageId":"CAP8UFD0bFWvXyQYb=EQ7QCPD_Va7CXEueEEtrETuEVO3n2X35g@mail.gmail.com","threadId":"50392","inReplyTo":"20190205211736.GD6085@hank.intra.tgummerer.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-02-05T22:00:27Z","receivedAt":"2019-02-05T22:00:45Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Feb 5, 2019 at 10:17 PM Thomas Gummerer <t.gummerer@gmail.com> wrote:\n>\n> [Dropped Stefan from the Cc list, as his email bounces]\n>\n> On 02/04, Thomas Gummerer wrote:\n\n> The idea is to add an option to 'git stash push', so it can stash\n> merge conflicts, and restore them with 'git stash pop'.  The various\n> stages of the files could be represented as commits, and the stash\n> commit would be an octopus merge of those commits, so they could be\n> re-created later.  The same idea can also be extended to store staged\n> vs. unstaged changes, so we can re-create the index state as it was\n> before creating the stash.\n>\n> Thoughts?\n\nI think it would be an interesting GSoC project indeed. I think though\nthat over the years we have been favoring refactoring projects over\npossibly more interesting projects, as the refactoring projects are\nusually easier to do step by step and to get code merged step by step\nwhich is encouraging.\n\nIn general the refactoring projects are worthwhile to do even if the\nproject is not finished at the end of the GSoC and if the student\nstops contributing after that. In those cases it is often a good idea\nto later finish the refactoring either by ourselves or by proposing it\nto another GSoC student or Outreachy intern.\n\nWith a project that implements a feature, there is a risk, if it's too\ncomplex or too difficult, that the feature will not be finished and\nthat nothing (or nearly nothing) will have been merged during the\nGSoC. There is also the risk that another way to implement the feature\nwill appear later in the GSoC and all, or nearly all, the work of the\nstudent and mentors will have been mostly wasted. It could also appear\nthat the use cases the feature was envisioned to be used in, are\nbetter addressed by other improvements or a different workflow.\n\nAnother potential issue is that a new feature might be prone to naming\nor user interface discussions which could last for a long time or\ncould not result in clear decisions.\n\nSo I think we should be very careful if we propose a project that\nimplements a new feature to a student. We should at least consider the\nabove potential issues and see if they can be mitigated before the\nproject starts.\n\nThank you anyway for proposing this idea,\nChristian.\n"},{"id":"368586","messageId":"nycvar.QRO.7.76.6.1902061325530.41@tvgsbejvaqbjf.bet","threadId":"50392","inReplyTo":"20190205211736.GD6085@hank.intra.tgummerer.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-02-06T12:27:12Z","receivedAt":"2019-02-06T12:27:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Thomas,\n\nOn Tue, 5 Feb 2019, Thomas Gummerer wrote:\n\n> Here's an idea, that I think could make a good GSoC project.  Dscho\n> mentioned this to me at Git Merge, and I liked the idea, but I'd like to\n> get some feedback on the list first before adding it to the project\n> list, to get others opinions on the feasibility.\n> \n> The idea is to add an option to 'git stash push', so it can stash merge\n> conflicts, and restore them with 'git stash pop'.  The various stages of\n> the files could be represented as commits, and the stash commit would be\n> an octopus merge of those commits, so they could be re-created later.\n> The same idea can also be extended to store staged vs. unstaged changes,\n> so we can re-create the index state as it was before creating the stash.\n> \n> Thoughts?\n\nYep, would make for a good GSoC project, as it is straight-forward to\nimplement and easy to structure, there is no exploratory work needed.\n\nCiao,\nDscho\n"},{"id":"368646","messageId":"20190206220942.GE6085@hank.intra.tgummerer.com","threadId":"50392","inReplyTo":"CAP8UFD0bFWvXyQYb=EQ7QCPD_Va7CXEueEEtrETuEVO3n2X35g@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2019-02-06T22:09:42Z","receivedAt":"2019-02-06T22:09:48Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 02/05, Christian Couder wrote:\n> On Tue, Feb 5, 2019 at 10:17 PM Thomas Gummerer <t.gummerer@gmail.com> wrote:\n> >\n> > [Dropped Stefan from the Cc list, as his email bounces]\n> >\n> > On 02/04, Thomas Gummerer wrote:\n> \n> > The idea is to add an option to 'git stash push', so it can stash\n> > merge conflicts, and restore them with 'git stash pop'.  The various\n> > stages of the files could be represented as commits, and the stash\n> > commit would be an octopus merge of those commits, so they could be\n> > re-created later.  The same idea can also be extended to store staged\n> > vs. unstaged changes, so we can re-create the index state as it was\n> > before creating the stash.\n> >\n> > Thoughts?\n> \n> I think it would be an interesting GSoC project indeed. I think though\n> that over the years we have been favoring refactoring projects over\n> possibly more interesting projects, as the refactoring projects are\n> usually easier to do step by step and to get code merged step by step\n> which is encouraging.\n>\n> In general the refactoring projects are worthwhile to do even if the\n> project is not finished at the end of the GSoC and if the student\n> stops contributing after that. In those cases it is often a good idea\n> to later finish the refactoring either by ourselves or by proposing it\n> to another GSoC student or Outreachy intern.\n> \n> With a project that implements a feature, there is a risk, if it's too\n> complex or too difficult, that the feature will not be finished and\n> that nothing (or nearly nothing) will have been merged during the\n> GSoC. There is also the risk that another way to implement the feature\n> will appear later in the GSoC and all, or nearly all, the work of the\n> student and mentors will have been mostly wasted. It could also appear\n> that the use cases the feature was envisioned to be used in, are\n> better addressed by other improvements or a different workflow.\n\nRight, it being too complex or too difficult is my main worry here.  I\ndon't necessarily agree that we should draw a line between refactoring\nand feature work here.  The more important distinction in my opinion\nis whether it is possible to implement the project in steps, that\nindividually make sense, and further work could be based on.\n\nFor example in Paul-Sebastians stash-in-c series (just to take a\nrecent example, that I was following closely), we didn't get anything\nmerged until stash was fully converted into C.  We could possibly have\nmerged half of the work, but maybe we would have waited until someone\nelse picks it up before merging anything, I don't know how to judge\nthat now.\n\nI think the idea here could definitely be split into a couple different\nphases, that could be individually useful, and can be merged\nindividually, though I don't know if they would necessarily be.  Of\nthe top of my head:\n\n - write test_expect_failure tests for the expected new behaviour\n\n   This may not be worth including in git.git yet, but it can be a\n   very useful starting point for somebody else continuing the feature\n   if the student finds they don't have time for it.\n\n - implement pushing the index state, without dealing with conflicts\n - implement poping the index state, without dealing with conflicts\n\n   This can already be individually useful, and I think this is\n   something people asked for on the mailing list, though I didn't try\n   digging up old threads for now.  After these two steps stashing and\n   restoring a merge conflict would still not work, but we have a good\n   first step that could be merged.\n\n - implement pushing/poping conflicted state\n\n   This would obviously be the end goal.\n\n> Another potential issue is that a new feature might be prone to naming\n> or user interface discussions which could last for a long time or\n> could not result in clear decisions.\n\nYes, this is definitely a potential pitfall.  I haven't thought in\ndepth about the interface yet, but I think the discussion around that\nwould be something we as mentors could and should guide the student\nthrough.  We also wouldn't make the feature the default from the\nbeginning, but introduce it behind a new flag/maybe a config option,\nto make sure we don't introduce any backwards compatible changes.\n\nIt's probably also something the student should include in their\nproposal, so we can get eyes on it early in the process.\n\n> So I think we should be very careful if we propose a project that\n> implements a new feature to a student. We should at least consider the\n> above potential issues and see if they can be mitigated before the\n> project starts.\n\nThanks for bringing these issues up, they are definitely useful to\nwork through.  \n\n> Thank you anyway for proposing this idea,\n> Christian.\n"},{"id":"368724","messageId":"nycvar.QRO.7.76.6.1902072023250.41@tvgsbejvaqbjf.bet","threadId":"50392","inReplyTo":"20190206220942.GE6085@hank.intra.tgummerer.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-02-07T19:39:08Z","receivedAt":"2019-02-07T19:39:20Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Thomas,\n\nOn Wed, 6 Feb 2019, Thomas Gummerer wrote:\n\n> I think the idea here could definitely be split into a couple different\n> phases, that could be individually useful, and can be merged\n> individually, though I don't know if they would necessarily be.\n\nGood idea.\n\n> Of the top of my head:\n> \n>  - write test_expect_failure tests for the expected new behaviour\n> \n>    This may not be worth including in git.git yet, but it can be a\n>    very useful starting point for somebody else continuing the feature\n>    if the student finds they don't have time for it.\n\nI like this approach.\n\n>  - implement pushing the index state, without dealing with conflicts\n>  - implement poping the index state, without dealing with conflicts\n> \n>    This can already be individually useful, and I think this is\n>    something people asked for on the mailing list, though I didn't try\n>    digging up old threads for now.  After these two steps stashing and\n>    restoring a merge conflict would still not work, but we have a good\n>    first step that could be merged.\n\nWe already have `git stash --keep-index`. Is this what you mean here?\n\n>  - implement pushing/poping conflicted state\n> \n>    This would obviously be the end goal.\n\nOn second thought, this might actually be super trivial. Right now, we\nsupport two modes (not counting the `--untracked` stuff): --keep-index and\n--no-keep-index. In both cases, we seem to create a merge commit whose\ntree reflects the working directory and whose first parent is HEAD and\nwhose second parent is a single commit on top of HEAD (which contains\neither no changes in the case of --no-keep-index, or whose tree reflects\nthe index in case of --keep-index).\n\nTo extend that to the conflict case, we could introduce a new flag\n--with-conflicts, and have the commit structure\n\n\tWorktree\n\t |    \\\n\t |    index stage 0\n\t |      /     |     \\\n\t | stage 1  stage 2  stage 3\n\t |    /     /       /\n\tHEAD ---------------\n\nThe only tricky thing I can see is to maintain backwards compatibility if\npossible, so that old `git stash` will do something at least semi-sensible\nwith those commit structures.\n\nIt might be too small a project, after all.\n\nCiao,\nDscho\n\n> > Another potential issue is that a new feature might be prone to naming\n> > or user interface discussions which could last for a long time or\n> > could not result in clear decisions.\n> \n> Yes, this is definitely a potential pitfall.  I haven't thought in\n> depth about the interface yet, but I think the discussion around that\n> would be something we as mentors could and should guide the student\n> through.  We also wouldn't make the feature the default from the\n> beginning, but introduce it behind a new flag/maybe a config option,\n> to make sure we don't introduce any backwards compatible changes.\n> \n> It's probably also something the student should include in their\n> proposal, so we can get eyes on it early in the process.\n> \n> > So I think we should be very careful if we propose a project that\n> > implements a new feature to a student. We should at least consider the\n> > above potential issues and see if they can be mitigated before the\n> > project starts.\n> \n> Thanks for bringing these issues up, they are definitely useful to\n> work through.  \n> \n> > Thank you anyway for proposing this idea,\n> > Christian.\n> \n"},{"id":"368740","messageId":"20190207213326.GF6085@hank.intra.tgummerer.com","threadId":"50392","inReplyTo":"nycvar.QRO.7.76.6.1902072023250.41@tvgsbejvaqbjf.bet","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2019-02-07T21:33:26Z","receivedAt":"2019-02-07T21:33:30Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 02/07, Johannes Schindelin wrote:\n> Hi Thomas,\n> \n> On Wed, 6 Feb 2019, Thomas Gummerer wrote:\n> >  - implement pushing the index state, without dealing with conflicts\n> >  - implement poping the index state, without dealing with conflicts\n> > \n> >    This can already be individually useful, and I think this is\n> >    something people asked for on the mailing list, though I didn't try\n> >    digging up old threads for now.  After these two steps stashing and\n> >    restoring a merge conflict would still not work, but we have a good\n> >    first step that could be merged.\n> \n> We already have `git stash --keep-index`. Is this what you mean here?\n\n`git stash --keep-index` does something different, what I meant here\nwas what `git stash pop --index` already does.   I had forgotten that\nthis functionality already exists.\n\n> >  - implement pushing/poping conflicted state\n> > \n> >    This would obviously be the end goal.\n> \n> On second thought, this might actually be super trivial. Right now, we\n> support two modes (not counting the `--untracked` stuff): --keep-index and\n> --no-keep-index. In both cases, we seem to create a merge commit whose\n> tree reflects the working directory and whose first parent is HEAD and\n> whose second parent is a single commit on top of HEAD (which contains\n> either no changes in the case of --no-keep-index, or whose tree reflects\n> the index in case of --keep-index).\n> \n> To extend that to the conflict case, we could introduce a new flag\n> --with-conflicts, and have the commit structure\n> \n> \tWorktree\n> \t |    \\\n> \t |    index stage 0\n> \t |      /     |     \\\n> \t | stage 1  stage 2  stage 3\n> \t |    /     /       /\n> \tHEAD ---------------\n> \n> The only tricky thing I can see is to maintain backwards compatibility if\n> possible, so that old `git stash` will do something at least semi-sensible\n> with those commit structures.\n> \n> It might be too small a project, after all.\n\nYeah, looking at this I think you're right.  Thanks for helping work\nthrough this.\n\n> Ciao,\n> Dscho\n"},{"id":"368998","messageId":"CAL21Bmkkpzp7fhAnjstTjeH+unDFk8-uhFAgKFfuczYzejf2RA@mail.gmail.com","threadId":"50392","inReplyTo":"20190207213326.GF6085@hank.intra.tgummerer.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Оля Тележная","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2019-02-11T05:41:18Z","receivedAt":"2019-02-11T05:49:01Z","isPatch":false,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"> It would be nice to have a few more project ideas.\n\nI am not sure I have additional ideas for 3-month project for the intern, but\n\n> https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible\n> projects:\n>\n> - Unify ref-filter formats with other --pretty formats (which is new)\n\nI am ready to act as a mentor in this task, I know that part of\nproject good enough.\nI have additional related task: We have a function called\noid_object_info, it allows to download meta-info of the file. It was\nused in cat-file, and inspired by that example, I improved ref-filter,\nso now ref-filter works faster with it. Moreover, I have found that\noid_object_info allows to get the contents of the file. It was useful\nin ref-filter, and actually it could be also useful in cat-file, but\nwe still download the file differently in cat-file, and it looks\nawkward. I need to make just one last move to finish my patch: it will\nclose the task about migrating cat-file formatting logic to\nref-filter. But cat-file still will not use general way to download\nthe file. So, the task is to get rid of additional file-reading logic.\nI guess this task is much smaller than original one, but at least the\nstudent will have chance to finish it in 3 months.\nMy patch is here: https://github.com/git/git/pull/568\nBut I hope you will also see it this week in the mailing list.\nProposed task is in TODO in the end of ref-filter file.\n\nBy the way, we had a letter from Google, it is said that our tasks are\nsparsed. I am not sure I understand it correctly. Should I help the\nproject somehow to solve our issues?\n"},{"id":"369000","messageId":"CAP8UFD24Jgetmb9_ANm07Emwr90obVpiRPyX+HtmaHcL1fYq5g@mail.gmail.com","threadId":"50392","inReplyTo":"CAL21Bmkkpzp7fhAnjstTjeH+unDFk8-uhFAgKFfuczYzejf2RA@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-02-11T07:45:53Z","receivedAt":"2019-02-11T07:46:09Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Feb 11, 2019 at 6:48 AM Оля Тележная <olyatelezhnaya@gmail.com> wrote:\n>\n> > It would be nice to have a few more project ideas.\n>\n> I am not sure I have additional ideas for 3-month project for the intern, but\n>\n> > https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible\n> > projects:\n> >\n> > - Unify ref-filter formats with other --pretty formats (which is new)\n>\n> I am ready to act as a mentor in this task, I know that part of\n> project good enough.\n\nGreat! I thought that it would be a good project for you to mentor and\nthat's why I added it.\n\nBy the way if you would prefer not to mentor the other project I can\nremove you from its possible mentor list.\n\n> I have additional related task: We have a function called\n> oid_object_info, it allows to download meta-info of the file. It was\n> used in cat-file, and inspired by that example, I improved ref-filter,\n> so now ref-filter works faster with it. Moreover, I have found that\n> oid_object_info allows to get the contents of the file. It was useful\n> in ref-filter, and actually it could be also useful in cat-file, but\n> we still download the file differently in cat-file, and it looks\n> awkward. I need to make just one last move to finish my patch: it will\n> close the task about migrating cat-file formatting logic to\n> ref-filter. But cat-file still will not use general way to download\n> the file. So, the task is to get rid of additional file-reading logic.\n> I guess this task is much smaller than original one, but at least the\n> student will have chance to finish it in 3 months.\n> My patch is here: https://github.com/git/git/pull/568\n> But I hope you will also see it this week in the mailing list.\n> Proposed task is in TODO in the end of ref-filter file.\n\nDo you mean the following comment from\nhttps://github.com/git/git/blob/c17ed82b8983ea7e172181d869966db546c6a528/ref-filter.c#L2393-L2399:\n\n/*\n* TODO: add support of %(*raw). Need to switch between oi and oi_deref for that.\n* TODO: split logic and printing (as it is done in format_ref_array_item and\n* show_ref_array_item). After that we could use %(raw) in all\nref-filter commands.\n* TODO: rewrite print_object_or_die so that it will reuse result of general\n* oid_object_info_extended call.\n*/\n\n?\n\nIt doesn't look like that's it. Could you just copy the task into an\nemail? Or if you think it could be an idea for a GSoC project, could\nyou send a pull request to add it to:\n\nhttps://github.com/git/git.github.io/blob/master/SoC-2019-Ideas.md\n\n?\n\n> By the way, we had a letter from Google, it is said that our tasks are\n> sparsed. I am not sure I understand it correctly. Should I help the\n> project somehow to solve our issues?\n\nYeah, we got en email from Stephanie Taylor saying that our idea list\nis quite sparse this year with a link to:\n\nhttps://google.github.io/gsocguides/mentor/defining-a-project-ideas-list\n\nwhich contains:\n\n\"Even if you are a new organization and only want one or two students\nshowing that you have multiple ideas (a bare minimum of 4 solid ideas)\nis vital.\"\n\nThey also want \"more detailed description of [each] project (2-5\nsentences)\", so I think we should work on that too.\n\nSo yeah, any help to fix the idea list is very welcome!\n\nThanks,\nChristian.\n"},{"id":"369003","messageId":"CAP8UFD1Rv+nFqDYf33rRw-kWnfqokSG6=tG8XPFyBoVCU6Te=w@mail.gmail.com","threadId":"50392","inReplyTo":"20190207213326.GF6085@hank.intra.tgummerer.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-02-11T08:35:27Z","receivedAt":"2019-02-11T08:35:43Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Feb 7, 2019 at 10:33 PM Thomas Gummerer <t.gummerer@gmail.com> wrote:\n>\n> On 02/07, Johannes Schindelin wrote:\n> > On Wed, 6 Feb 2019, Thomas Gummerer wrote:\n> > >  - implement pushing/poping conflicted state\n> > >\n> > >    This would obviously be the end goal.\n> >\n> > On second thought, this might actually be super trivial. Right now, we\n> > support two modes (not counting the `--untracked` stuff): --keep-index and\n> > --no-keep-index. In both cases, we seem to create a merge commit whose\n> > tree reflects the working directory and whose first parent is HEAD and\n> > whose second parent is a single commit on top of HEAD (which contains\n> > either no changes in the case of --no-keep-index, or whose tree reflects\n> > the index in case of --keep-index).\n> >\n> > To extend that to the conflict case, we could introduce a new flag\n> > --with-conflicts, and have the commit structure\n> >\n> >       Worktree\n> >        |    \\\n> >        |    index stage 0\n> >        |      /     |     \\\n> >        | stage 1  stage 2  stage 3\n> >        |    /     /       /\n> >       HEAD ---------------\n> >\n> > The only tricky thing I can see is to maintain backwards compatibility if\n> > possible, so that old `git stash` will do something at least semi-sensible\n> > with those commit structures.\n> >\n> > It might be too small a project, after all.\n>\n> Yeah, looking at this I think you're right.  Thanks for helping work\n> through this.\n\nI am not sure it will be too small a project, especially because it is\na new feature. On top of the coding part, the student will also have\nto come up with good documentation and test cases, and there will\nprobably be naming and workflow discussions and possibly refactoring\nopportunities and bug fixes along the way.\n\nYeah, the naming and workflow discussions should actually happen when\ndiscussing the student's proposal, in which case an important part of\nthe work will (hopefully) be done before the GSoC actually starts.\n\nHistorically though we have always been very optimistic in what we\nthought a student could accomplish in a GSoC. And we are very likely\nto find more ideas for improvements during the GSoC, in case\neverything is \"finished\" before the end. I actually think that it has\nnever happened that a student both \"finished\" the project before the\nend, and that no idea for improvement on top of the work was found.\n\nI have added a \"Note about refactoring projects versus projects that\nimplement new features\" at the end of the idea list:\n\nhttps://github.com/git/git.github.io/blob/master/SoC-2019-Ideas.md#note-about-refactoring-projects-versus-projects-that-implement-new-features\n\nand I think that with that note students working on such projects will\nbe warned enough, and therefore hopefully have a better chance of\nsuccess.\n\nSo after all if you are willing to co-mentor such a project, I would\nbe ok to co-mentor it with you, and we should add it to the list.\n\nThanks,\nChristian.\n\nAnd yeah it would help improve our idea list as requested by Google.\n"},{"id":"369004","messageId":"CAL21Bm=n0pe5M0G5eB9svQcmM9dC023J46HFo-jYuDQeyKcwFw@mail.gmail.com","threadId":"50392","inReplyTo":"CAP8UFD24Jgetmb9_ANm07Emwr90obVpiRPyX+HtmaHcL1fYq5g@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Оля Тележная","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2019-02-11T08:31:35Z","receivedAt":"2019-02-11T08:39:19Z","isPatch":false,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"пн, 11 февр. 2019 г. в 10:46, Christian Couder <christian.couder@gmail.com>:\n>\n> On Mon, Feb 11, 2019 at 6:48 AM Оля Тележная <olyatelezhnaya@gmail.com> wrote:\n> >\n> > > It would be nice to have a few more project ideas.\n> >\n> > I am not sure I have additional ideas for 3-month project for the intern, but\n> >\n> > > https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible\n> > > projects:\n> > >\n> > > - Unify ref-filter formats with other --pretty formats (which is new)\n> >\n> > I am ready to act as a mentor in this task, I know that part of\n> > project good enough.\n>\n> Great! I thought that it would be a good project for you to mentor and\n> that's why I added it.\n>\n> By the way if you would prefer not to mentor the other project I can\n> remove you from its possible mentor list.\n\nI am ready to try mentoring on both projects, but it would be much\neasier for me to work only for this one. I removed my name from the\nother one and made pull request:\nhttps://github.com/git/git.github.io/pull/355\n\nIf project about pretty will not be selected by any of the students, I\nam happy to help other mentors with other projects.\n\n>\n> > I have additional related task: We have a function called\n> > oid_object_info, it allows to download meta-info of the file. It was\n> > used in cat-file, and inspired by that example, I improved ref-filter,\n> > so now ref-filter works faster with it. Moreover, I have found that\n> > oid_object_info allows to get the contents of the file. It was useful\n> > in ref-filter, and actually it could be also useful in cat-file, but\n> > we still download the file differently in cat-file, and it looks\n> > awkward. I need to make just one last move to finish my patch: it will\n> > close the task about migrating cat-file formatting logic to\n> > ref-filter. But cat-file still will not use general way to download\n> > the file. So, the task is to get rid of additional file-reading logic.\n> > I guess this task is much smaller than original one, but at least the\n> > student will have chance to finish it in 3 months.\n> > My patch is here: https://github.com/git/git/pull/568\n> > But I hope you will also see it this week in the mailing list.\n> > Proposed task is in TODO in the end of ref-filter file.\n>\n> Do you mean the following comment from\n> https://github.com/git/git/blob/c17ed82b8983ea7e172181d869966db546c6a528/ref-filter.c#L2393-L2399:\n>\n> /*\n> * TODO: add support of %(*raw). Need to switch between oi and oi_deref for that.\n> * TODO: split logic and printing (as it is done in format_ref_array_item and\n> * show_ref_array_item). After that we could use %(raw) in all\n> ref-filter commands.\n> * TODO: rewrite print_object_or_die so that it will reuse result of general\n> * oid_object_info_extended call.\n> */\n>\n> ?\n>\n> It doesn't look like that's it. Could you just copy the task into an\n> email? Or if you think it could be an idea for a GSoC project, could\n> you send a pull request to add it to:\n>\n> https://github.com/git/git.github.io/blob/master/SoC-2019-Ideas.md\n>\n> ?\n\nYes, that's it. Particularly, the last TODO. But other TODOs will be\nalso solved as a result. I can add it to the list of the projects if\nyou find this task suitable.\n\n>\n> > By the way, we had a letter from Google, it is said that our tasks are\n> > sparsed. I am not sure I understand it correctly. Should I help the\n> > project somehow to solve our issues?\n>\n> Yeah, we got en email from Stephanie Taylor saying that our idea list\n> is quite sparse this year with a link to:\n>\n> https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list\n>\n> which contains:\n>\n> \"Even if you are a new organization and only want one or two students\n> showing that you have multiple ideas (a bare minimum of 4 solid ideas)\n> is vital.\"\n>\n> They also want \"more detailed description of [each] project (2-5\n> sentences)\", so I think we should work on that too.\n\nI added description for one of projects, it is also in my pull request.\n\n>\n> So yeah, any help to fix the idea list is very welcome!\n>\n> Thanks,\n> Christian.\n"},{"id":"369010","messageId":"CAP8UFD11+rrJ4e4L=D4FX3mjdJ=sdZ8FVOUXQofTbFMxmXEAmw@mail.gmail.com","threadId":"50392","inReplyTo":"CAL21Bm=n0pe5M0G5eB9svQcmM9dC023J46HFo-jYuDQeyKcwFw@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-02-11T10:52:07Z","receivedAt":"2019-02-11T10:52:23Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Feb 11, 2019 at 9:39 AM Оля Тележная <olyatelezhnaya@gmail.com> wrote:\n>\n> пн, 11 февр. 2019 г. в 10:46, Christian Couder <christian.couder@gmail.com>:\n> >\n> > On Mon, Feb 11, 2019 at 6:48 AM Оля Тележная <olyatelezhnaya@gmail.com> wrote:\n\n> > > > - Unify ref-filter formats with other --pretty formats (which is new)\n> > >\n> > > I am ready to act as a mentor in this task, I know that part of\n> > > project good enough.\n> >\n> > Great! I thought that it would be a good project for you to mentor and\n> > that's why I added it.\n> >\n> > By the way if you would prefer not to mentor the other project I can\n> > remove you from its possible mentor list.\n>\n> I am ready to try mentoring on both projects, but it would be much\n> easier for me to work only for this one. I removed my name from the\n> other one and made pull request:\n> https://github.com/git/git.github.io/pull/355\n\nGreat, merged!\n\n> If project about pretty will not be selected by any of the students, I\n> am happy to help other mentors with other projects.\n\nOk, we will see.\n\n> > Do you mean the following comment from\n> > https://github.com/git/git/blob/c17ed82b8983ea7e172181d869966db546c6a528/ref-filter.c#L2393-L2399:\n> >\n> > /*\n> > * TODO: add support of %(*raw). Need to switch between oi and oi_deref for that.\n> > * TODO: split logic and printing (as it is done in format_ref_array_item and\n> > * show_ref_array_item). After that we could use %(raw) in all\n> > ref-filter commands.\n> > * TODO: rewrite print_object_or_die so that it will reuse result of general\n> > * oid_object_info_extended call.\n> > */\n> >\n> > ?\n> >\n> > It doesn't look like that's it. Could you just copy the task into an\n> > email? Or if you think it could be an idea for a GSoC project, could\n> > you send a pull request to add it to:\n> >\n> > https://github.com/git/git.github.io/blob/master/SoC-2019-Ideas.md\n> >\n> > ?\n>\n> Yes, that's it. Particularly, the last TODO. But other TODOs will be\n> also solved as a result. I can add it to the list of the projects if\n> you find this task suitable.\n\nI think it is ok if we propose that task first and then the \"Unify\nref-filter formats with other --pretty formats\" project in case the\nstudent finishes the first task soon. Or do you see other tasks for a\nstudent after this?\n\nAnyway I don't think we should have both one student working on the\n\"Unify ref-filter formats with other --pretty formats\" project and\nanother one on this task.\n\nBut yeah, if you want, feel free to send a pull request to add it with\nthe above caveats.\n\n> > They also want \"more detailed description of [each] project (2-5\n> > sentences)\", so I think we should work on that too.\n>\n> I added description for one of projects, it is also in my pull request.\n\nThanks,\nChristian.\n"},{"id":"369047","messageId":"20190211221827.GG6085@hank.intra.tgummerer.com","threadId":"50392","inReplyTo":"CAP8UFD1Rv+nFqDYf33rRw-kWnfqokSG6=tG8XPFyBoVCU6Te=w@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2019-02-11T22:18:27Z","receivedAt":"2019-02-11T22:18:33Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 02/11, Christian Couder wrote:\n> On Thu, Feb 7, 2019 at 10:33 PM Thomas Gummerer <t.gummerer@gmail.com> wrote:\n> >\n> > On 02/07, Johannes Schindelin wrote:\n> > > On Wed, 6 Feb 2019, Thomas Gummerer wrote:\n> > > >  - implement pushing/poping conflicted state\n> > > >\n> > > >    This would obviously be the end goal.\n> > >\n> > > On second thought, this might actually be super trivial. Right now, we\n> > > support two modes (not counting the `--untracked` stuff): --keep-index and\n> > > --no-keep-index. In both cases, we seem to create a merge commit whose\n> > > tree reflects the working directory and whose first parent is HEAD and\n> > > whose second parent is a single commit on top of HEAD (which contains\n> > > either no changes in the case of --no-keep-index, or whose tree reflects\n> > > the index in case of --keep-index).\n> > >\n> > > To extend that to the conflict case, we could introduce a new flag\n> > > --with-conflicts, and have the commit structure\n> > >\n> > >       Worktree\n> > >        |    \\\n> > >        |    index stage 0\n> > >        |      /     |     \\\n> > >        | stage 1  stage 2  stage 3\n> > >        |    /     /       /\n> > >       HEAD ---------------\n> > >\n> > > The only tricky thing I can see is to maintain backwards compatibility if\n> > > possible, so that old `git stash` will do something at least semi-sensible\n> > > with those commit structures.\n> > >\n> > > It might be too small a project, after all.\n> >\n> > Yeah, looking at this I think you're right.  Thanks for helping work\n> > through this.\n> \n> I am not sure it will be too small a project, especially because it is\n> a new feature. On top of the coding part, the student will also have\n> to come up with good documentation and test cases, and there will\n> probably be naming and workflow discussions and possibly refactoring\n> opportunities and bug fixes along the way.\n\nI still think it's on the smaller side, but also as you mention below\nwe have usually been rather optimistic about project sizes.  So maybe\nthis is the right size for a GSoC after all.\n\n> Yeah, the naming and workflow discussions should actually happen when\n> discussing the student's proposal, in which case an important part of\n> the work will (hopefully) be done before the GSoC actually starts.\n> \n> Historically though we have always been very optimistic in what we\n> thought a student could accomplish in a GSoC. And we are very likely\n> to find more ideas for improvements during the GSoC, in case\n> everything is \"finished\" before the end. I actually think that it has\n> never happened that a student both \"finished\" the project before the\n> end, and that no idea for improvement on top of the work was found.\n\nFair enough.  I think there's still a number of things that could do\nwith some refactoring in 'builtin/stash.c', e.g. use more of the\nlibgit.a API, instead of using the run_command API, or potentially\nother improvements that could be made.\n\nAnother thing that may be useful to do is to write down some actual\ntechnical documentation on the format of what a stash commit looks\nlike.\n\n> I have added a \"Note about refactoring projects versus projects that\n> implement new features\" at the end of the idea list:\n> \n> https://github.com/git/git.github.io/blob/master/SoC-2019-Ideas.md#note-about-refactoring-projects-versus-projects-that-implement-new-features\n> \n> and I think that with that note students working on such projects will\n> be warned enough, and therefore hopefully have a better chance of\n> success.\n>\n> So after all if you are willing to co-mentor such a project, I would\n> be ok to co-mentor it with you, and we should add it to the list.\n\nOk, I'll submit a PR to add it to the list.\n\n> Thanks,\n> Christian.\n> \n> And yeah it would help improve our idea list as requested by Google.\n"},{"id":"369058","messageId":"CAP8UFD3s3-mR528FqV3yuMEZBqT0uP+Mp5hGDcN_a1LfAsR0bg@mail.gmail.com","threadId":"50392","inReplyTo":"20190211221827.GG6085@hank.intra.tgummerer.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-02-11T23:58:38Z","receivedAt":"2019-02-11T23:58:54Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Feb 11, 2019 at 11:18 PM Thomas Gummerer <t.gummerer@gmail.com> wrote:\n>\n> On 02/11, Christian Couder wrote:\n\n> > Historically though we have always been very optimistic in what we\n> > thought a student could accomplish in a GSoC. And we are very likely\n> > to find more ideas for improvements during the GSoC, in case\n> > everything is \"finished\" before the end. I actually think that it has\n> > never happened that a student both \"finished\" the project before the\n> > end, and that no idea for improvement on top of the work was found.\n>\n> Fair enough.  I think there's still a number of things that could do\n> with some refactoring in 'builtin/stash.c', e.g. use more of the\n> libgit.a API, instead of using the run_command API, or potentially\n> other improvements that could be made.\n>\n> Another thing that may be useful to do is to write down some actual\n> technical documentation on the format of what a stash commit looks\n> like.\n\nYeah, using more of the libgit.a API, instead of the run_command API,\nand writing technical documentation on the stash commit format look\nlike good ideas to me. I think I will add those items to the project\ndescription if you don't mind.\n\n> > So after all if you are willing to co-mentor such a project, I would\n> > be ok to co-mentor it with you, and we should add it to the list.\n>\n> Ok, I'll submit a PR to add it to the list.\n\nGreat! I merged your PR.\n\nI also resurrected the \"Convert scripts to builtins\" idea as I think\nthere might still be shell scripts that could be converted, like\nperhaps git-merge-octopus.sh, git-merge-one-file.sh and\ngit-merge-resolve.sh.\n\nSo I think we should be good regarding Google requirements.\n\nThanks,\nChristian.\n"},{"id":"369179","messageId":"20190212202501.GA17681@hank.intra.tgummerer.com","threadId":"50392","inReplyTo":"CAP8UFD3s3-mR528FqV3yuMEZBqT0uP+Mp5hGDcN_a1LfAsR0bg@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2019-02-12T20:25:01Z","receivedAt":"2019-02-12T20:25:08Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 02/12, Christian Couder wrote:\n> On Mon, Feb 11, 2019 at 11:18 PM Thomas Gummerer <t.gummerer@gmail.com> wrote:\n> >\n> > On 02/11, Christian Couder wrote:\n> \n> > > Historically though we have always been very optimistic in what we\n> > > thought a student could accomplish in a GSoC. And we are very likely\n> > > to find more ideas for improvements during the GSoC, in case\n> > > everything is \"finished\" before the end. I actually think that it has\n> > > never happened that a student both \"finished\" the project before the\n> > > end, and that no idea for improvement on top of the work was found.\n> >\n> > Fair enough.  I think there's still a number of things that could do\n> > with some refactoring in 'builtin/stash.c', e.g. use more of the\n> > libgit.a API, instead of using the run_command API, or potentially\n> > other improvements that could be made.\n> >\n> > Another thing that may be useful to do is to write down some actual\n> > technical documentation on the format of what a stash commit looks\n> > like.\n> \n> Yeah, using more of the libgit.a API, instead of the run_command API,\n> and writing technical documentation on the stash commit format look\n> like good ideas to me. I think I will add those items to the project\n> description if you don't mind.\n\nSure that sounds good, thanks!  I think using more of the libgit.a API\nshould probably be an optional endeavor, but writing the technical\ndocumentation may be a good thing to include in the project.\n\n> > > So after all if you are willing to co-mentor such a project, I would\n> > > be ok to co-mentor it with you, and we should add it to the list.\n> >\n> > Ok, I'll submit a PR to add it to the list.\n> \n> Great! I merged your PR.\n> \n> I also resurrected the \"Convert scripts to builtins\" idea as I think\n> there might still be shell scripts that could be converted, like\n> perhaps git-merge-octopus.sh, git-merge-one-file.sh and\n> git-merge-resolve.sh.\n\nThese all look quite small, but yeah perhaps converting a few of them\nover the course of the summer might be an alright project.\n\n> So I think we should be good regarding Google requirements.\n> \n> Thanks,\n> Christian.\n"},{"id":"369180","messageId":"CAP8UFD19Mhpm4MRjQ3xsPx-_Gc6CweTWC3aHbqyhyy0C0dvR1g@mail.gmail.com","threadId":"50392","inReplyTo":"20190212202501.GA17681@hank.intra.tgummerer.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-02-12T20:49:54Z","receivedAt":"2019-02-12T20:50:10Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Feb 12, 2019 at 9:25 PM Thomas Gummerer <t.gummerer@gmail.com> wrote:\n>\n> On 02/12, Christian Couder wrote:\n\n> > Yeah, using more of the libgit.a API, instead of the run_command API,\n> > and writing technical documentation on the stash commit format look\n> > like good ideas to me. I think I will add those items to the project\n> > description if you don't mind.\n>\n> Sure that sounds good, thanks!  I think using more of the libgit.a API\n> should probably be an optional endeavor, but writing the technical\n> documentation may be a good thing to include in the project.\n\nOk, there is now the following at the end of the idea:\n\n\"This will include writing the technical documentation of the stash\nformat, and optionally refactoring the `git stash` code to use more of\nthe libgit.a API, instead of the run_command API.\"\n"},{"id":"369184","messageId":"20190212221349.GH6085@hank.intra.tgummerer.com","threadId":"50392","inReplyTo":"CAP8UFD19Mhpm4MRjQ3xsPx-_Gc6CweTWC3aHbqyhyy0C0dvR1g@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Thomas Gummerer","fromEmail":"t.gummerer@gmail.com","sentAt":"2019-02-12T22:13:49Z","receivedAt":"2019-02-12T22:13:55Z","isPatch":false,"sender":{"key":"t.gummerer@gmail.com","avatar":"https://avatars.githubusercontent.com/u/191004?v=4"},"body":"On 02/12, Christian Couder wrote:\n> On Tue, Feb 12, 2019 at 9:25 PM Thomas Gummerer <t.gummerer@gmail.com> wrote:\n> >\n> > On 02/12, Christian Couder wrote:\n> \n> > > Yeah, using more of the libgit.a API, instead of the run_command API,\n> > > and writing technical documentation on the stash commit format look\n> > > like good ideas to me. I think I will add those items to the project\n> > > description if you don't mind.\n> >\n> > Sure that sounds good, thanks!  I think using more of the libgit.a API\n> > should probably be an optional endeavor, but writing the technical\n> > documentation may be a good thing to include in the project.\n> \n> Ok, there is now the following at the end of the idea:\n> \n> \"This will include writing the technical documentation of the stash\n> format, and optionally refactoring the `git stash` code to use more of\n> the libgit.a API, instead of the run_command API.\"\n\nThanks, this sounds good to me.\n"},{"id":"369263","messageId":"CABPp-BGNMN0QZWa4E4kBFOs8RcUQoMuMT2J_zKhwOTQPbaGU4g@mail.gmail.com","threadId":"50392","inReplyTo":"CAL21Bmkkpzp7fhAnjstTjeH+unDFk8-uhFAgKFfuczYzejf2RA@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-02-13T22:36:51Z","receivedAt":"2019-02-13T22:37:07Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Sun, Feb 10, 2019 at 9:51 PM Оля Тележная <olyatelezhnaya@gmail.com> wrote:\n>\n> > It would be nice to have a few more project ideas.\n>\n> I am not sure I have additional ideas for 3-month project for the intern, but\n>\n> > https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible\n> > projects:\n> >\n> > - Unify ref-filter formats with other --pretty formats (which is new)\n>\n> I am ready to act as a mentor in this task, I know that part of\n> project good enough.\n> I have additional related task: We have a function called\n> oid_object_info, it allows to download meta-info of the file. It was\n> used in cat-file, and inspired by that example, I improved ref-filter,\n> so now ref-filter works faster with it. Moreover, I have found that\n> oid_object_info allows to get the contents of the file. It was useful\n> in ref-filter, and actually it could be also useful in cat-file, but\n> we still download the file differently in cat-file, and it looks\n> awkward. I need to make just one last move to finish my patch: it will\n> close the task about migrating cat-file formatting logic to\n> ref-filter. But cat-file still will not use general way to download\n> the file. So, the task is to get rid of additional file-reading logic.\n> I guess this task is much smaller than original one, but at least the\n> student will have chance to finish it in 3 months.\n> My patch is here: https://github.com/git/git/pull/568\n> But I hope you will also see it this week in the mailing list.\n> Proposed task is in TODO in the end of ref-filter file.\n>\n> By the way, we had a letter from Google, it is said that our tasks are\n> sparsed. I am not sure I understand it correctly. Should I help the\n> project somehow to solve our issues?\n\nI'm a little hesitant to suggest this as I'm not sure how available I\ncould be for mentoring and don't view myself as a good mentor, but\nanother project idea which has lots of sub-pieces and thus could show\nprogress and be useful even if not everything is completed:\n\nConsistency of sequencer commands:\n* The suggestion to fix an interrupted rebase-i or cherry-pick due to\na commit that became empty via 'git reset HEAD' (in builtin/commit.c)\ninstead of 'git rebase --skip' or 'git cherry-pick --skip' ranges from\nannoying to confusing.  (Especially since other interrupted am's and\nrebases both point to am/rebase --skip.).  Note that 'git cherry-pick\n--skip' is not yet implemented, so that would have to be added first.\n* There are a handful of flags that am-based rebases support that are\nnot available to interactive/merge-based rebases; it'd be nice to\nimplement them for the interactive machinery.  (There are also\nnumerous flags that only the interactive machinery supports that are\nunavailable to am-based rebases, but I don't care; I want to deprecate\nam-based rebases.)\n  * --ignore-whitespace (transliterate to -Xignore-space-change?)\n  * --whitespace=...\n  * --committer-date-is-author-date/--ignore-date\n  * -C4\n\n[There's also some empty handling (from \"Behavioral Differences\" in\nDocumentation/git-rebase.txt) that would be nice to address, though\nthat might be contentious and I might try to tackle that piece before\nGSoC gets rolling...]\n\nBonus: Make a flag to allow rebase to rewrite commit messages that\nrefer to older commits that were also rebased.  (i.e. if rebasing\ncommits A and B, and commit B says \"This reverts commit <sha-of-A>,\nthen rewritten B's commit message should say \"This reverts commit\n<sha-of-rewritten-A\".)  Do this for both sha1sums and sha1sum\nabbreviations in commit messages.\n"},{"id":"369302","messageId":"CAP8UFD3kOp0iAX_A8K9wAht5=Zxp6Rea1fsDt8inG9ZpT-TWdw@mail.gmail.com","threadId":"50392","inReplyTo":"CABPp-BGNMN0QZWa4E4kBFOs8RcUQoMuMT2J_zKhwOTQPbaGU4g@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-02-14T09:48:14Z","receivedAt":"2019-02-14T09:48:31Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Wed, Feb 13, 2019 at 11:37 PM Elijah Newren <newren@gmail.com> wrote:\n>\n> I'm a little hesitant to suggest this as I'm not sure how available I\n> could be for mentoring and don't view myself as a good mentor, but\n> another project idea which has lots of sub-pieces and thus could show\n> progress and be useful even if not everything is completed:\n>\n> Consistency of sequencer commands:\n...\n\nThanks! I like this idea, as it indeed consists in multiple tasks that\ncould be worked on independently.\n\nAlso 2 previous GSoC students already worked on the sequencer (in 2008\nand 2010 IIRC), and I think Alban has been working on it too, so it\nwould be nice if another one worked on completing that work.\n\nI added it to the Idea page.\n"},{"id":"370677","messageId":"CACsJy8DhDe+28z2=3v1dBqco7q2Zj12hdKKT==yWFPui8SBkiw@mail.gmail.com","threadId":"50392","inReplyTo":"CAP8UFD2kt=Rv4pC67q0s+CKjgmBON_KkK09igfwe-0709Di2RQ@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2019-03-05T12:04:59Z","receivedAt":"2019-03-05T12:05:29Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Feb 4, 2019 at 4:17 PM Christian Couder\n<christian.couder@gmail.com> wrote:\n>\n> Hi everyone,\n>\n> There are now ideas, micro-projects and organization application pages\n> for GSoC 2019 on https://git.github.io/\n>\n> It would be nice to have a few more project ideas.\n\nNot sure if it's too late now. Anyway this could be something fun to\ndo: support C-based tests in our test suite.\n\nA while back I noticed some test running very long because it was\ntrying a lot of input combination. The actual logic is not much, but\nbecause of the increasing number of test cases, overhead goes off the\nroof. The last part is probably not true, but Windows port I think is\nhit much harder than what I experience, and I think Dscho did complain\nabout it.\n\nSo what this project does is somehow allow people to write test cases\nin C instead of shell. Imagine replacing t3070-wildmatch.sh with a\nbinary program t3070-wildmatch that behaves the same way. This test\nframework needs to support the same basic feature set as test-lib.sh:\nTAP output, test results summary, maybe -i and --valgrind... To\ndemonstrate that the test framework works, one of these long test\nfiles should be rewritten in C. I'm sure there's one that is simple to\nrewrite.\n\nI'm pretty sure I had some fun with this idea and made some prototype\nbut I couldn't find it. If I do, I'll post the link here.\n-- \nDuy\n"},{"id":"370681","messageId":"CACsJy8D=itd7m16BazCFjSgbPw1nQBaA_7SOZqpJS1N+njHSuw@mail.gmail.com","threadId":"50392","inReplyTo":"CACsJy8DhDe+28z2=3v1dBqco7q2Zj12hdKKT==yWFPui8SBkiw@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2019-03-05T12:23:24Z","receivedAt":"2019-03-05T12:23:52Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 5, 2019 at 7:04 PM Duy Nguyen <pclouds@gmail.com> wrote:\n> Not sure if it's too late now. Anyway this could be something fun to\n> do: support C-based tests in our test suite.\n>\n> ...\n>\n> I'm pretty sure I had some fun with this idea and made some prototype\n> but I couldn't find it. If I do, I'll post the link here.\n\nFound it. Far from complete, but it gives a general direction I hope\n\nhttps://public-inbox.org/git/20180110090724.GA2893@ash/\n\n-- \nDuy\n"},{"id":"370782","messageId":"20190306044955.GC6664@sigill.intra.peff.net","threadId":"50392","inReplyTo":"CACsJy8DhDe+28z2=3v1dBqco7q2Zj12hdKKT==yWFPui8SBkiw@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-06T04:49:56Z","receivedAt":"2019-03-06T04:49:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 05, 2019 at 07:04:59PM +0700, Duy Nguyen wrote:\n\n> On Mon, Feb 4, 2019 at 4:17 PM Christian Couder\n> <christian.couder@gmail.com> wrote:\n> >\n> > Hi everyone,\n> >\n> > There are now ideas, micro-projects and organization application pages\n> > for GSoC 2019 on https://git.github.io/\n> >\n> > It would be nice to have a few more project ideas.\n> \n> Not sure if it's too late now. Anyway this could be something fun to\n> do: support C-based tests in our test suite.\n> \n> A while back I noticed some test running very long because it was\n> trying a lot of input combination. The actual logic is not much, but\n> because of the increasing number of test cases, overhead goes off the\n> roof. The last part is probably not true, but Windows port I think is\n> hit much harder than what I experience, and I think Dscho did complain\n> about it.\n> \n> So what this project does is somehow allow people to write test cases\n> in C instead of shell. Imagine replacing t3070-wildmatch.sh with a\n> binary program t3070-wildmatch that behaves the same way. This test\n> framework needs to support the same basic feature set as test-lib.sh:\n> TAP output, test results summary, maybe -i and --valgrind... To\n> demonstrate that the test framework works, one of these long test\n> files should be rewritten in C. I'm sure there's one that is simple to\n> rewrite.\n> \n> I'm pretty sure I had some fun with this idea and made some prototype\n> but I couldn't find it. If I do, I'll post the link here.\n\nIn my experience, it's nicer to have a tool written in C that can be\ndriven by arbitrary input. That makes it easy to write new test cases,\nbecause you just have to write in some easy domain-specific format\ninstead of embedding the test data in C code.\n\nAnd many of our tests do work like that (in fact, many of the Git\nplumbing tools function as that). E.g., test-date gives you direct\naccess to the low-level routines, and we feed it a variety of dates.\n\nThat doesn't help with the cost of invoking that tool over and over,\nthough, once per test case. I wonder if we could have some kind of\nhybrid. I.e., where t3070 is still a shell script, but it primarily\nconsists of running one big binary, like:\n\n  test-wildmatch <<-\\EOF\n  case 1\n  case 2\n  ...etc\n  EOF\n\nbut with one added twist: test-wildmatch would actually generate TAP\noutput for each test, rather than just returning 0/1 for each success or\nfailure, and being embedded in a test_expect_success.\n\nIt seems like that would even be pretty easy to do, with the exception\nof the numbering. It would be nice if we could intermingle this kind of\n\"chunk of C tests\" with normal tests, but we'd have to figure out how\nmany tests it ran and increment our shell-script's counter\nappropriately.\n\n-Peff\n"},{"id":"370796","messageId":"CACsJy8BaCMsXhXSAwu+wmZCTwL5TO8wVDtGd87vRwH=AcOsThA@mail.gmail.com","threadId":"50392","inReplyTo":"20190306044955.GC6664@sigill.intra.peff.net","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2019-03-06T09:36:12Z","receivedAt":"2019-03-06T09:36:41Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Mar 6, 2019 at 11:49 AM Jeff King <peff@peff.net> wrote:\n>\n> On Tue, Mar 05, 2019 at 07:04:59PM +0700, Duy Nguyen wrote:\n>\n> > On Mon, Feb 4, 2019 at 4:17 PM Christian Couder\n> > <christian.couder@gmail.com> wrote:\n> > >\n> > > Hi everyone,\n> > >\n> > > There are now ideas, micro-projects and organization application pages\n> > > for GSoC 2019 on https://git.github.io/\n> > >\n> > > It would be nice to have a few more project ideas.\n> >\n> > Not sure if it's too late now. Anyway this could be something fun to\n> > do: support C-based tests in our test suite.\n> >\n> > A while back I noticed some test running very long because it was\n> > trying a lot of input combination. The actual logic is not much, but\n> > because of the increasing number of test cases, overhead goes off the\n> > roof. The last part is probably not true, but Windows port I think is\n> > hit much harder than what I experience, and I think Dscho did complain\n> > about it.\n> >\n> > So what this project does is somehow allow people to write test cases\n> > in C instead of shell. Imagine replacing t3070-wildmatch.sh with a\n> > binary program t3070-wildmatch that behaves the same way. This test\n> > framework needs to support the same basic feature set as test-lib.sh:\n> > TAP output, test results summary, maybe -i and --valgrind... To\n> > demonstrate that the test framework works, one of these long test\n> > files should be rewritten in C. I'm sure there's one that is simple to\n> > rewrite.\n> >\n> > I'm pretty sure I had some fun with this idea and made some prototype\n> > but I couldn't find it. If I do, I'll post the link here.\n>\n> In my experience, it's nicer to have a tool written in C that can be\n> driven by arbitrary input. That makes it easy to write new test cases,\n> because you just have to write in some easy domain-specific format\n> instead of embedding the test data in C code.\n>\n> And many of our tests do work like that (in fact, many of the Git\n> plumbing tools function as that). E.g., test-date gives you direct\n> access to the low-level routines, and we feed it a variety of dates.\n>\n> That doesn't help with the cost of invoking that tool over and over,\n> though, once per test case. I wonder if we could have some kind of\n> hybrid. I.e., where t3070 is still a shell script, but it primarily\n> consists of running one big binary, like:\n>\n>   test-wildmatch <<-\\EOF\n>   case 1\n>   case 2\n>   ...etc\n>   EOF\n>\n> but with one added twist: test-wildmatch would actually generate TAP\n> output for each test, rather than just returning 0/1 for each success or\n> failure, and being embedded in a test_expect_success.\n\nYeah. I mean, converting a full file is just one of the ways to go.\nThe exact design is up to whoever implements it.\n\n> It seems like that would even be pretty easy to do, with the exception\n> of the numbering.\n\nI'd like some niceties from test-lib.sh though. -i should be supported\nto stop at the first failure. -v would be nice if possible. Skipping\ntsets also.\n\n> It would be nice if we could intermingle this kind of\n> \"chunk of C tests\" with normal tests, but we'd have to figure out how\n> many tests it ran and increment our shell-script's counter\n> appropriately.\n\nEven if you convert a full file, you need to do that anyway, to make\nsure final test run summary is correct (at least when TAP is not used)\n\nThis kind of framework, I think also helps write new unit tests. There\nare cases where creating the right condition to trigger just one\nfunction is lots of work and easy to break. Sometimes it's easier to\ndo everything in C when full repository is not involved.\n-- \nDuy\n"},{"id":"370813","messageId":"nycvar.QRO.7.76.6.1903061515140.41@tvgsbejvaqbjf.bet","threadId":"50392","inReplyTo":"20190306044955.GC6664@sigill.intra.peff.net","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-03-06T14:16:33Z","receivedAt":"2019-03-06T14:16:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Peff,\n\nOn Tue, 5 Mar 2019, Jeff King wrote:\n\n> On Tue, Mar 05, 2019 at 07:04:59PM +0700, Duy Nguyen wrote:\n> \n> > On Mon, Feb 4, 2019 at 4:17 PM Christian Couder\n> > <christian.couder@gmail.com> wrote:\n> > >\n> > > Hi everyone,\n> > >\n> > > There are now ideas, micro-projects and organization application pages\n> > > for GSoC 2019 on https://git.github.io/\n> > >\n> > > It would be nice to have a few more project ideas.\n> > \n> > Not sure if it's too late now. Anyway this could be something fun to\n> > do: support C-based tests in our test suite.\n> > \n> > A while back I noticed some test running very long because it was\n> > trying a lot of input combination. The actual logic is not much, but\n> > because of the increasing number of test cases, overhead goes off the\n> > roof. The last part is probably not true, but Windows port I think is\n> > hit much harder than what I experience, and I think Dscho did complain\n> > about it.\n> > \n> > So what this project does is somehow allow people to write test cases\n> > in C instead of shell. Imagine replacing t3070-wildmatch.sh with a\n> > binary program t3070-wildmatch that behaves the same way. This test\n> > framework needs to support the same basic feature set as test-lib.sh:\n> > TAP output, test results summary, maybe -i and --valgrind... To\n> > demonstrate that the test framework works, one of these long test\n> > files should be rewritten in C. I'm sure there's one that is simple to\n> > rewrite.\n> > \n> > I'm pretty sure I had some fun with this idea and made some prototype\n> > but I couldn't find it. If I do, I'll post the link here.\n> \n> In my experience, it's nicer to have a tool written in C that can be\n> driven by arbitrary input. That makes it easy to write new test cases,\n> because you just have to write in some easy domain-specific format\n> instead of embedding the test data in C code.\n> \n> And many of our tests do work like that (in fact, many of the Git\n> plumbing tools function as that). E.g., test-date gives you direct\n> access to the low-level routines, and we feed it a variety of dates.\n> \n> That doesn't help with the cost of invoking that tool over and over,\n> though, once per test case. I wonder if we could have some kind of\n> hybrid. I.e., where t3070 is still a shell script, but it primarily\n> consists of running one big binary, like:\n> \n>   test-wildmatch <<-\\EOF\n>   case 1\n>   case 2\n>   ...etc\n>   EOF\n> \n> but with one added twist: test-wildmatch would actually generate TAP\n> output for each test, rather than just returning 0/1 for each success or\n> failure, and being embedded in a test_expect_success.\n> \n> It seems like that would even be pretty easy to do, with the exception\n> of the numbering. It would be nice if we could intermingle this kind of\n> \"chunk of C tests\" with normal tests, but we'd have to figure out how\n> many tests it ran and increment our shell-script's counter\n> appropriately.\n\nOooooh, that sounds like a very nice idea! Eventually, we might even be\nable to specify our test cases in our own, extensible language, where we\ndo not have to pay attention to &&-chains, or portability, because our\ntest runner does all that for us, under the hood, as it should be.\n\nDreaming of that future,\nDscho\n"},{"id":"370821","messageId":"20190306190819.GC18239@sigill.intra.peff.net","threadId":"50392","inReplyTo":"CACsJy8BaCMsXhXSAwu+wmZCTwL5TO8wVDtGd87vRwH=AcOsThA@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-03-06T19:08:19Z","receivedAt":"2019-03-06T19:08:23Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Mar 06, 2019 at 04:36:12PM +0700, Duy Nguyen wrote:\n\n> > It seems like that would even be pretty easy to do, with the exception\n> > of the numbering.\n> \n> I'd like some niceties from test-lib.sh though. -i should be supported\n> to stop at the first failure. -v would be nice if possible. Skipping\n> tsets also.\n\nYeah, I'd want all of those, too. I think they're easier, though,\nbecause it's not too hard to get information _into_ the C program via\nthe environment. But still, somebody has to write the code. :)\n\n-Peff\n"},{"id":"371811","messageId":"CACsJy8DtoMMSu5Vm4+ZkeUqCOo7stM4HObLkiSc-nQQV4G=GvA@mail.gmail.com","threadId":"50392","inReplyTo":"CAP8UFD2kt=Rv4pC67q0s+CKjgmBON_KkK09igfwe-0709Di2RQ@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2019-03-18T12:51:34Z","receivedAt":"2019-03-18T12:52:03Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Feb 4, 2019 at 4:17 PM Christian Couder\n<christian.couder@gmail.com> wrote:\n>\n> Hi everyone,\n>\n> There are now ideas, micro-projects and organization application pages\n> for GSoC 2019 on https://git.github.io/\n>\n> It would be nice to have a few more project ideas.\n> https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible\n> projects:\n>\n> - Unify ref-filter formats with other --pretty formats (which is new)\n> - git log --oneline improvements\n>\n> as I didn't feel that the others were still relevant, though I might be wrong.\n>\n> As Olga and Thomas told me at the Git Merge that they could be ok to\n> co-mentor with me, they are listed as possible mentors for both of\n> these projects.\n>\n> Anyway feel free to comment and suggest improvements on those pages,\n> especially the micro-projects and ideas one. Pull requests on\n> https://github.com/git/git.github.io/ are very much appreciated.\n\nI'm not opening a pull request because I'm not sure if it's worthy of\nGSoC (probably 2020, not 2019) but anyway the get_config_* discussion\nelsewhere reminds me of this.\n\nCurrently we have two ways of parsing config files, by a callback that\ngives you everything and you do whatever you want, and with configset\nwhere you can just call \"get me this config\", \"get me that one\". The\nidea is moving most callback-based sites to get_config_ one.\nPreferably in a declarative style, like 'struct option[]'.\n\nThis should reduce some amount of code because all the \"if (!strcmp..)\nvar = git_confg...\" is handled by a common code. It's easier to read\ntoo. And it may open up an opportunity to suggest misspelled config\nname (a bit far fetched) and list relevant configs of any command,\nperhaps with a short description of each config variable too. The\nconfigset way should be a bit faster too, but I don't think we care\nabout performance at all here.\n\nTo handle three-level config like remote.*.url, we can still do it the\ndeclarative way by declaring the pattern \"remote.*\" instead of a fixed\nvariable name which we can't know in advance. There will still be a\ncallback to handle remote.* vars correctly, but the callback should be\nmuch smaller and easier to manage, I hope.\n-- \nDuy\n"},{"id":"371825","messageId":"CAP8UFD2uBqq9M7SB4KPzM2Am9G6dLOUjBs4sx3U69hK-bzonrQ@mail.gmail.com","threadId":"50392","inReplyTo":"CACsJy8DtoMMSu5Vm4+ZkeUqCOo7stM4HObLkiSc-nQQV4G=GvA@mail.gmail.com","subject":"Re: GSoC 2019: Git's application submitted","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-03-18T16:37:28Z","receivedAt":"2019-03-18T16:37:45Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Mon, Mar 18, 2019 at 1:52 PM Duy Nguyen <pclouds@gmail.com> wrote:\n>\n> On Mon, Feb 4, 2019 at 4:17 PM Christian Couder\n> <christian.couder@gmail.com> wrote:\n\n> > Anyway feel free to comment and suggest improvements on those pages,\n> > especially the micro-projects and ideas one. Pull requests on\n> > https://github.com/git/git.github.io/ are very much appreciated.\n>\n> I'm not opening a pull request because I'm not sure if it's worthy of\n> GSoC (probably 2020, not 2019) but anyway the get_config_* discussion\n> elsewhere reminds me of this.\n\nI think it would be nice to have a section with potential ideas along\nwith a big warning saying that the ideas there aren't  developed\nenough as is and need much more work/thinking to be considered proper\nideas, but we are still putting them there to not forget about them\nand in case someone would be interested to develop/research them\nfurther.\n\n> Currently we have two ways of parsing config files, by a callback that\n> gives you everything and you do whatever you want, and with configset\n> where you can just call \"get me this config\", \"get me that one\". The\n> idea is moving most callback-based sites to get_config_ one.\n> Preferably in a declarative style, like 'struct option[]'.\n\nThanks, I like this idea! Maybe it could be even considered for\nmicroprojects, as I think it could be done in many small steps. It\nwould perhaps need to point to en existing commit doing already that\nto make it clearer and easier though.\n"}]}