GSoC 2019: Git's application submitted

GSoC 2019: Git's application submitted

[Christian Couder]

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.

Re: GSoC 2019: Git's application submitted

[Christian Couder]

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.

Re: GSoC 2019: Git's application submitted

[Thomas Gummerer]

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.

Re: GSoC 2019: Git's application submitted

[Thomas Gummerer]

[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?

Re: GSoC 2019: Git's application submitted

[Christian Couder]

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.

Re: GSoC 2019: Git's application submitted

[Thomas Gummerer]

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.

Re: GSoC 2019: Git's application submitted

[Johannes Schindelin]

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.
> 

Re: GSoC 2019: Git's application submitted

[Thomas Gummerer]

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

Re: GSoC 2019: Git's application submitted

[Оля Тележная]

> 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?

Re: GSoC 2019: Git's application submitted

[Christian Couder]

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.

Re: GSoC 2019: Git's application submitted

[Оля Тележная]

пн, 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.

Re: GSoC 2019: Git's application submitted

[Christian Couder]

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.

Re: GSoC 2019: Git's application submitted

[Elijah Newren]

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.

Re: GSoC 2019: Git's application submitted

[Christian Couder]

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.

Re: GSoC 2019: Git's application submitted

[Christian Couder]

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.

Re: GSoC 2019: Git's application submitted

[Thomas Gummerer]

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.

Re: GSoC 2019: Git's application submitted

[Christian Couder]

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.

Re: GSoC 2019: Git's application submitted

[Thomas Gummerer]

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.

Re: GSoC 2019: Git's application submitted

[Christian Couder]

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."

Re: GSoC 2019: Git's application submitted

[Thomas Gummerer]

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.

Re: GSoC 2019: Git's application submitted

[Johannes Schindelin]

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

Re: GSoC 2019: Git's application submitted

[Duy Nguyen]

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

Re: GSoC 2019: Git's application submitted

[Duy Nguyen]

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

Re: GSoC 2019: Git's application submitted

[Jeff King]

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

Re: GSoC 2019: Git's application submitted

[Duy Nguyen]

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

Re: GSoC 2019: Git's application submitted

[Jeff King]

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

Re: GSoC 2019: Git's application submitted

[Johannes Schindelin]

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

Re: GSoC 2019: Git's application submitted

[Duy Nguyen]

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

Re: GSoC 2019: Git's application submitted

[Christian Couder]

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.