Re: Unify ref-filter formats with other pretty formats: GSoC'22

Re: Unify ref-filter formats with other pretty formats: GSoC'22

[Tapasweni Pathak]

Hi Christian,

On Fri, Apr 22, 2022 at 2:44 PM Christian Couder
<christian.couder@gmail.com> wrote:
>
> On Wed, Apr 20, 2022 at 1:49 PM Tapasweni Pathak
> <tapaswenipathak@gmail.com> wrote:
> > On Wed, Apr 20, 2022 at 1:45 PM Christian Couder
> > <christian.couder@gmail.com> wrote:
> > > On Tue, Apr 19, 2022 at 1:54 PM Tapasweni Pathak
> > > <tapaswenipathak@gmail.com> wrote:
>
> > > Maybe you could work on continuing ZheNing Hu's work on the "Use
> > > ref-filter formats in `git cat-file`" GSoC 2021 project, which is a
> > > bit related. This is a very difficult task though, as it requires
> > > dealing with tricky performance issues. And the changes you make might
> > > conflict with those made by someone working on the "Unify ref-filter
> > > formats with other pretty formats" GSoC 2022 project.
> >
> > I would like to work on this with a planner, separately, we can see
> > what should be adapted in mine to have everything go smooth and
> > GSoC'22 project especially.
>
> As you seem interested in other things too, I think it's better to
> avoid this one for now. It could be a bad experience as it's a really
> difficult subject, and I think it would be much better for you to
> start with something easier and smaller.

I must insist; would be interested in a planner and document prep for
the project, I can see some details
- https://git.github.io/SoC-2021-Ideas/
- https://lore.kernel.org/git/pull.989.git.1625155693.gitgitgadget@gmail.com/
- https://docs.google.com/document/d/119k-Xa4CKOt5rC1gg1cqPr6H3MvdgTUizndJGAo1Erk/edit
- https://github.blog/2021-11-15-highlights-from-git-2-34/
- https://lore.kernel.org/git/CAOLTT8S8TxuTmddGp2WGoPtTc3gwGXzizBfVzKd87otRw7Dpiw@mail.gmail.com/

to set things for the next steps, let me know if you strongly feel to
not take up the problem right away.
>
> > > Now if we don't find a good applicant for this latter project, you
> > > might of course work on it. The selected Proposals and Applicant will
> > > be known on May 20 though. So if that would be your prefered project,
> > > you would have to wait until then and hope that we don't select
> > > anyone.
> >
> > Happy to take it up, if it remains open.
>
> Great! Let's see on May 20 if it's still open and you haven't found
> anything else to work on in the meantime.
>
> > > See: https://lore.kernel.org/git/xmqq35iaz6n3.fsf@gitster.g/
> > >
> > > I think he wants someone to add a `train` command to `git rerere`
> > > based on what "contrib/rerere-train.sh" does.
> > >
> > > As you can see "contrib/rerere-train.sh" is a 102 line long shell
> > > script, so converting it to a new `train` command in
> > > "builtin/rerere.c" seems like a not very difficult and not too big
> > > task (especially if done the same way as the script). Junio will
> > > likely be involved in this, as it looks like he is interested in it.
> >
> > Can I take it up immediately, if Junio is not working on it?
> > ++gitster@pobox.com. Hi Junio. Do you suggest otherwise?
>
> I don't want to speak for him, but I don't think he is working on it.
> In fact, as he suggested it for a GSoC, I think he doesn't plan to
> work on it soon. Also he might not answer often to emails that aren't
> also sent to the mailing list.
>
> So if you want to work on it, I would suggest starting right away. You
> can of course send an email on the mailing list to let people know
> that you want to start working on this and to check if anyone is
> already working on it or has suggestions about it.

