[GSoC] Introduction

[GSoC] Introduction

[Shourya Shukla]

Greetings everyone!

I am Shourya Shukla, a Computer Science And Engineering student from IIT Roorkee.
I am very keen on contributing to Git via Google Summer of Code 2020 (GSoC 2020).

I have worked on a microproject(I saw it here[1] and thought I'd give it a shot)
and submitted a patch regarding the same[2], which has been accpeted by Junio C Hamano[3][4]
and will be queued shortly. I have become familiar with mailing lists as well now so it isn't
an issue. I want to know in which direction should I proceed now.

Thanks,
Shourya Shukla

[1]: https://git.github.io/SoC-2019-Microprojects/
[2]: https://lore.kernel.org/git/20200116203622.4694-1-shouryashukla.oo@gmail.com/
[3]: https://lore.kernel.org/git/xmqqy2u08obx.fsf@gitster-ct.c.googlers.com/
[4]: https://lore.kernel.org/git/xmqqtv4o8ob0.fsf@gitster-ct.c.googlers.com/

Re: [GSoC] Introduction

[Christian Couder]

Hi Shourya,

On Wed, Jan 22, 2020 at 9:45 PM Shourya Shukla
<shouryashukla.oo@gmail.com> wrote:
>
> Greetings everyone!
>
> I am Shourya Shukla, a Computer Science And Engineering student from IIT Roorkee.
> I am very keen on contributing to Git via Google Summer of Code 2020 (GSoC 2020).

Nice!

> I have worked on a microproject(I saw it here[1] and thought I'd give it a shot)
> and submitted a patch regarding the same[2], which has been accpeted by Junio C Hamano[3][4]
> and will be queued shortly.

Nice that you have already done a microproject! It would have been
better if you already added [GSoC] to the title of your patches so
that we could more easily find them.

> I have become familiar with mailing lists as well now so it isn't
> an issue. I want to know in which direction should I proceed now.

In https://git.github.io/SoC-2019-Microprojects/ you can find the following:

"If you’ve already done a microproject and are itching to do more,
then get involved in other ways, like finding and fixing other
problems in the code, or improving the documentation or code comments,
or helping to review other people’s patches on the mailing list, or
answering questions on the mailing list or in IRC, or writing new
tests, etc., etc. In short, start doing things that other Git
developers do! Alternatively you can of course focus on your project
proposal."

So I would suggest you follow the above advice.

As we haven't proposed projects yet, you can perhaps look for a
project that you would be interested in. As we say in
https://git.github.io/SoC-2019-Ideas/ the ideas we will propose will
be just … ideas, and the list we will propose will not be exhaustive,
and also we are more than happy to receive proposals for other ideas
related to Git. Be sure to read the "Note about refactoring projects
versus projects that implement new features" though.

Best,
Christian.

Re: [GSoC] Introduction

[Shourya Shukla]

Hey Christian,

Thank you for your advice! Apologies for not tagging my patch with [GSoC],
I didn't realise it before. Is it okay if I try solving a couple of issues
and then focus on the GSoC project(following from what you advised)? 

Also, I wanted to ask whether or not one can try attempting the projects mentioned
last year[1] this year as well? I observed that only one idea[2] was picked out of
the aforementioned project list.

Merci,
Shourya

[1]: https://git.github.io/SoC-2019-Ideas/
[2]: https://summerofcode.withgoogle.com/archive/2019/projects/5390155215536128/

Re: [GSoC] Introduction

[Christian Couder]

On Thu, Jan 23, 2020 at 7:04 PM Shourya Shukla
<shouryashukla.oo@gmail.com> wrote:

> Thank you for your advice! Apologies for not tagging my patch with [GSoC],
> I didn't realise it before. Is it okay if I try solving a couple of issues
> and then focus on the GSoC project(following from what you advised)?

Yeah, it is okay, but we ask for "Only ONE quality focused
microproject per student". So solving other issues might not help much
your GSoC application.

> Also, I wanted to ask whether or not one can try attempting the projects mentioned
> last year[1] this year as well?

You should probably ask the persons mentioned as "possible mentors"

> I observed that only one idea[2] was picked out of
> the aforementioned project list.
>
> [2]: https://summerofcode.withgoogle.com/archive/2019/projects/5390155215536128/

Yeah, because one GSoC student suggested a project idea on his own.

Best,
Christian.

[GSOC] Introduction

[Hariom verma]

Hello,
I'm Hariom Verma, a third-year Computer Science Engineering Student.
I'm using Git for almost 2 years and want to contribute to the same. I had
gone through the solid part of 'SubmittingPatches' and 'Historical Summer of
Code Materials'.
I previously solved 2 issues[1][2] with the help of dscho and looking
forward to work on more before working on minor project to have a good
understanding of Git's Code. But thought I'd take a quick break to
introduce myself.

Thanks
Hariom Verma

[1]: https://github.com/gitgitgadget/git/issues/357
[2]: https://github.com/gitgitgadget/git/issues/399

Re: [GSOC] Introduction

[Christian Couder]

Hi,

On Wed, Jan 1, 2020 at 2:05 PM Hariom verma <hariom18599@gmail.com> wrote:
>
> Hello,
> I'm Hariom Verma, a third-year Computer Science Engineering Student.
> I'm using Git for almost 2 years and want to contribute to the same. I had
> gone through the solid part of 'SubmittingPatches' and 'Historical Summer of
> Code Materials'.

Thank you for getting in touch with us!

Also sorry for the late answer. I think many people had a vacation
around January 1st and I think that's why your email fell through the
cracks.

> I previously solved 2 issues[1][2] with the help of dscho and looking
> forward to work on more before working on minor project to have a good
> understanding of Git's Code. But thought I'd take a quick break to
> introduce myself.

It is not clear looking only at the links if the issues you solved
have resulted in some patches posted to the Git mailing list or just
fixes in Git for Windows. Could you give us more details about that?
For example if you sent emails to the mailing list could you send
links to those emails?

If you have already sent patches to the mailing list and they have
been accepted, you don't need to work on a microproject and I would
then suggest to look at the following:

https://public-inbox.org/git/CAP8UFD2Fo=2suQDLwzLM-Wg3ZzXpqHw-x0brPtPV0d4dRsgs9A@mail.gmail.com/

Best,
Christian.

Re: [GSOC] Introduction

[Hariom verma]

Hi Christian,

On Thu, Jan 23, 2020 at 4:46 PM Christian Couder
<christian.couder@gmail.com> wrote:
>
> It is not clear looking only at the links if the issues you solved
> have resulted in some patches posted to the Git mailing list or just
> fixes in Git for Windows. Could you give us more details about that?
> For example if you sent emails to the mailing list could you send
> links to those emails?

My apologies, here are the links to the patches[1][2].

> If you have already sent patches to the mailing list and they have
> been accepted, you don't need to work on a microproject.

Both have been accepted and merged successfully. Those are just minor
issues, so I don't they can be qualify as microproject. Although I
forgot to tag [GSoC] with the patches.

Few Doubts:
1. Do I need to tag [GSoC] with every patch I will send before GSoC or
just only with a microproject?
2. Can I use GitGitGadget throughout the GSoC period and for my
microproject? (I'm quite liking this tool)

Regards,
Hariom

[1]: https://public-inbox.org/git/3b4b8e0353d705ea649c9fb608c021b35e6d8f5b.1571250635.git.gitgitgadget@gmail.com/
[2]: https://public-inbox.org/git/177deddcf83c2550c0db536a7a6942ba69a92fa5.1574600963.git.gitgitgadget@gmail.com/

Re: [GSOC] Introduction

[Christian Couder]

Hi Hariom,

On Thu, Jan 23, 2020 at 9:18 PM Hariom verma <hariom18599@gmail.com> wrote:
>
> On Thu, Jan 23, 2020 at 4:46 PM Christian Couder
> <christian.couder@gmail.com> wrote:
> >
> > It is not clear looking only at the links if the issues you solved
> > have resulted in some patches posted to the Git mailing list or just
> > fixes in Git for Windows. Could you give us more details about that?
> > For example if you sent emails to the mailing list could you send
> > links to those emails?
>
> My apologies, here are the links to the patches[1][2].

Great, thanks!

> > If you have already sent patches to the mailing list and they have
> > been accepted, you don't need to work on a microproject.
>
> Both have been accepted and merged successfully. Those are just minor
> issues, so I don't they can be qualify as microproject. Although I
> forgot to tag [GSoC] with the patches.

I think it is enough for a microproject.

> Few Doubts:
> 1. Do I need to tag [GSoC] with every patch I will send before GSoC or
> just only with a microproject?

I think it's better, except when replying, if you tag every email you
send before the end of the GSoC with [GSoC].

> 2. Can I use GitGitGadget throughout the GSoC period and for my
> microproject? (I'm quite liking this tool)

I think so. I think other GSoC students and Outreachy interns have done.

Best,
Christian.

[GSoC] Introduction

[Rohit Ashiwal]

Hello
I am Rohit Ashiwal, a computer science and engineering student from
IIT Roorkee. I am a git user for 2 years now and want to contribute
towards its development.
I have read the microproject list available [here](1) and project
titled `Use test_path_is_*  functions in test scripts` caught my eye.
I want to work on this one if anyone is not working on it (I was not
able to find related threads on public-inbox).
I am somewhat familiar with git's code as I was previously working on
git-for-windows and I have solved 1 [issue](2), which is a reason for
my concern. Should this count as a microproject? As the webpage
instructs us to work only on 1 microproject.
If you disregard that contribution, here is my approach to solving
this microproject: search for `test -f` in `t/**` and replace all
occurrences with `test_path_is_file` and similarly for other mentioned
commands. Is it correct?

Regards
Rohit Ashiwal

[1]: https://git.github.io/SoC-2019-Microprojects/
[2]: https://github.com/git-for-windows/git/issues/1970

Re: [GSoC] Introduction

[Johannes Schindelin]

Hi Rohit,

On Sun, 24 Feb 2019, Rohit Ashiwal wrote:

> Hello

Hi there!

> I am Rohit Ashiwal, a computer science and engineering student from
> IIT Roorkee. I am a git user for 2 years now and want to contribute
> towards its development.

Great!

> I have read the microproject list available [here](1) and project
> titled `Use test_path_is_*  functions in test scripts` caught my eye.
> I want to work on this one if anyone is not working on it (I was not
> able to find related threads on public-inbox).

Go for it ;-) The microprojects are basically a straight-forward way to
introduce prospective GSoC students to Git's code contribution process.

In that sense, while it would be better for students not to have
overlapping microprojects, it is not the end of the world, either.

In your case, it is relatively easy to figure out that no other student
mentioned this project on the Git mailing list:
https://public-inbox.org/git/?q=test_path_is_file

> I am somewhat familiar with git's code as I was previously working on
> git-for-windows and I have solved 1 [issue](2), which is a reason for
> my concern. Should this count as a microproject? As the webpage
> instructs us to work only on 1 microproject.

True. You could brush up that pair of patches to teach `git archive` to
avoid spawning `gzip` when generating `.tar.gz` archives, and submit them
using the process suggested in https://git-scm.com/docs/SubmittingPatches.

(You might want to make it easier on yourself and use GitGitGadget, which
takes out the challenge of sending patches in the required format via
email, see https://gitgitgadget.github.io/ for details.)

On the other hand, it might make more sense to start afresh with the
test_path_is_* microproject, as I already took custody of your patches and
planned on submitting them (via GitGitGadget) right after v2.21.0 comes
out.

> If you disregard that contribution, here is my approach to solving
> this microproject: search for `test -f` in `t/**` and replace all
> occurrences with `test_path_is_file` and similarly for other mentioned
> commands. Is it correct?

This is a good first step, indeed. You may want to be careful about it,
though, as there *might* be instances where replacing the `test -f` would
not make sense (such as instances where scripts are written via
`write_script`, and those scripts would not have access to the
`test_path_is_file` function).

You probably also want to inspect instances of `test -e` (which
technically only ask whether a path exists, whether it is a file, a
directory, or a symbolic link), as it might be possible that some tests
use that invocation when they really want to ask whether a file exists.

Then, you want to also look for `test -d` for the `test_path_is_dir`
conversion.

Good luck,
Johannes

Re: [GSoC] Introduction

[Christian Couder]

Hi Rohit,

On Sun, Feb 24, 2019 at 11:08 AM Rohit Ashiwal
<rohit.ashiwal265@gmail.com> wrote:

> If you disregard that contribution, here is my approach to solving
> this microproject: search for `test -f` in `t/**` and replace all
> occurrences with `test_path_is_file` and similarly for other mentioned
> commands. Is it correct?

In addition to what Dscho (alias Johannes Schindelin) wrote, please
just send one patch that replaces `test -d`, `test -d` and similar
code in only one t/tXXXX-*.sh file. No need to do more than that.

Thanks,
Christian.

Re: [GSoC] Introduction

[Rohit Ashiwal]

Hey Christian

On Mon, Feb 25, 2019 at 12:20 PM Christian Couder
<christian.couder@gmail.com> wrote:

> In addition to what Dscho (alias Johannes Schindelin) wrote, please
> just send one patch that replaces `test -d`, `test -d` and similar
> code in only one t/tXXXX-*.sh file. No need to do more than that.

I don't think I quite understood this. Were you asking for replacing
all `test -X` calls with `test_path_is_*` calls in only one tXXXX-*.sh
file or `test -d` calls with `test_path_is_dir` in all tXXXX-*.sh? As
of now, I've changed almost all `test -d` in all relevant tXXXX-*.sh
files.

Thanks
Rohit

Re: [GSoC] Introduction

[Christian Couder]

Hi Rohit,

On Mon, Feb 25, 2019 at 12:36 PM Rohit Ashiwal
<rohit.ashiwal265@gmail.com> wrote:
>
> Hey Christian
>
> On Mon, Feb 25, 2019 at 12:20 PM Christian Couder
> <christian.couder@gmail.com> wrote:
>
> > In addition to what Dscho (alias Johannes Schindelin) wrote, please
> > just send one patch that replaces `test -d`, `test -d` and similar
> > code in only one t/tXXXX-*.sh file. No need to do more than that.
>
> I don't think I quite understood this. Were you asking for replacing
> all `test -X` calls with `test_path_is_*` calls in only one tXXXX-*.sh
> file or `test -d` calls with `test_path_is_dir` in all tXXXX-*.sh? As
> of now, I've changed almost all `test -d` in all relevant tXXXX-*.sh
> files.

First on the micro-project page
(https://git.github.io/SoC-2019-Microprojects/) there is "Please
attempt only ONE microproject. We want quality, not quantity!"

And the description of the micro-project you selected is:

"Find a test script that verifies the presence/absence of
files/directories with ‘test -(e|f|d|…)’ and replace them with the
appropriate test_path_is_file, test_path_is_dir, etc. helper
functions."

This asks you to change only 1 test script, that is one t/tXXXX-*.sh file only.

So yes I am asking for replacing all `test -X` calls with
`test_path_is_*` calls in only one tXXXX-*.sh file.

Thanks,
Christian.

Re: [GSoC] Introduction

[Eric Sunshine]

On Mon, Feb 25, 2019 at 3:22 PM Christian Couder
<christian.couder@gmail.com> wrote:
> On Mon, Feb 25, 2019 at 12:36 PM Rohit Ashiwal
> <rohit.ashiwal265@gmail.com> wrote:
> > I don't think I quite understood this. Were you asking for replacing
> > all `test -X` calls with `test_path_is_*` calls in only one tXXXX-*.sh
> > file or `test -d` calls with `test_path_is_dir` in all tXXXX-*.sh? As
> > of now, I've changed almost all `test -d` in all relevant tXXXX-*.sh
> > files.
>
> So yes I am asking for replacing all `test -X` calls with
> `test_path_is_*` calls in only one tXXXX-*.sh file.

Not stated outright, but an important reason for limiting the scope of
this change (and, indeed, the scope of any patch series) is to ease
the burden on people who review your submission. Large patch series
tend to tax reviewers heavily, even (and often) when repetitive and
simple, like replacing `test -d` with `test_path_is_dir()`. The
shorter and more concise a patch series is, the more likely that it
will receive quality reviews.

Another reason for keeping the scope of changes limited is to ease the
burden of the project maintainer. Patch series which touch a lot of
areas tend to conflict with in-flight topics from other people, and
the project maintainer has to juggle and resolve these problems.
Concise patch series, on the other hand, are less likely to conflict
with changes elsewhere.

[GSOC] Introduction

[karthik nayak]

Hello everyone!
I am Karthik Nayak from Bangalore, India. I am currently pursuing my B.E 
in Computer Science. I am very keen on contributing to Git via GSoC 
2015. I have worked on one of the micro projects[1], I like how code is 
reviewed via the mailing list, It always ensures different perspectives 
on the same code and shows how there is always room for improvement.
I have been using Git for personal work, since about two years now. The 
reason why I want to contribute to Git is because I can relate to what 
is happening in the code, since I use it regularly.
I want to work on the project of "Unifying git branch -l, git tag -l, 
and git for-each-ref" and have been reading up on what Junio suggested 
in a reply to Amate Yolande[2].
I also found a link to a previous discussion[3] on the same topic. Is 
there any other discussion on the same? Do you guys have any comments?

Regards
-Karthik


[1] : http://article.gmane.org/gmane.comp.version-control.git/264911
[2] : http://article.gmane.org/gmane.comp.version-control.git/264966
[3] : http://thread.gmane.org/gmane.comp.version-control.git/261479