* GSoC 2019: Git's application submitted @ 2019-02-04 9:16 Christian Couder [not found] ` <CAL21Bm=K6zZ=APkiP3A_X7xVoOfx-MY2435YMp5y1ztE-xyYtg@mail.gmail.com> ` (3 more replies) 0 siblings, 4 replies; 29+ messages in thread From: Christian Couder @ 2019-02-04 9:16 UTC (permalink / raw) To: git Cc: Jeff King, Stefan Beller, SZEDER Gábor, Thomas Gummerer, Оля Тележная, Matthieu Moy Hi everyone, There are now ideas, micro-projects and organization application pages for GSoC 2019 on https://git.github.io/ It would be nice to have a few more project ideas. https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible projects: - Unify ref-filter formats with other --pretty formats (which is new) - git log --oneline improvements as I didn't feel that the others were still relevant, though I might be wrong. As Olga and Thomas told me at the Git Merge that they could be ok to co-mentor with me, they are listed as possible mentors for both of these projects. Anyway feel free to comment and suggest improvements on those pages, especially the micro-projects and ideas one. Pull requests on https://github.com/git/git.github.io/ are very much appreciated. The application has been submitted on https://summerofcode.withgoogle.com, but it will not be complete until someone else volunteers as an org admin. I volunteered, but they require "at least 2 and at most 5 Organization Administrators". So another org admin is needed before Wednesday February 6th, as this is the deadline. Invitations have been sent to Peff, Thomas, Olga and Matthieu, but anyone can do it and it requires a very low amount of work. Thanks, Christian. ^ permalink raw reply [flat|nested] 29+ messages in thread
[parent not found: <CAL21Bm=K6zZ=APkiP3A_X7xVoOfx-MY2435YMp5y1ztE-xyYtg@mail.gmail.com>]
* Re: GSoC 2019: Git's application submitted [not found] ` <CAL21Bm=K6zZ=APkiP3A_X7xVoOfx-MY2435YMp5y1ztE-xyYtg@mail.gmail.com> @ 2019-02-04 12:54 ` Christian Couder 0 siblings, 0 replies; 29+ messages in thread From: Christian Couder @ 2019-02-04 12:54 UTC (permalink / raw) To: Оля Тележная Cc: git, Jeff King, Stefan Beller, SZEDER Gábor, Thomas Gummerer, Matthieu Moy On Mon, Feb 4, 2019 at 11:28 AM Оля Тележная <olyatelezhnaya@gmail.com> wrote: > > пн, 4 февр. 2019 г., 10:16 Christian Couder christian.couder@gmail.com: >> >> The application has been submitted on >> https://summerofcode.withgoogle.com, but it will not be complete until >> someone else volunteers as an org admin. I volunteered, but they >> require "at least 2 and at most 5 Organization Administrators". > > Thank you, > I filled the form in. Thank you Olga! The application is complete now, though of course we can still add org admins and improve our "ideas" and "microprojects" pages. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-04 9:16 GSoC 2019: Git's application submitted Christian Couder [not found] ` <CAL21Bm=K6zZ=APkiP3A_X7xVoOfx-MY2435YMp5y1ztE-xyYtg@mail.gmail.com> @ 2019-02-04 21:52 ` Thomas Gummerer 2019-02-05 21:17 ` Thomas Gummerer 2019-03-05 12:04 ` Duy Nguyen 2019-03-18 12:51 ` Duy Nguyen 3 siblings, 1 reply; 29+ messages in thread From: Thomas Gummerer @ 2019-02-04 21:52 UTC (permalink / raw) To: Christian Couder Cc: git, Jeff King, Stefan Beller, SZEDER Gábor, Оля Тележная, Matthieu Moy On 02/04, Christian Couder wrote: > Hi everyone, > > There are now ideas, micro-projects and organization application pages > for GSoC 2019 on https://git.github.io/ > > It would be nice to have a few more project ideas. > https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible > projects: Thanks for putting this together. I'm going to have a look at the project list over the next couple of days. > - Unify ref-filter formats with other --pretty formats (which is new) > - git log --oneline improvements > > as I didn't feel that the others were still relevant, though I might be wrong. > > As Olga and Thomas told me at the Git Merge that they could be ok to > co-mentor with me, they are listed as possible mentors for both of > these projects. Yes, I am indeed happy to co-mentor a student with you, or someone else experienced in mentoring. > Anyway feel free to comment and suggest improvements on those pages, > especially the micro-projects and ideas one. Pull requests on > https://github.com/git/git.github.io/ are very much appreciated. > > The application has been submitted on > https://summerofcode.withgoogle.com, but it will not be complete until > someone else volunteers as an org admin. I volunteered, but they > require "at least 2 and at most 5 Organization Administrators". > > So another org admin is needed before Wednesday February 6th, as this > is the deadline. Invitations have been sent to Peff, Thomas, Olga and > Matthieu, but anyone can do it and it requires a very low amount of > work. > > Thanks, > Christian. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-04 21:52 ` Thomas Gummerer @ 2019-02-05 21:17 ` Thomas Gummerer 2019-02-05 22:00 ` Christian Couder 2019-02-06 12:27 ` Johannes Schindelin 0 siblings, 2 replies; 29+ messages in thread From: Thomas Gummerer @ 2019-02-05 21:17 UTC (permalink / raw) To: Christian Couder Cc: git, Jeff King, SZEDER Gábor, Оля Тележная, Matthieu Moy, Johannes Schindelin [Dropped Stefan from the Cc list, as his email bounces] On 02/04, Thomas Gummerer wrote: > On 02/04, Christian Couder wrote: > > It would be nice to have a few more project ideas. > > https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible > > projects: > > Thanks for putting this together. I'm going to have a look at the > project list over the next couple of days. Here's an idea, that I think could make a good GSoC project. Dscho mentioned this to me at Git Merge, and I liked the idea, but I'd like to get some feedback on the list first before adding it to the project list, to get others opinions on the feasibility. The idea is to add an option to 'git stash push', so it can stash merge conflicts, and restore them with 'git stash pop'. The various stages of the files could be represented as commits, and the stash commit would be an octopus merge of those commits, so they could be re-created later. The same idea can also be extended to store staged vs. unstaged changes, so we can re-create the index state as it was before creating the stash. Thoughts? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-05 21:17 ` Thomas Gummerer @ 2019-02-05 22:00 ` Christian Couder 2019-02-06 22:09 ` Thomas Gummerer 2019-02-06 12:27 ` Johannes Schindelin 1 sibling, 1 reply; 29+ messages in thread From: Christian Couder @ 2019-02-05 22:00 UTC (permalink / raw) To: Thomas Gummerer Cc: git, Jeff King, SZEDER Gábor, Оля Тележная, Matthieu Moy, Johannes Schindelin On Tue, Feb 5, 2019 at 10:17 PM Thomas Gummerer <t.gummerer@gmail.com> wrote: > > [Dropped Stefan from the Cc list, as his email bounces] > > On 02/04, Thomas Gummerer wrote: > The idea is to add an option to 'git stash push', so it can stash > merge conflicts, and restore them with 'git stash pop'. The various > stages of the files could be represented as commits, and the stash > commit would be an octopus merge of those commits, so they could be > re-created later. The same idea can also be extended to store staged > vs. unstaged changes, so we can re-create the index state as it was > before creating the stash. > > Thoughts? I think it would be an interesting GSoC project indeed. I think though that over the years we have been favoring refactoring projects over possibly more interesting projects, as the refactoring projects are usually easier to do step by step and to get code merged step by step which is encouraging. In general the refactoring projects are worthwhile to do even if the project is not finished at the end of the GSoC and if the student stops contributing after that. In those cases it is often a good idea to later finish the refactoring either by ourselves or by proposing it to another GSoC student or Outreachy intern. With a project that implements a feature, there is a risk, if it's too complex or too difficult, that the feature will not be finished and that nothing (or nearly nothing) will have been merged during the GSoC. There is also the risk that another way to implement the feature will appear later in the GSoC and all, or nearly all, the work of the student and mentors will have been mostly wasted. It could also appear that the use cases the feature was envisioned to be used in, are better addressed by other improvements or a different workflow. Another potential issue is that a new feature might be prone to naming or user interface discussions which could last for a long time or could not result in clear decisions. So I think we should be very careful if we propose a project that implements a new feature to a student. We should at least consider the above potential issues and see if they can be mitigated before the project starts. Thank you anyway for proposing this idea, Christian. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-05 22:00 ` Christian Couder @ 2019-02-06 22:09 ` Thomas Gummerer 2019-02-07 19:39 ` Johannes Schindelin 0 siblings, 1 reply; 29+ messages in thread From: Thomas Gummerer @ 2019-02-06 22:09 UTC (permalink / raw) To: Christian Couder Cc: git, Jeff King, SZEDER Gábor, Оля Тележная, Matthieu Moy, Johannes Schindelin On 02/05, Christian Couder wrote: > On Tue, Feb 5, 2019 at 10:17 PM Thomas Gummerer <t.gummerer@gmail.com> wrote: > > > > [Dropped Stefan from the Cc list, as his email bounces] > > > > On 02/04, Thomas Gummerer wrote: > > > The idea is to add an option to 'git stash push', so it can stash > > merge conflicts, and restore them with 'git stash pop'. The various > > stages of the files could be represented as commits, and the stash > > commit would be an octopus merge of those commits, so they could be > > re-created later. The same idea can also be extended to store staged > > vs. unstaged changes, so we can re-create the index state as it was > > before creating the stash. > > > > Thoughts? > > I think it would be an interesting GSoC project indeed. I think though > that over the years we have been favoring refactoring projects over > possibly more interesting projects, as the refactoring projects are > usually easier to do step by step and to get code merged step by step > which is encouraging. > > In general the refactoring projects are worthwhile to do even if the > project is not finished at the end of the GSoC and if the student > stops contributing after that. In those cases it is often a good idea > to later finish the refactoring either by ourselves or by proposing it > to another GSoC student or Outreachy intern. > > With a project that implements a feature, there is a risk, if it's too > complex or too difficult, that the feature will not be finished and > that nothing (or nearly nothing) will have been merged during the > GSoC. There is also the risk that another way to implement the feature > will appear later in the GSoC and all, or nearly all, the work of the > student and mentors will have been mostly wasted. It could also appear > that the use cases the feature was envisioned to be used in, are > better addressed by other improvements or a different workflow. Right, it being too complex or too difficult is my main worry here. I don't necessarily agree that we should draw a line between refactoring and feature work here. The more important distinction in my opinion is whether it is possible to implement the project in steps, that individually make sense, and further work could be based on. For example in Paul-Sebastians stash-in-c series (just to take a recent example, that I was following closely), we didn't get anything merged until stash was fully converted into C. We could possibly have merged half of the work, but maybe we would have waited until someone else picks it up before merging anything, I don't know how to judge that now. I think the idea here could definitely be split into a couple different phases, that could be individually useful, and can be merged individually, though I don't know if they would necessarily be. Of the top of my head: - write test_expect_failure tests for the expected new behaviour This may not be worth including in git.git yet, but it can be a very useful starting point for somebody else continuing the feature if the student finds they don't have time for it. - implement pushing the index state, without dealing with conflicts - implement poping the index state, without dealing with conflicts This can already be individually useful, and I think this is something people asked for on the mailing list, though I didn't try digging up old threads for now. After these two steps stashing and restoring a merge conflict would still not work, but we have a good first step that could be merged. - implement pushing/poping conflicted state This would obviously be the end goal. > Another potential issue is that a new feature might be prone to naming > or user interface discussions which could last for a long time or > could not result in clear decisions. Yes, this is definitely a potential pitfall. I haven't thought in depth about the interface yet, but I think the discussion around that would be something we as mentors could and should guide the student through. We also wouldn't make the feature the default from the beginning, but introduce it behind a new flag/maybe a config option, to make sure we don't introduce any backwards compatible changes. It's probably also something the student should include in their proposal, so we can get eyes on it early in the process. > So I think we should be very careful if we propose a project that > implements a new feature to a student. We should at least consider the > above potential issues and see if they can be mitigated before the > project starts. Thanks for bringing these issues up, they are definitely useful to work through. > Thank you anyway for proposing this idea, > Christian. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-06 22:09 ` Thomas Gummerer @ 2019-02-07 19:39 ` Johannes Schindelin 2019-02-07 21:33 ` Thomas Gummerer 0 siblings, 1 reply; 29+ messages in thread From: Johannes Schindelin @ 2019-02-07 19:39 UTC (permalink / raw) To: Thomas Gummerer Cc: Christian Couder, git, Jeff King, SZEDER Gábor, Оля Тележная, Matthieu Moy Hi Thomas, On Wed, 6 Feb 2019, Thomas Gummerer wrote: > I think the idea here could definitely be split into a couple different > phases, that could be individually useful, and can be merged > individually, though I don't know if they would necessarily be. Good idea. > Of the top of my head: > > - write test_expect_failure tests for the expected new behaviour > > This may not be worth including in git.git yet, but it can be a > very useful starting point for somebody else continuing the feature > if the student finds they don't have time for it. I like this approach. > - implement pushing the index state, without dealing with conflicts > - implement poping the index state, without dealing with conflicts > > This can already be individually useful, and I think this is > something people asked for on the mailing list, though I didn't try > digging up old threads for now. After these two steps stashing and > restoring a merge conflict would still not work, but we have a good > first step that could be merged. We already have `git stash --keep-index`. Is this what you mean here? > - implement pushing/poping conflicted state > > This would obviously be the end goal. On second thought, this might actually be super trivial. Right now, we support two modes (not counting the `--untracked` stuff): --keep-index and --no-keep-index. In both cases, we seem to create a merge commit whose tree reflects the working directory and whose first parent is HEAD and whose second parent is a single commit on top of HEAD (which contains either no changes in the case of --no-keep-index, or whose tree reflects the index in case of --keep-index). To extend that to the conflict case, we could introduce a new flag --with-conflicts, and have the commit structure Worktree | \ | index stage 0 | / | \ | stage 1 stage 2 stage 3 | / / / HEAD --------------- The only tricky thing I can see is to maintain backwards compatibility if possible, so that old `git stash` will do something at least semi-sensible with those commit structures. It might be too small a project, after all. Ciao, Dscho > > Another potential issue is that a new feature might be prone to naming > > or user interface discussions which could last for a long time or > > could not result in clear decisions. > > Yes, this is definitely a potential pitfall. I haven't thought in > depth about the interface yet, but I think the discussion around that > would be something we as mentors could and should guide the student > through. We also wouldn't make the feature the default from the > beginning, but introduce it behind a new flag/maybe a config option, > to make sure we don't introduce any backwards compatible changes. > > It's probably also something the student should include in their > proposal, so we can get eyes on it early in the process. > > > So I think we should be very careful if we propose a project that > > implements a new feature to a student. We should at least consider the > > above potential issues and see if they can be mitigated before the > > project starts. > > Thanks for bringing these issues up, they are definitely useful to > work through. > > > Thank you anyway for proposing this idea, > > Christian. > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-07 19:39 ` Johannes Schindelin @ 2019-02-07 21:33 ` Thomas Gummerer 2019-02-11 5:41 ` Оля Тележная 2019-02-11 8:35 ` Christian Couder 0 siblings, 2 replies; 29+ messages in thread From: Thomas Gummerer @ 2019-02-07 21:33 UTC (permalink / raw) To: Johannes Schindelin Cc: Christian Couder, git, Jeff King, SZEDER Gábor, Оля Тележная, Matthieu Moy On 02/07, Johannes Schindelin wrote: > Hi Thomas, > > On Wed, 6 Feb 2019, Thomas Gummerer wrote: > > - implement pushing the index state, without dealing with conflicts > > - implement poping the index state, without dealing with conflicts > > > > This can already be individually useful, and I think this is > > something people asked for on the mailing list, though I didn't try > > digging up old threads for now. After these two steps stashing and > > restoring a merge conflict would still not work, but we have a good > > first step that could be merged. > > We already have `git stash --keep-index`. Is this what you mean here? `git stash --keep-index` does something different, what I meant here was what `git stash pop --index` already does. I had forgotten that this functionality already exists. > > - implement pushing/poping conflicted state > > > > This would obviously be the end goal. > > On second thought, this might actually be super trivial. Right now, we > support two modes (not counting the `--untracked` stuff): --keep-index and > --no-keep-index. In both cases, we seem to create a merge commit whose > tree reflects the working directory and whose first parent is HEAD and > whose second parent is a single commit on top of HEAD (which contains > either no changes in the case of --no-keep-index, or whose tree reflects > the index in case of --keep-index). > > To extend that to the conflict case, we could introduce a new flag > --with-conflicts, and have the commit structure > > Worktree > | \ > | index stage 0 > | / | \ > | stage 1 stage 2 stage 3 > | / / / > HEAD --------------- > > The only tricky thing I can see is to maintain backwards compatibility if > possible, so that old `git stash` will do something at least semi-sensible > with those commit structures. > > It might be too small a project, after all. Yeah, looking at this I think you're right. Thanks for helping work through this. > Ciao, > Dscho ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-07 21:33 ` Thomas Gummerer @ 2019-02-11 5:41 ` Оля Тележная 2019-02-11 7:45 ` Christian Couder 2019-02-13 22:36 ` Elijah Newren 2019-02-11 8:35 ` Christian Couder 1 sibling, 2 replies; 29+ messages in thread From: Оля Тележная @ 2019-02-11 5:41 UTC (permalink / raw) To: Thomas Gummerer Cc: Johannes Schindelin, Christian Couder, git, Jeff King, SZEDER Gábor, Matthieu Moy > It would be nice to have a few more project ideas. I am not sure I have additional ideas for 3-month project for the intern, but > https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible > projects: > > - Unify ref-filter formats with other --pretty formats (which is new) I am ready to act as a mentor in this task, I know that part of project good enough. I have additional related task: We have a function called oid_object_info, it allows to download meta-info of the file. It was used in cat-file, and inspired by that example, I improved ref-filter, so now ref-filter works faster with it. Moreover, I have found that oid_object_info allows to get the contents of the file. It was useful in ref-filter, and actually it could be also useful in cat-file, but we still download the file differently in cat-file, and it looks awkward. I need to make just one last move to finish my patch: it will close the task about migrating cat-file formatting logic to ref-filter. But cat-file still will not use general way to download the file. So, the task is to get rid of additional file-reading logic. I guess this task is much smaller than original one, but at least the student will have chance to finish it in 3 months. My patch is here: https://github.com/git/git/pull/568 But I hope you will also see it this week in the mailing list. Proposed task is in TODO in the end of ref-filter file. By the way, we had a letter from Google, it is said that our tasks are sparsed. I am not sure I understand it correctly. Should I help the project somehow to solve our issues? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-11 5:41 ` Оля Тележная @ 2019-02-11 7:45 ` Christian Couder 2019-02-11 8:31 ` Оля Тележная 2019-02-13 22:36 ` Elijah Newren 1 sibling, 1 reply; 29+ messages in thread From: Christian Couder @ 2019-02-11 7:45 UTC (permalink / raw) To: Оля Тележная Cc: Thomas Gummerer, Johannes Schindelin, git, Jeff King, SZEDER Gábor, Matthieu Moy On Mon, Feb 11, 2019 at 6:48 AM Оля Тележная <olyatelezhnaya@gmail.com> wrote: > > > It would be nice to have a few more project ideas. > > I am not sure I have additional ideas for 3-month project for the intern, but > > > https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible > > projects: > > > > - Unify ref-filter formats with other --pretty formats (which is new) > > I am ready to act as a mentor in this task, I know that part of > project good enough. Great! I thought that it would be a good project for you to mentor and that's why I added it. By the way if you would prefer not to mentor the other project I can remove you from its possible mentor list. > I have additional related task: We have a function called > oid_object_info, it allows to download meta-info of the file. It was > used in cat-file, and inspired by that example, I improved ref-filter, > so now ref-filter works faster with it. Moreover, I have found that > oid_object_info allows to get the contents of the file. It was useful > in ref-filter, and actually it could be also useful in cat-file, but > we still download the file differently in cat-file, and it looks > awkward. I need to make just one last move to finish my patch: it will > close the task about migrating cat-file formatting logic to > ref-filter. But cat-file still will not use general way to download > the file. So, the task is to get rid of additional file-reading logic. > I guess this task is much smaller than original one, but at least the > student will have chance to finish it in 3 months. > My patch is here: https://github.com/git/git/pull/568 > But I hope you will also see it this week in the mailing list. > Proposed task is in TODO in the end of ref-filter file. Do you mean the following comment from https://github.com/git/git/blob/c17ed82b8983ea7e172181d869966db546c6a528/ref-filter.c#L2393-L2399: /* * TODO: add support of %(*raw). Need to switch between oi and oi_deref for that. * TODO: split logic and printing (as it is done in format_ref_array_item and * show_ref_array_item). After that we could use %(raw) in all ref-filter commands. * TODO: rewrite print_object_or_die so that it will reuse result of general * oid_object_info_extended call. */ ? It doesn't look like that's it. Could you just copy the task into an email? Or if you think it could be an idea for a GSoC project, could you send a pull request to add it to: https://github.com/git/git.github.io/blob/master/SoC-2019-Ideas.md ? > By the way, we had a letter from Google, it is said that our tasks are > sparsed. I am not sure I understand it correctly. Should I help the > project somehow to solve our issues? Yeah, we got en email from Stephanie Taylor saying that our idea list is quite sparse this year with a link to: https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list which contains: "Even if you are a new organization and only want one or two students showing that you have multiple ideas (a bare minimum of 4 solid ideas) is vital." They also want "more detailed description of [each] project (2-5 sentences)", so I think we should work on that too. So yeah, any help to fix the idea list is very welcome! Thanks, Christian. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-11 7:45 ` Christian Couder @ 2019-02-11 8:31 ` Оля Тележная 2019-02-11 10:52 ` Christian Couder 0 siblings, 1 reply; 29+ messages in thread From: Оля Тележная @ 2019-02-11 8:31 UTC (permalink / raw) To: Christian Couder Cc: Thomas Gummerer, Johannes Schindelin, git, Jeff King, SZEDER Gábor, Matthieu Moy пн, 11 февр. 2019 г. в 10:46, Christian Couder <christian.couder@gmail.com>: > > On Mon, Feb 11, 2019 at 6:48 AM Оля Тележная <olyatelezhnaya@gmail.com> wrote: > > > > > It would be nice to have a few more project ideas. > > > > I am not sure I have additional ideas for 3-month project for the intern, but > > > > > https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible > > > projects: > > > > > > - Unify ref-filter formats with other --pretty formats (which is new) > > > > I am ready to act as a mentor in this task, I know that part of > > project good enough. > > Great! I thought that it would be a good project for you to mentor and > that's why I added it. > > By the way if you would prefer not to mentor the other project I can > remove you from its possible mentor list. I am ready to try mentoring on both projects, but it would be much easier for me to work only for this one. I removed my name from the other one and made pull request: https://github.com/git/git.github.io/pull/355 If project about pretty will not be selected by any of the students, I am happy to help other mentors with other projects. > > > I have additional related task: We have a function called > > oid_object_info, it allows to download meta-info of the file. It was > > used in cat-file, and inspired by that example, I improved ref-filter, > > so now ref-filter works faster with it. Moreover, I have found that > > oid_object_info allows to get the contents of the file. It was useful > > in ref-filter, and actually it could be also useful in cat-file, but > > we still download the file differently in cat-file, and it looks > > awkward. I need to make just one last move to finish my patch: it will > > close the task about migrating cat-file formatting logic to > > ref-filter. But cat-file still will not use general way to download > > the file. So, the task is to get rid of additional file-reading logic. > > I guess this task is much smaller than original one, but at least the > > student will have chance to finish it in 3 months. > > My patch is here: https://github.com/git/git/pull/568 > > But I hope you will also see it this week in the mailing list. > > Proposed task is in TODO in the end of ref-filter file. > > Do you mean the following comment from > https://github.com/git/git/blob/c17ed82b8983ea7e172181d869966db546c6a528/ref-filter.c#L2393-L2399: > > /* > * TODO: add support of %(*raw). Need to switch between oi and oi_deref for that. > * TODO: split logic and printing (as it is done in format_ref_array_item and > * show_ref_array_item). After that we could use %(raw) in all > ref-filter commands. > * TODO: rewrite print_object_or_die so that it will reuse result of general > * oid_object_info_extended call. > */ > > ? > > It doesn't look like that's it. Could you just copy the task into an > email? Or if you think it could be an idea for a GSoC project, could > you send a pull request to add it to: > > https://github.com/git/git.github.io/blob/master/SoC-2019-Ideas.md > > ? Yes, that's it. Particularly, the last TODO. But other TODOs will be also solved as a result. I can add it to the list of the projects if you find this task suitable. > > > By the way, we had a letter from Google, it is said that our tasks are > > sparsed. I am not sure I understand it correctly. Should I help the > > project somehow to solve our issues? > > Yeah, we got en email from Stephanie Taylor saying that our idea list > is quite sparse this year with a link to: > > https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list > > which contains: > > "Even if you are a new organization and only want one or two students > showing that you have multiple ideas (a bare minimum of 4 solid ideas) > is vital." > > They also want "more detailed description of [each] project (2-5 > sentences)", so I think we should work on that too. I added description for one of projects, it is also in my pull request. > > So yeah, any help to fix the idea list is very welcome! > > Thanks, > Christian. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-11 8:31 ` Оля Тележная @ 2019-02-11 10:52 ` Christian Couder 0 siblings, 0 replies; 29+ messages in thread From: Christian Couder @ 2019-02-11 10:52 UTC (permalink / raw) To: Оля Тележная Cc: Thomas Gummerer, Johannes Schindelin, git, Jeff King, SZEDER Gábor, Matthieu Moy On Mon, Feb 11, 2019 at 9:39 AM Оля Тележная <olyatelezhnaya@gmail.com> wrote: > > пн, 11 февр. 2019 г. в 10:46, Christian Couder <christian.couder@gmail.com>: > > > > On Mon, Feb 11, 2019 at 6:48 AM Оля Тележная <olyatelezhnaya@gmail.com> wrote: > > > > - Unify ref-filter formats with other --pretty formats (which is new) > > > > > > I am ready to act as a mentor in this task, I know that part of > > > project good enough. > > > > Great! I thought that it would be a good project for you to mentor and > > that's why I added it. > > > > By the way if you would prefer not to mentor the other project I can > > remove you from its possible mentor list. > > I am ready to try mentoring on both projects, but it would be much > easier for me to work only for this one. I removed my name from the > other one and made pull request: > https://github.com/git/git.github.io/pull/355 Great, merged! > If project about pretty will not be selected by any of the students, I > am happy to help other mentors with other projects. Ok, we will see. > > Do you mean the following comment from > > https://github.com/git/git/blob/c17ed82b8983ea7e172181d869966db546c6a528/ref-filter.c#L2393-L2399: > > > > /* > > * TODO: add support of %(*raw). Need to switch between oi and oi_deref for that. > > * TODO: split logic and printing (as it is done in format_ref_array_item and > > * show_ref_array_item). After that we could use %(raw) in all > > ref-filter commands. > > * TODO: rewrite print_object_or_die so that it will reuse result of general > > * oid_object_info_extended call. > > */ > > > > ? > > > > It doesn't look like that's it. Could you just copy the task into an > > email? Or if you think it could be an idea for a GSoC project, could > > you send a pull request to add it to: > > > > https://github.com/git/git.github.io/blob/master/SoC-2019-Ideas.md > > > > ? > > Yes, that's it. Particularly, the last TODO. But other TODOs will be > also solved as a result. I can add it to the list of the projects if > you find this task suitable. I think it is ok if we propose that task first and then the "Unify ref-filter formats with other --pretty formats" project in case the student finishes the first task soon. Or do you see other tasks for a student after this? Anyway I don't think we should have both one student working on the "Unify ref-filter formats with other --pretty formats" project and another one on this task. But yeah, if you want, feel free to send a pull request to add it with the above caveats. > > They also want "more detailed description of [each] project (2-5 > > sentences)", so I think we should work on that too. > > I added description for one of projects, it is also in my pull request. Thanks, Christian. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-11 5:41 ` Оля Тележная 2019-02-11 7:45 ` Christian Couder @ 2019-02-13 22:36 ` Elijah Newren 2019-02-14 9:48 ` Christian Couder 1 sibling, 1 reply; 29+ messages in thread From: Elijah Newren @ 2019-02-13 22:36 UTC (permalink / raw) To: Оля Тележная Cc: Thomas Gummerer, Johannes Schindelin, Christian Couder, git, Jeff King, SZEDER Gábor, Matthieu Moy On Sun, Feb 10, 2019 at 9:51 PM Оля Тележная <olyatelezhnaya@gmail.com> wrote: > > > It would be nice to have a few more project ideas. > > I am not sure I have additional ideas for 3-month project for the intern, but > > > https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible > > projects: > > > > - Unify ref-filter formats with other --pretty formats (which is new) > > I am ready to act as a mentor in this task, I know that part of > project good enough. > I have additional related task: We have a function called > oid_object_info, it allows to download meta-info of the file. It was > used in cat-file, and inspired by that example, I improved ref-filter, > so now ref-filter works faster with it. Moreover, I have found that > oid_object_info allows to get the contents of the file. It was useful > in ref-filter, and actually it could be also useful in cat-file, but > we still download the file differently in cat-file, and it looks > awkward. I need to make just one last move to finish my patch: it will > close the task about migrating cat-file formatting logic to > ref-filter. But cat-file still will not use general way to download > the file. So, the task is to get rid of additional file-reading logic. > I guess this task is much smaller than original one, but at least the > student will have chance to finish it in 3 months. > My patch is here: https://github.com/git/git/pull/568 > But I hope you will also see it this week in the mailing list. > Proposed task is in TODO in the end of ref-filter file. > > By the way, we had a letter from Google, it is said that our tasks are > sparsed. I am not sure I understand it correctly. Should I help the > project somehow to solve our issues? I'm a little hesitant to suggest this as I'm not sure how available I could be for mentoring and don't view myself as a good mentor, but another project idea which has lots of sub-pieces and thus could show progress and be useful even if not everything is completed: Consistency of sequencer commands: * The suggestion to fix an interrupted rebase-i or cherry-pick due to a commit that became empty via 'git reset HEAD' (in builtin/commit.c) instead of 'git rebase --skip' or 'git cherry-pick --skip' ranges from annoying to confusing. (Especially since other interrupted am's and rebases both point to am/rebase --skip.). Note that 'git cherry-pick --skip' is not yet implemented, so that would have to be added first. * There are a handful of flags that am-based rebases support that are not available to interactive/merge-based rebases; it'd be nice to implement them for the interactive machinery. (There are also numerous flags that only the interactive machinery supports that are unavailable to am-based rebases, but I don't care; I want to deprecate am-based rebases.) * --ignore-whitespace (transliterate to -Xignore-space-change?) * --whitespace=... * --committer-date-is-author-date/--ignore-date * -C4 [There's also some empty handling (from "Behavioral Differences" in Documentation/git-rebase.txt) that would be nice to address, though that might be contentious and I might try to tackle that piece before GSoC gets rolling...] Bonus: Make a flag to allow rebase to rewrite commit messages that refer to older commits that were also rebased. (i.e. if rebasing commits A and B, and commit B says "This reverts commit <sha-of-A>, then rewritten B's commit message should say "This reverts commit <sha-of-rewritten-A".) Do this for both sha1sums and sha1sum abbreviations in commit messages. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-13 22:36 ` Elijah Newren @ 2019-02-14 9:48 ` Christian Couder 0 siblings, 0 replies; 29+ messages in thread From: Christian Couder @ 2019-02-14 9:48 UTC (permalink / raw) To: Elijah Newren Cc: Оля Тележная, Thomas Gummerer, Johannes Schindelin, git, Jeff King, SZEDER Gábor, Matthieu Moy On Wed, Feb 13, 2019 at 11:37 PM Elijah Newren <newren@gmail.com> wrote: > > I'm a little hesitant to suggest this as I'm not sure how available I > could be for mentoring and don't view myself as a good mentor, but > another project idea which has lots of sub-pieces and thus could show > progress and be useful even if not everything is completed: > > Consistency of sequencer commands: ... Thanks! I like this idea, as it indeed consists in multiple tasks that could be worked on independently. Also 2 previous GSoC students already worked on the sequencer (in 2008 and 2010 IIRC), and I think Alban has been working on it too, so it would be nice if another one worked on completing that work. I added it to the Idea page. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-07 21:33 ` Thomas Gummerer 2019-02-11 5:41 ` Оля Тележная @ 2019-02-11 8:35 ` Christian Couder 2019-02-11 22:18 ` Thomas Gummerer 1 sibling, 1 reply; 29+ messages in thread From: Christian Couder @ 2019-02-11 8:35 UTC (permalink / raw) To: Thomas Gummerer Cc: Johannes Schindelin, git, Jeff King, SZEDER Gábor, Оля Тележная, Matthieu Moy On Thu, Feb 7, 2019 at 10:33 PM Thomas Gummerer <t.gummerer@gmail.com> wrote: > > On 02/07, Johannes Schindelin wrote: > > On Wed, 6 Feb 2019, Thomas Gummerer wrote: > > > - implement pushing/poping conflicted state > > > > > > This would obviously be the end goal. > > > > On second thought, this might actually be super trivial. Right now, we > > support two modes (not counting the `--untracked` stuff): --keep-index and > > --no-keep-index. In both cases, we seem to create a merge commit whose > > tree reflects the working directory and whose first parent is HEAD and > > whose second parent is a single commit on top of HEAD (which contains > > either no changes in the case of --no-keep-index, or whose tree reflects > > the index in case of --keep-index). > > > > To extend that to the conflict case, we could introduce a new flag > > --with-conflicts, and have the commit structure > > > > Worktree > > | \ > > | index stage 0 > > | / | \ > > | stage 1 stage 2 stage 3 > > | / / / > > HEAD --------------- > > > > The only tricky thing I can see is to maintain backwards compatibility if > > possible, so that old `git stash` will do something at least semi-sensible > > with those commit structures. > > > > It might be too small a project, after all. > > Yeah, looking at this I think you're right. Thanks for helping work > through this. I am not sure it will be too small a project, especially because it is a new feature. On top of the coding part, the student will also have to come up with good documentation and test cases, and there will probably be naming and workflow discussions and possibly refactoring opportunities and bug fixes along the way. Yeah, the naming and workflow discussions should actually happen when discussing the student's proposal, in which case an important part of the work will (hopefully) be done before the GSoC actually starts. Historically though we have always been very optimistic in what we thought a student could accomplish in a GSoC. And we are very likely to find more ideas for improvements during the GSoC, in case everything is "finished" before the end. I actually think that it has never happened that a student both "finished" the project before the end, and that no idea for improvement on top of the work was found. I have added a "Note about refactoring projects versus projects that implement new features" at the end of the idea list: https://github.com/git/git.github.io/blob/master/SoC-2019-Ideas.md#note-about-refactoring-projects-versus-projects-that-implement-new-features and I think that with that note students working on such projects will be warned enough, and therefore hopefully have a better chance of success. So after all if you are willing to co-mentor such a project, I would be ok to co-mentor it with you, and we should add it to the list. Thanks, Christian. And yeah it would help improve our idea list as requested by Google. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-11 8:35 ` Christian Couder @ 2019-02-11 22:18 ` Thomas Gummerer 2019-02-11 23:58 ` Christian Couder 0 siblings, 1 reply; 29+ messages in thread From: Thomas Gummerer @ 2019-02-11 22:18 UTC (permalink / raw) To: Christian Couder Cc: Johannes Schindelin, git, Jeff King, SZEDER Gábor, Оля Тележная, Matthieu Moy On 02/11, Christian Couder wrote: > On Thu, Feb 7, 2019 at 10:33 PM Thomas Gummerer <t.gummerer@gmail.com> wrote: > > > > On 02/07, Johannes Schindelin wrote: > > > On Wed, 6 Feb 2019, Thomas Gummerer wrote: > > > > - implement pushing/poping conflicted state > > > > > > > > This would obviously be the end goal. > > > > > > On second thought, this might actually be super trivial. Right now, we > > > support two modes (not counting the `--untracked` stuff): --keep-index and > > > --no-keep-index. In both cases, we seem to create a merge commit whose > > > tree reflects the working directory and whose first parent is HEAD and > > > whose second parent is a single commit on top of HEAD (which contains > > > either no changes in the case of --no-keep-index, or whose tree reflects > > > the index in case of --keep-index). > > > > > > To extend that to the conflict case, we could introduce a new flag > > > --with-conflicts, and have the commit structure > > > > > > Worktree > > > | \ > > > | index stage 0 > > > | / | \ > > > | stage 1 stage 2 stage 3 > > > | / / / > > > HEAD --------------- > > > > > > The only tricky thing I can see is to maintain backwards compatibility if > > > possible, so that old `git stash` will do something at least semi-sensible > > > with those commit structures. > > > > > > It might be too small a project, after all. > > > > Yeah, looking at this I think you're right. Thanks for helping work > > through this. > > I am not sure it will be too small a project, especially because it is > a new feature. On top of the coding part, the student will also have > to come up with good documentation and test cases, and there will > probably be naming and workflow discussions and possibly refactoring > opportunities and bug fixes along the way. I still think it's on the smaller side, but also as you mention below we have usually been rather optimistic about project sizes. So maybe this is the right size for a GSoC after all. > Yeah, the naming and workflow discussions should actually happen when > discussing the student's proposal, in which case an important part of > the work will (hopefully) be done before the GSoC actually starts. > > Historically though we have always been very optimistic in what we > thought a student could accomplish in a GSoC. And we are very likely > to find more ideas for improvements during the GSoC, in case > everything is "finished" before the end. I actually think that it has > never happened that a student both "finished" the project before the > end, and that no idea for improvement on top of the work was found. Fair enough. I think there's still a number of things that could do with some refactoring in 'builtin/stash.c', e.g. use more of the libgit.a API, instead of using the run_command API, or potentially other improvements that could be made. Another thing that may be useful to do is to write down some actual technical documentation on the format of what a stash commit looks like. > I have added a "Note about refactoring projects versus projects that > implement new features" at the end of the idea list: > > https://github.com/git/git.github.io/blob/master/SoC-2019-Ideas.md#note-about-refactoring-projects-versus-projects-that-implement-new-features > > and I think that with that note students working on such projects will > be warned enough, and therefore hopefully have a better chance of > success. > > So after all if you are willing to co-mentor such a project, I would > be ok to co-mentor it with you, and we should add it to the list. Ok, I'll submit a PR to add it to the list. > Thanks, > Christian. > > And yeah it would help improve our idea list as requested by Google. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-11 22:18 ` Thomas Gummerer @ 2019-02-11 23:58 ` Christian Couder 2019-02-12 20:25 ` Thomas Gummerer 0 siblings, 1 reply; 29+ messages in thread From: Christian Couder @ 2019-02-11 23:58 UTC (permalink / raw) To: Thomas Gummerer Cc: Johannes Schindelin, git, Jeff King, SZEDER Gábor, Оля Тележная, Matthieu Moy On Mon, Feb 11, 2019 at 11:18 PM Thomas Gummerer <t.gummerer@gmail.com> wrote: > > On 02/11, Christian Couder wrote: > > Historically though we have always been very optimistic in what we > > thought a student could accomplish in a GSoC. And we are very likely > > to find more ideas for improvements during the GSoC, in case > > everything is "finished" before the end. I actually think that it has > > never happened that a student both "finished" the project before the > > end, and that no idea for improvement on top of the work was found. > > Fair enough. I think there's still a number of things that could do > with some refactoring in 'builtin/stash.c', e.g. use more of the > libgit.a API, instead of using the run_command API, or potentially > other improvements that could be made. > > Another thing that may be useful to do is to write down some actual > technical documentation on the format of what a stash commit looks > like. Yeah, using more of the libgit.a API, instead of the run_command API, and writing technical documentation on the stash commit format look like good ideas to me. I think I will add those items to the project description if you don't mind. > > So after all if you are willing to co-mentor such a project, I would > > be ok to co-mentor it with you, and we should add it to the list. > > Ok, I'll submit a PR to add it to the list. Great! I merged your PR. I also resurrected the "Convert scripts to builtins" idea as I think there might still be shell scripts that could be converted, like perhaps git-merge-octopus.sh, git-merge-one-file.sh and git-merge-resolve.sh. So I think we should be good regarding Google requirements. Thanks, Christian. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-11 23:58 ` Christian Couder @ 2019-02-12 20:25 ` Thomas Gummerer 2019-02-12 20:49 ` Christian Couder 0 siblings, 1 reply; 29+ messages in thread From: Thomas Gummerer @ 2019-02-12 20:25 UTC (permalink / raw) To: Christian Couder Cc: Johannes Schindelin, git, Jeff King, SZEDER Gábor, Оля Тележная, Matthieu Moy On 02/12, Christian Couder wrote: > On Mon, Feb 11, 2019 at 11:18 PM Thomas Gummerer <t.gummerer@gmail.com> wrote: > > > > On 02/11, Christian Couder wrote: > > > > Historically though we have always been very optimistic in what we > > > thought a student could accomplish in a GSoC. And we are very likely > > > to find more ideas for improvements during the GSoC, in case > > > everything is "finished" before the end. I actually think that it has > > > never happened that a student both "finished" the project before the > > > end, and that no idea for improvement on top of the work was found. > > > > Fair enough. I think there's still a number of things that could do > > with some refactoring in 'builtin/stash.c', e.g. use more of the > > libgit.a API, instead of using the run_command API, or potentially > > other improvements that could be made. > > > > Another thing that may be useful to do is to write down some actual > > technical documentation on the format of what a stash commit looks > > like. > > Yeah, using more of the libgit.a API, instead of the run_command API, > and writing technical documentation on the stash commit format look > like good ideas to me. I think I will add those items to the project > description if you don't mind. Sure that sounds good, thanks! I think using more of the libgit.a API should probably be an optional endeavor, but writing the technical documentation may be a good thing to include in the project. > > > So after all if you are willing to co-mentor such a project, I would > > > be ok to co-mentor it with you, and we should add it to the list. > > > > Ok, I'll submit a PR to add it to the list. > > Great! I merged your PR. > > I also resurrected the "Convert scripts to builtins" idea as I think > there might still be shell scripts that could be converted, like > perhaps git-merge-octopus.sh, git-merge-one-file.sh and > git-merge-resolve.sh. These all look quite small, but yeah perhaps converting a few of them over the course of the summer might be an alright project. > So I think we should be good regarding Google requirements. > > Thanks, > Christian. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-12 20:25 ` Thomas Gummerer @ 2019-02-12 20:49 ` Christian Couder 2019-02-12 22:13 ` Thomas Gummerer 0 siblings, 1 reply; 29+ messages in thread From: Christian Couder @ 2019-02-12 20:49 UTC (permalink / raw) To: Thomas Gummerer Cc: Johannes Schindelin, git, Jeff King, SZEDER Gábor, Оля Тележная, Matthieu Moy On Tue, Feb 12, 2019 at 9:25 PM Thomas Gummerer <t.gummerer@gmail.com> wrote: > > On 02/12, Christian Couder wrote: > > Yeah, using more of the libgit.a API, instead of the run_command API, > > and writing technical documentation on the stash commit format look > > like good ideas to me. I think I will add those items to the project > > description if you don't mind. > > Sure that sounds good, thanks! I think using more of the libgit.a API > should probably be an optional endeavor, but writing the technical > documentation may be a good thing to include in the project. Ok, there is now the following at the end of the idea: "This will include writing the technical documentation of the stash format, and optionally refactoring the `git stash` code to use more of the libgit.a API, instead of the run_command API." ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-12 20:49 ` Christian Couder @ 2019-02-12 22:13 ` Thomas Gummerer 0 siblings, 0 replies; 29+ messages in thread From: Thomas Gummerer @ 2019-02-12 22:13 UTC (permalink / raw) To: Christian Couder Cc: Johannes Schindelin, git, Jeff King, SZEDER Gábor, Оля Тележная, Matthieu Moy On 02/12, Christian Couder wrote: > On Tue, Feb 12, 2019 at 9:25 PM Thomas Gummerer <t.gummerer@gmail.com> wrote: > > > > On 02/12, Christian Couder wrote: > > > > Yeah, using more of the libgit.a API, instead of the run_command API, > > > and writing technical documentation on the stash commit format look > > > like good ideas to me. I think I will add those items to the project > > > description if you don't mind. > > > > Sure that sounds good, thanks! I think using more of the libgit.a API > > should probably be an optional endeavor, but writing the technical > > documentation may be a good thing to include in the project. > > Ok, there is now the following at the end of the idea: > > "This will include writing the technical documentation of the stash > format, and optionally refactoring the `git stash` code to use more of > the libgit.a API, instead of the run_command API." Thanks, this sounds good to me. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-05 21:17 ` Thomas Gummerer 2019-02-05 22:00 ` Christian Couder @ 2019-02-06 12:27 ` Johannes Schindelin 1 sibling, 0 replies; 29+ messages in thread From: Johannes Schindelin @ 2019-02-06 12:27 UTC (permalink / raw) To: Thomas Gummerer Cc: Christian Couder, git, Jeff King, SZEDER Gábor, Оля Тележная, Matthieu Moy Hi Thomas, On Tue, 5 Feb 2019, Thomas Gummerer wrote: > Here's an idea, that I think could make a good GSoC project. Dscho > mentioned this to me at Git Merge, and I liked the idea, but I'd like to > get some feedback on the list first before adding it to the project > list, to get others opinions on the feasibility. > > The idea is to add an option to 'git stash push', so it can stash merge > conflicts, and restore them with 'git stash pop'. The various stages of > the files could be represented as commits, and the stash commit would be > an octopus merge of those commits, so they could be re-created later. > The same idea can also be extended to store staged vs. unstaged changes, > so we can re-create the index state as it was before creating the stash. > > Thoughts? Yep, would make for a good GSoC project, as it is straight-forward to implement and easy to structure, there is no exploratory work needed. Ciao, Dscho ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-04 9:16 GSoC 2019: Git's application submitted Christian Couder [not found] ` <CAL21Bm=K6zZ=APkiP3A_X7xVoOfx-MY2435YMp5y1ztE-xyYtg@mail.gmail.com> 2019-02-04 21:52 ` Thomas Gummerer @ 2019-03-05 12:04 ` Duy Nguyen 2019-03-05 12:23 ` Duy Nguyen 2019-03-06 4:49 ` Jeff King 2019-03-18 12:51 ` Duy Nguyen 3 siblings, 2 replies; 29+ messages in thread From: Duy Nguyen @ 2019-03-05 12:04 UTC (permalink / raw) To: Christian Couder Cc: git, Jeff King, Stefan Beller, SZEDER Gábor, Thomas Gummerer, Оля Тележная, Matthieu Moy On Mon, Feb 4, 2019 at 4:17 PM Christian Couder <christian.couder@gmail.com> wrote: > > Hi everyone, > > There are now ideas, micro-projects and organization application pages > for GSoC 2019 on https://git.github.io/ > > It would be nice to have a few more project ideas. Not sure if it's too late now. Anyway this could be something fun to do: support C-based tests in our test suite. A while back I noticed some test running very long because it was trying a lot of input combination. The actual logic is not much, but because of the increasing number of test cases, overhead goes off the roof. The last part is probably not true, but Windows port I think is hit much harder than what I experience, and I think Dscho did complain about it. So what this project does is somehow allow people to write test cases in C instead of shell. Imagine replacing t3070-wildmatch.sh with a binary program t3070-wildmatch that behaves the same way. This test framework needs to support the same basic feature set as test-lib.sh: TAP output, test results summary, maybe -i and --valgrind... To demonstrate that the test framework works, one of these long test files should be rewritten in C. I'm sure there's one that is simple to rewrite. I'm pretty sure I had some fun with this idea and made some prototype but I couldn't find it. If I do, I'll post the link here. -- Duy ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-03-05 12:04 ` Duy Nguyen @ 2019-03-05 12:23 ` Duy Nguyen 2019-03-06 4:49 ` Jeff King 1 sibling, 0 replies; 29+ messages in thread From: Duy Nguyen @ 2019-03-05 12:23 UTC (permalink / raw) To: Christian Couder Cc: git, Jeff King, SZEDER Gábor, Thomas Gummerer, Оля Тележная, Matthieu Moy On Tue, Mar 5, 2019 at 7:04 PM Duy Nguyen <pclouds@gmail.com> wrote: > Not sure if it's too late now. Anyway this could be something fun to > do: support C-based tests in our test suite. > > ... > > I'm pretty sure I had some fun with this idea and made some prototype > but I couldn't find it. If I do, I'll post the link here. Found it. Far from complete, but it gives a general direction I hope https://public-inbox.org/git/20180110090724.GA2893@ash/ -- Duy ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-03-05 12:04 ` Duy Nguyen 2019-03-05 12:23 ` Duy Nguyen @ 2019-03-06 4:49 ` Jeff King 2019-03-06 9:36 ` Duy Nguyen 2019-03-06 14:16 ` Johannes Schindelin 1 sibling, 2 replies; 29+ messages in thread From: Jeff King @ 2019-03-06 4:49 UTC (permalink / raw) To: Duy Nguyen Cc: Christian Couder, git, Stefan Beller, SZEDER Gábor, Thomas Gummerer, Оля Тележная, Matthieu Moy On Tue, Mar 05, 2019 at 07:04:59PM +0700, Duy Nguyen wrote: > On Mon, Feb 4, 2019 at 4:17 PM Christian Couder > <christian.couder@gmail.com> wrote: > > > > Hi everyone, > > > > There are now ideas, micro-projects and organization application pages > > for GSoC 2019 on https://git.github.io/ > > > > It would be nice to have a few more project ideas. > > Not sure if it's too late now. Anyway this could be something fun to > do: support C-based tests in our test suite. > > A while back I noticed some test running very long because it was > trying a lot of input combination. The actual logic is not much, but > because of the increasing number of test cases, overhead goes off the > roof. The last part is probably not true, but Windows port I think is > hit much harder than what I experience, and I think Dscho did complain > about it. > > So what this project does is somehow allow people to write test cases > in C instead of shell. Imagine replacing t3070-wildmatch.sh with a > binary program t3070-wildmatch that behaves the same way. This test > framework needs to support the same basic feature set as test-lib.sh: > TAP output, test results summary, maybe -i and --valgrind... To > demonstrate that the test framework works, one of these long test > files should be rewritten in C. I'm sure there's one that is simple to > rewrite. > > I'm pretty sure I had some fun with this idea and made some prototype > but I couldn't find it. If I do, I'll post the link here. In my experience, it's nicer to have a tool written in C that can be driven by arbitrary input. That makes it easy to write new test cases, because you just have to write in some easy domain-specific format instead of embedding the test data in C code. And many of our tests do work like that (in fact, many of the Git plumbing tools function as that). E.g., test-date gives you direct access to the low-level routines, and we feed it a variety of dates. That doesn't help with the cost of invoking that tool over and over, though, once per test case. I wonder if we could have some kind of hybrid. I.e., where t3070 is still a shell script, but it primarily consists of running one big binary, like: test-wildmatch <<-\EOF case 1 case 2 ...etc EOF but with one added twist: test-wildmatch would actually generate TAP output for each test, rather than just returning 0/1 for each success or failure, and being embedded in a test_expect_success. It seems like that would even be pretty easy to do, with the exception of the numbering. It would be nice if we could intermingle this kind of "chunk of C tests" with normal tests, but we'd have to figure out how many tests it ran and increment our shell-script's counter appropriately. -Peff ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-03-06 4:49 ` Jeff King @ 2019-03-06 9:36 ` Duy Nguyen 2019-03-06 19:08 ` Jeff King 2019-03-06 14:16 ` Johannes Schindelin 1 sibling, 1 reply; 29+ messages in thread From: Duy Nguyen @ 2019-03-06 9:36 UTC (permalink / raw) To: Jeff King Cc: Christian Couder, git, Stefan Beller, SZEDER Gábor, Thomas Gummerer, Оля Тележная, Matthieu Moy On Wed, Mar 6, 2019 at 11:49 AM Jeff King <peff@peff.net> wrote: > > On Tue, Mar 05, 2019 at 07:04:59PM +0700, Duy Nguyen wrote: > > > On Mon, Feb 4, 2019 at 4:17 PM Christian Couder > > <christian.couder@gmail.com> wrote: > > > > > > Hi everyone, > > > > > > There are now ideas, micro-projects and organization application pages > > > for GSoC 2019 on https://git.github.io/ > > > > > > It would be nice to have a few more project ideas. > > > > Not sure if it's too late now. Anyway this could be something fun to > > do: support C-based tests in our test suite. > > > > A while back I noticed some test running very long because it was > > trying a lot of input combination. The actual logic is not much, but > > because of the increasing number of test cases, overhead goes off the > > roof. The last part is probably not true, but Windows port I think is > > hit much harder than what I experience, and I think Dscho did complain > > about it. > > > > So what this project does is somehow allow people to write test cases > > in C instead of shell. Imagine replacing t3070-wildmatch.sh with a > > binary program t3070-wildmatch that behaves the same way. This test > > framework needs to support the same basic feature set as test-lib.sh: > > TAP output, test results summary, maybe -i and --valgrind... To > > demonstrate that the test framework works, one of these long test > > files should be rewritten in C. I'm sure there's one that is simple to > > rewrite. > > > > I'm pretty sure I had some fun with this idea and made some prototype > > but I couldn't find it. If I do, I'll post the link here. > > In my experience, it's nicer to have a tool written in C that can be > driven by arbitrary input. That makes it easy to write new test cases, > because you just have to write in some easy domain-specific format > instead of embedding the test data in C code. > > And many of our tests do work like that (in fact, many of the Git > plumbing tools function as that). E.g., test-date gives you direct > access to the low-level routines, and we feed it a variety of dates. > > That doesn't help with the cost of invoking that tool over and over, > though, once per test case. I wonder if we could have some kind of > hybrid. I.e., where t3070 is still a shell script, but it primarily > consists of running one big binary, like: > > test-wildmatch <<-\EOF > case 1 > case 2 > ...etc > EOF > > but with one added twist: test-wildmatch would actually generate TAP > output for each test, rather than just returning 0/1 for each success or > failure, and being embedded in a test_expect_success. Yeah. I mean, converting a full file is just one of the ways to go. The exact design is up to whoever implements it. > It seems like that would even be pretty easy to do, with the exception > of the numbering. I'd like some niceties from test-lib.sh though. -i should be supported to stop at the first failure. -v would be nice if possible. Skipping tsets also. > It would be nice if we could intermingle this kind of > "chunk of C tests" with normal tests, but we'd have to figure out how > many tests it ran and increment our shell-script's counter > appropriately. Even if you convert a full file, you need to do that anyway, to make sure final test run summary is correct (at least when TAP is not used) This kind of framework, I think also helps write new unit tests. There are cases where creating the right condition to trigger just one function is lots of work and easy to break. Sometimes it's easier to do everything in C when full repository is not involved. -- Duy ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-03-06 9:36 ` Duy Nguyen @ 2019-03-06 19:08 ` Jeff King 0 siblings, 0 replies; 29+ messages in thread From: Jeff King @ 2019-03-06 19:08 UTC (permalink / raw) To: Duy Nguyen Cc: Christian Couder, git, Stefan Beller, SZEDER Gábor, Thomas Gummerer, Оля Тележная, Matthieu Moy On Wed, Mar 06, 2019 at 04:36:12PM +0700, Duy Nguyen wrote: > > It seems like that would even be pretty easy to do, with the exception > > of the numbering. > > I'd like some niceties from test-lib.sh though. -i should be supported > to stop at the first failure. -v would be nice if possible. Skipping > tsets also. Yeah, I'd want all of those, too. I think they're easier, though, because it's not too hard to get information _into_ the C program via the environment. But still, somebody has to write the code. :) -Peff ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-03-06 4:49 ` Jeff King 2019-03-06 9:36 ` Duy Nguyen @ 2019-03-06 14:16 ` Johannes Schindelin 1 sibling, 0 replies; 29+ messages in thread From: Johannes Schindelin @ 2019-03-06 14:16 UTC (permalink / raw) To: Jeff King Cc: Duy Nguyen, Christian Couder, git, Stefan Beller, SZEDER Gábor, Thomas Gummerer, Оля Тележная, Matthieu Moy Hi Peff, On Tue, 5 Mar 2019, Jeff King wrote: > On Tue, Mar 05, 2019 at 07:04:59PM +0700, Duy Nguyen wrote: > > > On Mon, Feb 4, 2019 at 4:17 PM Christian Couder > > <christian.couder@gmail.com> wrote: > > > > > > Hi everyone, > > > > > > There are now ideas, micro-projects and organization application pages > > > for GSoC 2019 on https://git.github.io/ > > > > > > It would be nice to have a few more project ideas. > > > > Not sure if it's too late now. Anyway this could be something fun to > > do: support C-based tests in our test suite. > > > > A while back I noticed some test running very long because it was > > trying a lot of input combination. The actual logic is not much, but > > because of the increasing number of test cases, overhead goes off the > > roof. The last part is probably not true, but Windows port I think is > > hit much harder than what I experience, and I think Dscho did complain > > about it. > > > > So what this project does is somehow allow people to write test cases > > in C instead of shell. Imagine replacing t3070-wildmatch.sh with a > > binary program t3070-wildmatch that behaves the same way. This test > > framework needs to support the same basic feature set as test-lib.sh: > > TAP output, test results summary, maybe -i and --valgrind... To > > demonstrate that the test framework works, one of these long test > > files should be rewritten in C. I'm sure there's one that is simple to > > rewrite. > > > > I'm pretty sure I had some fun with this idea and made some prototype > > but I couldn't find it. If I do, I'll post the link here. > > In my experience, it's nicer to have a tool written in C that can be > driven by arbitrary input. That makes it easy to write new test cases, > because you just have to write in some easy domain-specific format > instead of embedding the test data in C code. > > And many of our tests do work like that (in fact, many of the Git > plumbing tools function as that). E.g., test-date gives you direct > access to the low-level routines, and we feed it a variety of dates. > > That doesn't help with the cost of invoking that tool over and over, > though, once per test case. I wonder if we could have some kind of > hybrid. I.e., where t3070 is still a shell script, but it primarily > consists of running one big binary, like: > > test-wildmatch <<-\EOF > case 1 > case 2 > ...etc > EOF > > but with one added twist: test-wildmatch would actually generate TAP > output for each test, rather than just returning 0/1 for each success or > failure, and being embedded in a test_expect_success. > > It seems like that would even be pretty easy to do, with the exception > of the numbering. It would be nice if we could intermingle this kind of > "chunk of C tests" with normal tests, but we'd have to figure out how > many tests it ran and increment our shell-script's counter > appropriately. Oooooh, that sounds like a very nice idea! Eventually, we might even be able to specify our test cases in our own, extensible language, where we do not have to pay attention to &&-chains, or portability, because our test runner does all that for us, under the hood, as it should be. Dreaming of that future, Dscho ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-02-04 9:16 GSoC 2019: Git's application submitted Christian Couder ` (2 preceding siblings ...) 2019-03-05 12:04 ` Duy Nguyen @ 2019-03-18 12:51 ` Duy Nguyen 2019-03-18 16:37 ` Christian Couder 3 siblings, 1 reply; 29+ messages in thread From: Duy Nguyen @ 2019-03-18 12:51 UTC (permalink / raw) To: Christian Couder Cc: git, Jeff King, Stefan Beller, SZEDER Gábor, Thomas Gummerer, Оля Тележная, Matthieu Moy On Mon, Feb 4, 2019 at 4:17 PM Christian Couder <christian.couder@gmail.com> wrote: > > Hi everyone, > > There are now ideas, micro-projects and organization application pages > for GSoC 2019 on https://git.github.io/ > > It would be nice to have a few more project ideas. > https://git.github.io/SoC-2019-Ideas/ currently lists only 2 possible > projects: > > - Unify ref-filter formats with other --pretty formats (which is new) > - git log --oneline improvements > > as I didn't feel that the others were still relevant, though I might be wrong. > > As Olga and Thomas told me at the Git Merge that they could be ok to > co-mentor with me, they are listed as possible mentors for both of > these projects. > > Anyway feel free to comment and suggest improvements on those pages, > especially the micro-projects and ideas one. Pull requests on > https://github.com/git/git.github.io/ are very much appreciated. I'm not opening a pull request because I'm not sure if it's worthy of GSoC (probably 2020, not 2019) but anyway the get_config_* discussion elsewhere reminds me of this. Currently we have two ways of parsing config files, by a callback that gives you everything and you do whatever you want, and with configset where you can just call "get me this config", "get me that one". The idea is moving most callback-based sites to get_config_ one. Preferably in a declarative style, like 'struct option[]'. This should reduce some amount of code because all the "if (!strcmp..) var = git_confg..." is handled by a common code. It's easier to read too. And it may open up an opportunity to suggest misspelled config name (a bit far fetched) and list relevant configs of any command, perhaps with a short description of each config variable too. The configset way should be a bit faster too, but I don't think we care about performance at all here. To handle three-level config like remote.*.url, we can still do it the declarative way by declaring the pattern "remote.*" instead of a fixed variable name which we can't know in advance. There will still be a callback to handle remote.* vars correctly, but the callback should be much smaller and easier to manage, I hope. -- Duy ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: GSoC 2019: Git's application submitted 2019-03-18 12:51 ` Duy Nguyen @ 2019-03-18 16:37 ` Christian Couder 0 siblings, 0 replies; 29+ messages in thread From: Christian Couder @ 2019-03-18 16:37 UTC (permalink / raw) To: Duy Nguyen Cc: git, Jeff King, Stefan Beller, SZEDER Gábor, Thomas Gummerer, Оля Тележная, Matthieu Moy On Mon, Mar 18, 2019 at 1:52 PM Duy Nguyen <pclouds@gmail.com> wrote: > > On Mon, Feb 4, 2019 at 4:17 PM Christian Couder > <christian.couder@gmail.com> wrote: > > Anyway feel free to comment and suggest improvements on those pages, > > especially the micro-projects and ideas one. Pull requests on > > https://github.com/git/git.github.io/ are very much appreciated. > > I'm not opening a pull request because I'm not sure if it's worthy of > GSoC (probably 2020, not 2019) but anyway the get_config_* discussion > elsewhere reminds me of this. I think it would be nice to have a section with potential ideas along with a big warning saying that the ideas there aren't developed enough as is and need much more work/thinking to be considered proper ideas, but we are still putting them there to not forget about them and in case someone would be interested to develop/research them further. > Currently we have two ways of parsing config files, by a callback that > gives you everything and you do whatever you want, and with configset > where you can just call "get me this config", "get me that one". The > idea is moving most callback-based sites to get_config_ one. > Preferably in a declarative style, like 'struct option[]'. Thanks, I like this idea! Maybe it could be even considered for microprojects, as I think it could be done in many small steps. It would perhaps need to point to en existing commit doing already that to make it clearer and easier though. ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2019-03-18 16:37 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-02-04 9:16 GSoC 2019: Git's application submitted Christian Couder [not found] ` <CAL21Bm=K6zZ=APkiP3A_X7xVoOfx-MY2435YMp5y1ztE-xyYtg@mail.gmail.com> 2019-02-04 12:54 ` Christian Couder 2019-02-04 21:52 ` Thomas Gummerer 2019-02-05 21:17 ` Thomas Gummerer 2019-02-05 22:00 ` Christian Couder 2019-02-06 22:09 ` Thomas Gummerer 2019-02-07 19:39 ` Johannes Schindelin 2019-02-07 21:33 ` Thomas Gummerer 2019-02-11 5:41 ` Оля Тележная 2019-02-11 7:45 ` Christian Couder 2019-02-11 8:31 ` Оля Тележная 2019-02-11 10:52 ` Christian Couder 2019-02-13 22:36 ` Elijah Newren 2019-02-14 9:48 ` Christian Couder 2019-02-11 8:35 ` Christian Couder 2019-02-11 22:18 ` Thomas Gummerer 2019-02-11 23:58 ` Christian Couder 2019-02-12 20:25 ` Thomas Gummerer 2019-02-12 20:49 ` Christian Couder 2019-02-12 22:13 ` Thomas Gummerer 2019-02-06 12:27 ` Johannes Schindelin 2019-03-05 12:04 ` Duy Nguyen 2019-03-05 12:23 ` Duy Nguyen 2019-03-06 4:49 ` Jeff King 2019-03-06 9:36 ` Duy Nguyen 2019-03-06 19:08 ` Jeff King 2019-03-06 14:16 ` Johannes Schindelin 2019-03-18 12:51 ` Duy Nguyen 2019-03-18 16:37 ` Christian Couder
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).