++git@vger.kernel.org. :)
>
> > > Another thing that was discussed recently is that the git-scm.org web
> > > site could be converted to not use Heroku anymore. If you prefer
> > > working on this kind of web oriented thing, this could be another
> > > possibility.
> >
> > I have worked a lot on web-based projects, SAAS, IAAS, PAAS, FAAS,
> > would it be better to share a proposal of comparison of those keeping
> > git-scm.org in mind, or is it pre-decided where git-scm.org will make
> > its new home/work?
> >
> > This shouldn't take more than 3 working days with no downtimes.
>
> Nice that you have some experience in this!
>
> I added Taylor in Cc as he is involved in this and might answer your
> questions much better than me. Now if you are interested in it, I
> suggest starting right away and perhaps also sending an email to the
> mailing list asking your questions and asking for advice there.

Hi Taylor. Great if you can let me know what you want to see
happening, and if we can discuss tech specifications, you have already
decided or plan to.

Re: Unify ref-filter formats with other pretty formats: GSoC'22

[Junio C Hamano]

Tapasweni Pathak <tapaswenipathak@gmail.com> writes:

>> > > As you can see "contrib/rerere-train.sh" is a 102 line long shell
>> > > script, so converting it to a new `train` command in
>> > > "builtin/rerere.c" seems like a not very difficult and not too big
>> > > task (especially if done the same way as the script). Junio will
>> > > likely be involved in this, as it looks like he is interested in it.
>> >
>> > Can I take it up immediately, if Junio is not working on it?
>> > ++gitster@pobox.com. Hi Junio. Do you suggest otherwise?
>>
>> I don't want to speak for him, but I don't think he is working on it.
>> In fact, as he suggested it for a GSoC, I think he doesn't plan to
>> work on it soon. Also he might not answer often to emails that aren't
>> also sent to the mailing list.

s/answer/see/ actually.  Other than that, everything you said is
correct, Christian ;-)  Mails to this mailbox that is not also going
to the list are usually sent to the spambox.

>> So if you want to work on it, I would suggest starting right away. You
>> can of course send an email on the mailing list to let people know
>> that you want to start working on this and to check if anyone is
>> already working on it or has suggestions about it.

Yes, that is a good advice.

If we were doing 'git rerere train', especially outside GSoC, we
would need to make sure we won't have to redo it later.

A GSoC "easy" version of "git rerere train" would probably write a
loop in C that repeatedly calls get_revision() to enumerate each
merge commit in the given range, and in each iteration, spawns "git
checkout --detach" to update the working tree and the index to that
of its first parent, spawns "git merge" to try merging the other
parent, and when it fails in conflict, updates the index and the
working tree files to match what is recorded in the merge commit,
and spawns "git rerere" to record that resolution.

The thing is, many people on the list are unhappy with the approach
various past GSoc and other tasks took to rewrite scripted Porcelain
commands to C, spawning individual Git command just like the
original scripts did.  These people will be very unhappy with such a
rewrite, I suspect, and would want it see done totally differently.

Now we have ort merge machinery that can be used to implement
in-core merges without touching neither the working tree or the
index, a proper C rewrite of "git rerere train" should work quite
differently from the scripted version, so "easy" version would
likely be discarded and rewritten later.

>> > > Another thing that was discussed recently is that the git-scm.org web
>> > > site could be converted to not use Heroku anymore. If you prefer
>> > > working on this kind of web oriented thing, this could be another
>> > > possibility.
>> >
>> > I have worked a lot on web-based projects, SAAS, IAAS, PAAS, FAAS,
>> > would it be better to share a proposal of comparison of those keeping
>> > git-scm.org in mind, or is it pre-decided where git-scm.org will make
>> > its new home/work?
>> >
>> > This shouldn't take more than 3 working days with no downtimes.
>>
>> Nice that you have some experience in this!

Yup.  This is not in my area of expertise, but it is very worthy
work.  If we can wean ourselves off of Heroku (the only thing we are
doing is to serve a pretty much static website) sooner, it would be
very good.

>> I added Taylor in Cc as he is involved in this and might answer your
>> questions much better than me. Now if you are interested in it, I
>> suggest starting right away and perhaps also sending an email to the
>> mailing list asking your questions and asking for advice there.
>
> Hi Taylor. Great if you can let me know what you want to see
> happening, and if we can discuss tech specifications, you have already
> decided or plan to.

Re: Unify ref-filter formats with other pretty formats: GSoC'22

[Christian Couder]

Hi Tapasweni,

On Fri, Apr 22, 2022 at 12:29 PM Tapasweni Pathak
<tapaswenipathak@gmail.com> wrote:
> On Fri, Apr 22, 2022 at 2:44 PM Christian Couder
> <christian.couder@gmail.com> wrote:
> > On Wed, Apr 20, 2022 at 1:49 PM Tapasweni Pathak
> > <tapaswenipathak@gmail.com> wrote:

> > > I would like to work on this with a planner, separately, we can see
> > > what should be adapted in mine to have everything go smooth and
> > > GSoC'22 project especially.
> >
> > As you seem interested in other things too, I think it's better to
> > avoid this one for now. It could be a bad experience as it's a really
> > difficult subject, and I think it would be much better for you to
> > start with something easier and smaller.
>
> I must insist; would be interested in a planner and document prep for
> the project, I can see some details
> - https://git.github.io/SoC-2021-Ideas/
> - https://lore.kernel.org/git/pull.989.git.1625155693.gitgitgadget@gmail.com/
> - https://docs.google.com/document/d/119k-Xa4CKOt5rC1gg1cqPr6H3MvdgTUizndJGAo1Erk/edit
> - https://github.blog/2021-11-15-highlights-from-git-2-34/
> - https://lore.kernel.org/git/CAOLTT8S8TxuTmddGp2WGoPtTc3gwGXzizBfVzKd87otRw7Dpiw@mail.gmail.com/
>
> to set things for the next steps, let me know if you strongly feel to
> not take up the problem right away.

I am not sure what "planner" and "document prep" mean exactly to you,
and what "the problem" is. I replied to your other email and I hope it
helps, but maybe in my replies here and to your other email I am
missing something. In this case please let me know.

We are ok to describe projects in a few sentences or paragraphs, like
in https://git.github.io/SoC-2021-Ideas/ where we describe the
projects we propose, but for GSoC and Outreachy, applicants interested
in a project are those who actually write the proposals which usually
include a timeline.

I am sure not, but it looks to me like you would like us (not you) to
write a full proposal including a timeline.

For example the proposal in
https://docs.google.com/document/d/119k-Xa4CKOt5rC1gg1cqPr6H3MvdgTUizndJGAo1Erk/edit
which includes a timeline was fully writen by ZheNing Hu, and was then
accepted by us, so that ZheNing Hu could then participate in the GSoC
2021 and start the actual work.

https://lore.kernel.org/git/pull.989.git.1625155693.gitgitgadget@gmail.com/
shows some of the work he did and sent to the mailing list as part of
the GSoC.

https://github.blog/2021-11-15-highlights-from-git-2-34/ is not
especially related to any GSoC.

https://lore.kernel.org/git/CAOLTT8S8TxuTmddGp2WGoPtTc3gwGXzizBfVzKd87otRw7Dpiw@mail.gmail.com/
is a discussion about the Outreachy Winter 2021-2022 round (not GSoC)
where ZheNing Hu accepted to co-mentor with me someone who would work
on continuing Hariom's GSoC 2020 "Unify ref-filter formats with other
\-\-pretty formats" project. As there were no Outreachy applicants
interested in working on this, we proposed this same project to the
upcoming GSoC.

So I don't see any problem that we should take up with the links you
listed. If someone would have it write a full proposal and a detailed
timeline it would be you, not us. Of course, as you propose to work
outside GSoC and Outreachy, we don't require that from you, because
you would not be part of any such official program and wouldn't get
paid.

I hope I don't misunderstand what you said.

Re: Unify ref-filter formats with other pretty formats: GSoC'22

[Tapasweni Pathak]

Hi Christian,

On Tue, Apr 26, 2022 at 3:25 PM Christian Couder
<christian.couder@gmail.com> wrote:
>
> Hi Tapasweni,
>
> On Fri, Apr 22, 2022 at 12:29 PM Tapasweni Pathak
> <tapaswenipathak@gmail.com> wrote:
> > On Fri, Apr 22, 2022 at 2:44 PM Christian Couder
> > <christian.couder@gmail.com> wrote:
> > > On Wed, Apr 20, 2022 at 1:49 PM Tapasweni Pathak
> > > <tapaswenipathak@gmail.com> wrote:
>
> > > > I would like to work on this with a planner, separately, we can see
> > > > what should be adapted in mine to have everything go smooth and
> > > > GSoC'22 project especially.
> > >
> > > As you seem interested in other things too, I think it's better to
> > > avoid this one for now. It could be a bad experience as it's a really
> > > difficult subject, and I think it would be much better for you to
> > > start with something easier and smaller.
> >
> > I must insist; would be interested in a planner and document prep for
> > the project, I can see some details
> > - https://git.github.io/SoC-2021-Ideas/
> > - https://lore.kernel.org/git/pull.989.git.1625155693.gitgitgadget@gmail.com/
> > - https://docs.google.com/document/d/119k-Xa4CKOt5rC1gg1cqPr6H3MvdgTUizndJGAo1Erk/edit
> > - https://github.blog/2021-11-15-highlights-from-git-2-34/
> > - https://lore.kernel.org/git/CAOLTT8S8TxuTmddGp2WGoPtTc3gwGXzizBfVzKd87otRw7Dpiw@mail.gmail.com/
> >
> > to set things for the next steps, let me know if you strongly feel to
> > not take up the problem right away.
>
> I am not sure what "planner" and "document prep" mean exactly to you,
> and what "the problem" is. I replied to your other email and I hope it
> helps, but maybe in my replies here and to your other email I am
> missing something. In this case please let me know.

GSoC Timeline. :)
>
> We are ok to describe projects in a few sentences or paragraphs, like
> in https://git.github.io/SoC-2021-Ideas/ where we describe the
> projects we propose, but for GSoC and Outreachy, applicants interested
> in a project are those who actually write the proposals which usually
> include a timeline.
>
> I am sure not, but it looks to me like you would like us (not you) to
> write a full proposal including a timeline.

No, no. not. at. all.
>
> For example the proposal in
> https://docs.google.com/document/d/119k-Xa4CKOt5rC1gg1cqPr6H3MvdgTUizndJGAo1Erk/edit
> which includes a timeline was fully writen by ZheNing Hu, and was then
> accepted by us, so that ZheNing Hu could then participate in the GSoC
> 2021 and start the actual work.
>
> https://lore.kernel.org/git/pull.989.git.1625155693.gitgitgadget@gmail.com/
> shows some of the work he did and sent to the mailing list as part of
> the GSoC.
>
> https://github.blog/2021-11-15-highlights-from-git-2-34/ is not
> especially related to any GSoC.
>
> https://lore.kernel.org/git/CAOLTT8S8TxuTmddGp2WGoPtTc3gwGXzizBfVzKd87otRw7Dpiw@mail.gmail.com/
> is a discussion about the Outreachy Winter 2021-2022 round (not GSoC)
> where ZheNing Hu accepted to co-mentor with me someone who would work
> on continuing Hariom's GSoC 2020 "Unify ref-filter formats with other
> \-\-pretty formats" project. As there were no Outreachy applicants
> interested in working on this, we proposed this same project to the
> upcoming GSoC.
>
> So I don't see any problem that we should take up with the links you
> listed. If someone would have it write a full proposal and a detailed
> timeline it would be you, not us. Of course, as you propose to work
> outside GSoC and Outreachy, we don't require that from you, because
> you would not be part of any such official program and wouldn't get
> paid.
>
> I hope I don't misunderstand what you said.

I will update will a timeline in the next few weeks (June).

Thank you for the information.

Re: Unify ref-filter formats with other pretty formats: GSoC'22

[Tapasweni Pathak]

On Sat, Sep 10, 2022 at 4:11 AM Taylor Blau <me@ttaylorr.com> wrote:
>
> [-cc list]
>
> Hi Tapasweni,
>
> On Tue, May 31, 2022 at 09:54:24PM +0530, Tapasweni Pathak wrote:
> > I will update will a timeline in the next few weeks (June).
> >
> > Thank you for the information.
>
> Sorry that this has sat in my inbox for so long. Did you get around to
> updating this timeline? I was talking with Christian off-list, and it
> sounds like this could be a potentially good fit for Outreachy, though I
> am not sure of the specifics.

website one?

>
> Could you two work together to resurrect this project for Outreachy, if
> that is something that you both are interested in?
>
> Thanks,
> Taylor

Re: Unify ref-filter formats with other pretty formats: GSoC'22

[Tapasweni Pathak]

Hi Taylor, Hi Junio,

I have added the mailing list (++git@vger.kernel.org) in this email,
hope now it lands better in your mailbox.

I would be happy to take these tasks, not that I require any
mentorship but to work with folks who are involved. I have had times
where my work has not been seen for quarters and then closed after
reviews cycles, never let it re-happen.

It is a nice and respectful way to say, already deeply involved folks
as mentors, for someone who is entering the org or community. Not that
I require any tech or engineering help or otherwise, I mostly work
independently, just don't want to go my work stale and be clear on
what exactly is required (before or after a discussion, rather w/ or
w/o any discussions)

On Fri, Apr 22, 2022 at 2:51 PM Christian Couder
<christian.couder@gmail.com> wrote:
>
> Taylor and Junio,
>
> For some context, Tapasweni is willing to work outside the GSoC (as it
> looks like she is not eligible for GSoC as she is not a beginner in
> open source) on some Git related project as long as she gets some
> mentorship.
>
> Tapasweni, please correct me if I am wrong.
>
> Best,
> Christian.

Re: Unify ref-filter formats with other pretty formats: GSoC'22

[Christian Couder]

Hi Tapasweni,

On Fri, Apr 22, 2022 at 12:40 PM Tapasweni Pathak
<tapaswenipathak@gmail.com> wrote:
>
> Hi Taylor, Hi Junio,
>
> I have added the mailing list (++git@vger.kernel.org) in this email,
> hope now it lands better in your mailbox.
>
> I would be happy to take these tasks, not that I require any
> mentorship but to work with folks who are involved.

I am sure that there will be folks who are involved who will work with
you if you select one of the projects we suggested. We don't suggest
projects we are not interested in. The old timers who suggest them and
are willing to mentor usually do get involved in them.

> I have had times
> where my work has not been seen for quarters and then closed after
> reviews cycles, never let it re-happen.

We cannot guarantee that your work will be merged, as some better
solution might be found, or someone else will decide to do it in
another way and it might turn out to be better. But otherwise you can
be pretty sure that your work will get reviewed. It might take some
time and we might ask for a lot of changes in the reviews though.

> It is a nice and respectful way to say, already deeply involved folks
> as mentors, for someone who is entering the org or community. Not that
> I require any tech or engineering help or otherwise, I mostly work
> independently, just don't want to go my work stale and be clear on
> what exactly is required (before or after a discussion, rather w/ or
> w/o any discussions)

I think we are open to answering specific questions about what is
required for the work we suggest. We might sometimes be wrong though
and realize it later, so the requirements (or sometimes the whole
solution we suggest) could change along the way. That's how software
development works. And even in this case the fact that we realize that
our requirements were wrong is an achievement.

Re: Unify ref-filter formats with other pretty formats: GSoC'22

[Tapasweni Pathak]

Hi Christian,

Took a while. I hope we would be in a habit to connect to old conversations. :)

On Mon, Apr 25, 2022 at 2:07 PM Christian Couder
<christian.couder@gmail.com> wrote:
>
> Hi Tapasweni,
>
> On Fri, Apr 22, 2022 at 12:40 PM Tapasweni Pathak
> <tapaswenipathak@gmail.com> wrote:
> >
> > Hi Taylor, Hi Junio,
> >
> > I have added the mailing list (++git@vger.kernel.org) in this email,
> > hope now it lands better in your mailbox.
> >
> > I would be happy to take these tasks, not that I require any
> > mentorship but to work with folks who are involved.
>
> I am sure that there will be folks who are involved who will work with
> you if you select one of the projects we suggested. We don't suggest
> projects we are not interested in. The old timers who suggest them and
> are willing to mentor usually do get involved in them.

Yes, sure, sending the initial draft for git-scm.com in the next
email. I will soon loop in the plan/timeline for two other tasks,
described.
>
> > I have had times
> > where my work has not been seen for quarters and then closed after
> > reviews cycles, never let it re-happen.
>
> We cannot guarantee that your work will be merged, as some better
> solution might be found, or someone else will decide to do it in
> another way and it might turn out to be better. But otherwise you can
> be pretty sure that your work will get reviewed. It might take some
> time and we might ask for a lot of changes in the reviews though.

Sure!
>
> > It is a nice and respectful way to say, already deeply involved folks
> > as mentors, for someone who is entering the org or community. Not that
> > I require any tech or engineering help or otherwise, I mostly work
> > independently, just don't want to go my work stale and be clear on
> > what exactly is required (before or after a discussion, rather w/ or
> > w/o any discussions)
>
> I think we are open to answering specific questions about what is
> required for the work we suggest. We might sometimes be wrong though
> and realize it later, so the requirements (or sometimes the whole
> solution we suggest) could change along the way. That's how software
> development works. And even in this case the fact that we realize that
> our requirements were wrong is an achievement.

Agree!

Re: Unify ref-filter formats with other pretty formats: GSoC'22

[Tapasweni Pathak]

.++git <git@vger.kernel.org>.

Hi Taylor,

On Tue, Apr 26, 2022 at 5:31 AM Taylor Blau <me@ttaylorr.com> wrote:
>
> Hi Tapasweni, Christian,
>
> On Fri, Apr 22, 2022 at 11:21:37AM +0200, Christian Couder wrote:
> > Taylor and Junio,
> >
> > For some context, Tapasweni is willing to work outside the GSoC (as it
> > looks like she is not eligible for GSoC as she is not a beginner in
> > open source) on some Git related project as long as she gets some
> > mentorship.
> >
> > Tapasweni, please correct me if I am wrong.
>
> Terrific!
>
I just thought about what could be better with current GSoC
eligibility guidelines and open source in general. Says, I'm not a
beginner.

(something to deep think about)

> Tapasweni: a good summary of the current state of git-scm.com can be
> found in an email I sent here:
>
>     https://lore.kernel.org/git/YkcmtqcFaO7v1jW5@nand.local/
>
> , and I think the section that will be most relevant to you begins with
> "Convert the Rails application into a static site [...]".
>
> In that email, I suggested GitHub Pages as one such hosting provider
> that might suit our needs. But I am not the only decision-maker there,
> that should come from the community. It would be ideal if the service we
> chose was free, or near-free.
>
> It's possible that some providers may want to sponsor git-scm.com's
> hosting as an open-source project. But that's a discussion for another
> day :-).
>
> In the meantime, if you are interested in converting git-scm.com to a
> static site, let me know. As far as I can think, there are only a
> handful of components that aren't static and would need to be replaced.
> Those are: the search bar functionality, some light database work, and
> automatic rebuilding of Git's own documentation. The site's Rakefile is
> a good jumping off point to figure out what some of the non-static parts
> are.
>
> If you're interested, let me know. I'm not fully versed in every corner
> of the site's architecture, but I have a general idea of how things work
> and would be happy to fill in any gaps on your end, and/or explore
> together :-).
I have drafted this for the merger of:
https://paper.dropbox.com/doc/git-scm.com--Bihq4Cxzo3AzCrZqgScRkRo5AQ-LBbrQXZfwvrTMnhdEwhl8

1. Git SCM: https://git-scm.com/
2. Git Developer Pages: https://git.github.io/
3. Git Reference: http://git.github.io/git-reference/

If this looks good, i.e., Jekyll and GitHub Pages (with maybe a new
org? git-scm?), I will fill in the timeline. I have tried to add and
cover all suggestions while working on git-scm w/ Heroku.

Please let me know what everyone thinks.  Let me know if you prefer
Google Doc, paper.dropbox.com requires a signup/sign in.

(This email is to complete the draft document to have a concrete plan)


>
> Thanks,
> Taylor