GSoC 2016: Microproject

GSoC 2016: Microproject

[Mehul Jain]

Hello everyone,

I'm Mehul Jain. I'm looking for participating in GSoC 2016.

I've started work on a Microproject" Teach git pull --rebase the
--no-autostash" option. While looking at Git's source code I have made
following observation: In the pull.c file
1.  git_config_get_bool( , ) search in the configuration key for the
value of rebase.autostash, if found true then modify autostash's value
to a non-zero number and thus making a stash to encounter the problem
of dirty tree.
2. Here if in command line a flag "--no-autostash" is given then we
can easily set the value of autostash = 0 and thus killing the process
by die_on_unclean_work_tree(prefix).
Is my observation is right?

I'm new to open source projects and not much experienced at it. So
please correct/comment on any mistake that I made while trying to put
my point. I will also appreciate any comment/suggestion/criticism on
my observation.

Thanks

Re: GSoC 2016: Microproject

[Matthieu Moy]

Hi,

This is a double-post. You've posted almost the same message under the
title "GSoC 2016". Nothing serious, but attention to details is
important if you want to give a good image of yourself.

Mehul Jain <mehul.jain2029@gmail.com> writes:

> Hello everyone,
>
> I'm Mehul Jain. I'm looking for participating in GSoC 2016.

Note that we are just submitting our application, but have no guarantee
that the Git organization will be accepted for this year's GSoC.

> I've started work on a Microproject" Teach git pull --rebase the
> --no-autostash" option. While looking at Git's source code I have made
> following observation: In the pull.c file
> 1.  git_config_get_bool( , ) search in the configuration key for the
> value of rebase.autostash, if found true then modify autostash's value
> to a non-zero number and thus making a stash to encounter the problem
> of dirty tree.
> 2. Here if in command line a flag "--no-autostash" is given then we
> can easily set the value of autostash = 0 and thus killing the process
> by die_on_unclean_work_tree(prefix).
> Is my observation is right?

I don't have all the code in mind, but I think it is. In this situation,
you always end up with a variable telling Git what to do (I guess,
autostash here), and this variable is set according to the configuration
and the command-line.

You should be careful about the precedence: command-line should override
the configuration. And the default behavior should be used if neither
the command-line nor the configuration specified otherwise.

To get an example, you can pick any pair (command-line option, config)
that work together, find the code implementing it and blame to find the
corresponding commit.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: Microproject

[Mehul Jain]

On Fri, Feb 19, 2016 at 6:33 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Hi,
>
> This is a double-post. You've posted almost the same message under the
> title "GSoC 2016". Nothing serious, but attention to details is
> important if you want to give a good image of yourself.

I'm sorry of this kind of behavior. It was due to a misunderstanding by my side.

> I don't have all the code in mind, but I think it is. In this situation,
> you always end up with a variable telling Git what to do (I guess,
> autostash here), and this variable is set according to the configuration
> and the command-line.
>
> You should be careful about the precedence: command-line should override
> the configuration. And the default behavior should be used if neither
> the command-line nor the configuration specified otherwise.

Thanks for the suggestion.
I've started the work on patch and did the change in the code which
were necessary for Microproject. I have run the test by using "make",
and there was no failure of any test.
I've a doubt regarding tests. Here as "git pull" will now understand
the argument that  "--[no-]autostash" means "rebase.autostash" should
be set false for current execution of command "git pull --rebase". So
do I have to write a test for this new option?

Mehul Jain

Re: GSoC 2016: Microproject

[Stefan Beller]

On Fri, Feb 19, 2016 at 9:39 AM, Mehul Jain <mehul.jain2029@gmail.com> wrote:
> On Fri, Feb 19, 2016 at 6:33 PM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Hi,
>>
>> This is a double-post. You've posted almost the same message under the
>> title "GSoC 2016". Nothing serious, but attention to details is
>> important if you want to give a good image of yourself.
>
> I'm sorry of this kind of behavior. It was due to a misunderstanding by my side.
>
>> I don't have all the code in mind, but I think it is. In this situation,
>> you always end up with a variable telling Git what to do (I guess,
>> autostash here), and this variable is set according to the configuration
>> and the command-line.
>>
>> You should be careful about the precedence: command-line should override
>> the configuration. And the default behavior should be used if neither
>> the command-line nor the configuration specified otherwise.
>
> Thanks for the suggestion.
> I've started the work on patch and did the change in the code which
> were necessary for Microproject. I have run the test by using "make",
> and there was no failure of any test.
> I've a doubt regarding tests. Here as "git pull" will now understand
> the argument that  "--[no-]autostash" means "rebase.autostash" should
> be set false for current execution of command "git pull --rebase". So
> do I have to write a test for this new option?
>

Yes, most likely t/t5521-pull-options.sh or t/t5520-pull.sh would be the right
place as judging from the file name of the tests.

Thanks,
Stefan

> Mehul Jain
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GSoC 2016: Microproject

[Mehul Jain]

On Fri, Feb 19, 2016 at 11:20 PM, Stefan Beller <sbeller@google.com> wrote:
> Yes, most likely t/t5521-pull-options.sh or t/t5520-pull.sh would be the right
> place as judging from the file name of the tests.

Thanks for specifying the files. I think t/t5520-pull.sh line 258 will
be the best place to write test for this case.

Mehul Jain

Re: GSoC 2016: Microproject

[Mehul Jain]

Hello,

I faced the following problem when I tested master branch. Here I have
made no commits to master branch.

*** t5539-fetch-http-shallow.sh ***
ok 1 - setup shallow clone
not ok 2 - clone http repository
#
# git clone --bare --no-local shallow "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
# git clone $HTTPD_URL/smart/repo.git clone &&
# (
# cd clone &&
# git fsck &&
# git log --format=%s origin/master >actual &&
# cat <<EOF >expect &&
# 7
# 6
# 5
# 4
# 3
# EOF
# test_cmp expect actual
# )
#
not ok 3 - no shallow lines after receiving ACK ready
#
# (
# cd shallow &&
# test_tick &&
# for i in $(test_seq 15)
# do
# git checkout --orphan unrelated$i &&
# test_commit unrelated$i &&
# git push -q "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" \
# refs/heads/unrelated$i:refs/heads/unrelated$i &&
# git push -q ../clone/.git \
# refs/heads/unrelated$i:refs/heads/unrelated$i ||
# exit 1
# done &&
# git checkout master &&
# test_commit new &&
# git push  "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" master
# ) &&
# (
# cd clone &&
# git checkout --orphan newnew &&
# test_commit new-too &&
# GIT_TRACE_PACKET="$TRASH_DIRECTORY/trace" git fetch --depth=2 &&
# grep "fetch-pack< ACK .* ready" ../trace &&
# ! grep "fetch-pack> done" ../trace
# )
#
# failed 2 among 3 test(s)
1..3
make[1]: *** [t5539-fetch-http-shallow.sh] Error 1
make[1]: Leaving directory `/home/mj/git/t'
make: *** [test] Error 2

Is this test failure usual with linux based system or just happened with me.
I'm running Ubuntu 14.04.

thanks,
Mehul Jain

On Fri, Feb 19, 2016 at 11:20 PM, Stefan Beller <sbeller@google.com> wrote:
> On Fri, Feb 19, 2016 at 9:39 AM, Mehul Jain <mehul.jain2029@gmail.com> wrote:
>> On Fri, Feb 19, 2016 at 6:33 PM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>> Hi,
>>>
>>> This is a double-post. You've posted almost the same message under the
>>> title "GSoC 2016". Nothing serious, but attention to details is
>>> important if you want to give a good image of yourself.
>>
>> I'm sorry of this kind of behavior. It was due to a misunderstanding by my side.
>>
>>> I don't have all the code in mind, but I think it is. In this situation,
>>> you always end up with a variable telling Git what to do (I guess,
>>> autostash here), and this variable is set according to the configuration
>>> and the command-line.
>>>
>>> You should be careful about the precedence: command-line should override
>>> the configuration. And the default behavior should be used if neither
>>> the command-line nor the configuration specified otherwise.
>>
>> Thanks for the suggestion.
>> I've started the work on patch and did the change in the code which
>> were necessary for Microproject. I have run the test by using "make",
>> and there was no failure of any test.
>> I've a doubt regarding tests. Here as "git pull" will now understand
>> the argument that  "--[no-]autostash" means "rebase.autostash" should
>> be set false for current execution of command "git pull --rebase". So
>> do I have to write a test for this new option?
>>
>
> Yes, most likely t/t5521-pull-options.sh or t/t5520-pull.sh would be the right
> place as judging from the file name of the tests.
>
> Thanks,
> Stefan
>
>> Mehul Jain
>> --
>> To unsubscribe from this list: send the line "unsubscribe git" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: GSoC 2016: Microproject

[Matthieu Moy]

Please, don't top-post on this list.

Mehul Jain <mehul.jain2029@gmail.com> writes:

> Hello,
>
> I faced the following problem when I tested master branch. Here I have
> made no commits to master branch.

Are you sure that 1) you have no uncommitted change and 2) you have
compiled what you have in your tree?

> Is this test failure usual with linux based system or just happened with me.

All tests are supposed to pass. You can see the result of the Travis-CI
builds there:

  https://travis-ci.org/git/git/branches

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: Microproject

[Mehul Jain]

On Sun, Feb 21, 2016 at 10:25 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Please, don't top-post on this list.

I apologize for top-posting on the list.

> Are you sure that 1) you have no uncommitted change and 2) you have
> compiled what you have in your tree?

1) Yes, I have no uncommited change in the branch(master).
2) Yes, I compiled before testing.

Earlier when I was testing the master branch on my pc, I used "make"
in \t directory, which lead to failure of test #2, #3 in
t5539-fetch-http-shallow.sh .
Afterwards I switched to sudo mode and ran the make command again.
This time all test of  t5539-fetch-http-shallow.sh passed, but test
#32 of file t7300-clean.sh failed. To crosscheck, I ran " sudo sh
./t7300-clean.sh -v --run='1-32' " which gave the following error
message -

Skipping repository baz/boo
Skipping repository foo/
Removing possible_sub1/
Skipping repository repo/
Skipping repository sub2/
Removing to_clean/
File possible_sub1/.git doesn't exist.
not ok 32 - should avoid cleaning possible submodules
#
# rm -fr to_clean possible_sub1 &&
# mkdir to_clean possible_sub1 &&
# test_when_finished "rm -rf possible_sub*" &&
# echo "gitdir: foo" >possible_sub1/.git &&
# >possible_sub1/hello.world &&
# chmod 0 possible_sub1/.git &&
# >to_clean/should_clean.this &&
# git clean -f -d &&
# test_path_is_file possible_sub1/.git &&
# test_path_is_file possible_sub1/hello.world &&
# test_path_is_missing to_clean
#

I haven't made any commits/changes in the master branch. Can you
please suggest where things are going wrong.

Thanks
Mehul Jain

Re: GSoC 2016: Microproject

[Matthieu Moy]

Mehul Jain <mehul.jain2029@gmail.com> writes:

> Earlier when I was testing the master branch on my pc, I used "make"
> in \t directory, which lead to failure of test #2, #3 in
> t5539-fetch-http-shallow.sh .
> Afterwards I switched to sudo mode and ran the make command again.

Never ever do that. Your git source tree should be within your $HOME
directory, and you should never run any command as root that creates
files within your $HOME dir. If you do that, you'll end up having files
belonging to root within other directories, you won't have write
permission on these files. Then, anything can go wrong because any
attempt to write to these files will fail.

The simplest way to get back on track for you is probably to start over
with a fresh clone, or (warning: destructive operations): use git clean
to remove untracked files.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016: Microproject

[Karthik Nayak]

On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Mehul Jain <mehul.jain2029@gmail.com> writes:
>
>> Earlier when I was testing the master branch on my pc, I used "make"
>> in \t directory, which lead to failure of test #2, #3 in
>> t5539-fetch-http-shallow.sh .
>> Afterwards I switched to sudo mode and ran the make command again.
>
> Never ever do that. Your git source tree should be within your $HOME
> directory, and you should never run any command as root that creates
> files within your $HOME dir. If you do that, you'll end up having files
> belonging to root within other directories, you won't have write
> permission on these files. Then, anything can go wrong because any
> attempt to write to these files will fail.
>
> The simplest way to get back on track for you is probably to start over
> with a fresh clone, or (warning: destructive operations): use git clean
> to remove untracked files.
>

I think a 'sudo git clean' outta be enough. But the main point to take away is
not using 'make' with 'sudo' like you mentioned.

-- 
Regards,
Karthik Nayak

Re: GSoC 2016: Microproject

[Mehul Jain]

On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> The simplest way to get back on track for you is probably to start over
> with a fresh clone, or (warning: destructive operations): use git clean
> to remove untracked files.

Hello Matthieu,

I followed your advise and cloned a fresh copy of git source code.
After compiling it and running the test with " prove --timer --jobs 15
./t[0-9]*.sh" command, I received tests failure. All these tests are
regarding HTTP protocol being invoked like
t5539-fetch-http-shallow.sh.

I'm behind a proxy server which blocks all ports except 80 and 443.
Also my .gitconfig file is properly configured for proxy. Can these
tests failure be triggered because of proxy server?

Thanks,
Mehul Jain

Re: GSoC 2016: Microproject

[Duy Nguyen]

On Mon, Feb 22, 2016 at 5:12 PM, Mehul Jain <mehul.jain2029@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> The simplest way to get back on track for you is probably to start over
>> with a fresh clone, or (warning: destructive operations): use git clean
>> to remove untracked files.
>
> Hello Matthieu,
>
> I followed your advise and cloned a fresh copy of git source code.
> After compiling it and running the test with " prove --timer --jobs 15
> ./t[0-9]*.sh" command, I received tests failure. All these tests are
> regarding HTTP protocol being invoked like
> t5539-fetch-http-shallow.sh.

You may have an http server installed but not suitable for these
tests. Try running one test file alone with -v -i, e.g.
./t5539-fetch-http-shallow.sh -v -i and post the output.

> I'm behind a proxy server which blocks all ports except 80 and 443.
> Also my .gitconfig file is properly configured for proxy. Can these
> tests failure be triggered because of proxy server?

No. HTTP server will be run locally on your machine and serve all the tests.
-- 
Duy

Re: GSoC 2016: Microproject

[Mehul Jain]

On Mon, Feb 22, 2016 at 3:50 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> You may have an http server installed but not suitable for these
> tests. Try running one test file alone with -v -i, e.g.
> ./t5539-fetch-http-shallow.sh -v -i and post the output.

Here's the output :-

expecting success:
    git clone --bare --no-local shallow "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
    git clone $HTTPD_URL/smart/repo.git clone &&
    (
    cd clone &&
    git fsck &&
    git log --format=%s origin/master >actual &&
    cat <<EOF >expect &&
7
6
5
4
3
EOF
    test_cmp expect actual
    )

Cloning into bare repository '/home/mj/git/t/trash
directory.t5539-fetch-http-shallow/httpd/www/repo.git'...
remote: Counting objects: 15, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 15 (delta 0), reused 15 (delta 0)
Receiving objects: 100% (15/15), done.
Checking connectivity... done.
Cloning into 'clone'...
fatal: unable to access 'http://127.0.0.1:5539/smart/repo.git/': The
requested URL returned error: 403
not ok 2 - clone http repository
#
#        git clone --bare --no-local shallow
"$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
#        git clone $HTTPD_URL/smart/repo.git clone &&
#        (
#        cd clone &&
#        git fsck &&
#        git log --format=%s origin/master >actual &&
#        cat <<EOF >expect &&
#    7
#    6
#    5
#    4
#    3
#    EOF
#        test_cmp expect actual
#        )
#

Re: GSoC 2016: Microproject

[Duy Nguyen]

On Mon, Feb 22, 2016 at 5:30 PM, Mehul Jain <mehul.jain2029@gmail.com> wrote:
> On Mon, Feb 22, 2016 at 3:50 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> You may have an http server installed but not suitable for these
>> tests. Try running one test file alone with -v -i, e.g.
>> ./t5539-fetch-http-shallow.sh -v -i and post the output.
>
> Here's the output :-
>
> expecting success:
>     git clone --bare --no-local shallow "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
>     git clone $HTTPD_URL/smart/repo.git clone &&
>     (
>     cd clone &&
>     git fsck &&
>     git log --format=%s origin/master >actual &&
>     cat <<EOF >expect &&
> 7
> 6
> 5
> 4
> 3
> EOF
>     test_cmp expect actual
>     )
>
> Cloning into bare repository '/home/mj/git/t/trash
> directory.t5539-fetch-http-shallow/httpd/www/repo.git'...
> remote: Counting objects: 15, done.
> remote: Compressing objects: 100% (5/5), done.
> remote: Total 15 (delta 0), reused 15 (delta 0)
> Receiving objects: 100% (15/15), done.
> Checking connectivity... done.
> Cloning into 'clone'...
> fatal: unable to access 'http://127.0.0.1:5539/smart/repo.git/': The
> requested URL returned error: 403

OK server is up but very likely misconfigured. If you have experience
with http server before (I think this is apache), then you can dig in
t/lib-httpd.sh, study how the server is configured and try to fix it.

Alternatively, you can smiply skip http tests by setting environment
variable GIT_TEST_HTTPD to false before running the tests.
-- 
Duy

Re: GSoC 2016: Microproject

[Mehul Jain]

On Mon, Feb 22, 2016 at 4:51 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> OK server is up but very likely misconfigured. If you have experience
> with http server before (I think this is apache), then you can dig in
> t/lib-httpd.sh, study how the server is configured and try to fix it.

Thanks Duy. :)  All tests passed. I configured apache server to listen
to the ports tests were trying to access.

Thanks Lars. I tested on Traivs-CI, worked fine. :)

Mehul Jain

Re: GSoC 2016: Microproject

[Lars Schneider]

> On 22 Feb 2016, at 11:12, Mehul Jain <mehul.jain2029@gmail.com> wrote:
> 
> On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> The simplest way to get back on track for you is probably to start over
>> with a fresh clone, or (warning: destructive operations): use git clean
>> to remove untracked files.
> 
> Hello Matthieu,
> 
> I followed your advise and cloned a fresh copy of git source code.
> After compiling it and running the test with " prove --timer --jobs 15
> ./t[0-9]*.sh" command, I received tests failure. All these tests are
> regarding HTTP protocol being invoked like
> t5539-fetch-http-shallow.sh.
> 
> I'm behind a proxy server which blocks all ports except 80 and 443.
> Also my .gitconfig file is properly configured for proxy. Can these
> tests failure be triggered because of proxy server?
> 

Hi Mehul,

please try this:
https://github.com/git/git.github.io/commit/9754cb22aeacf37fe341c5b3fde88f2a79e0ea24

Cheers,
Lars

Re: GSoC 2016: Microproject

[Lars Schneider]

> On 22 Feb 2016, at 11:21, Lars Schneider <larsxschneider@gmail.com> wrote:
> 
> 
>> On 22 Feb 2016, at 11:12, Mehul Jain <mehul.jain2029@gmail.com> wrote:
>> 
>> On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>> The simplest way to get back on track for you is probably to start over
>>> with a fresh clone, or (warning: destructive operations): use git clean
>>> to remove untracked files.
>> 
>> Hello Matthieu,
>> 
>> I followed your advise and cloned a fresh copy of git source code.
>> After compiling it and running the test with " prove --timer --jobs 15
>> ./t[0-9]*.sh" command, I received tests failure. All these tests are
>> regarding HTTP protocol being invoked like
>> t5539-fetch-http-shallow.sh.
>> 
>> I'm behind a proxy server which blocks all ports except 80 and 443.
>> Also my .gitconfig file is properly configured for proxy. Can these
>> tests failure be triggered because of proxy server?
>> 
> 
> Hi Mehul,
> 
> please try this:
> https://github.com/git/git.github.io/commit/9754cb22aeacf37fe341c5b3fde88f2a79e0ea24
> 
Oops.. I am sorry. I should have read your email more closely. t5539 is not yet executed on Travis-CI...
But it wouldn't be too hard to add ;-)

Cheers,
Lars

Re: GSoC 2016: Microproject

[Mehul Jain]

On Fri, Feb 19, 2016 at 11:20 PM, Stefan Beller <sbeller@google.com> wrote:
> Yes, most likely t/t5521-pull-options.sh or t/t5520-pull.sh would be the right
> place as judging from the file name of the tests.

I checked out both of the files and made following observations -

1) As I'm going to add an option for "git pull --rebase"; tests should
be added for following commands in t/t5521-pull-options.sh
          a)  git pull --rebase --[no-]autostash
          b)  git pull -v --rebase --[no-]autostash
          c)  git pull -q --rebase --[no-]autostash

2) Also test for "pull --rebase --[no-]autostash fails with dirty
working tree and rebase.autostash set" should be added to
t/t5520-pull.sh.

Have I made the right observation?

Thanks,
Mehul Jain

GSoC 2016 Microproject

[Sidhant Sharma]

Hi everyone,


I'm Sidhant Sharma. I'm looking to participate in GSoC 2016 (and contribute  
to Git in general as well). I read up the pages relating to participation  
in GSoC and selected the microproject "Add configuration options for some  
commonly used command-line options". I have some queries regarding this  
though:

1. I believe the option can be added by a reassignment of the `verbose`  
variable in `parse_and_validate_options` function inside the  
`builtin/commit.c`. It can be a logical OR between the `verbose` (which was  
parsed by the argument parser) and the value obtained by using  
`git_config_get_bool("command.verbose", &opt_verbose)`. Am I thinking on  
the right lines?

2. Should I also add an option to override the configuration for verbose?

3. The microproject title suggests there can more such options, so are  
there more to be added?


Thanks in advance.



Regards

Sidhant Sharma [:tk]

Re: GSoC 2016 Microproject

[Matthieu Moy]

Sidhant Sharma <tigerkid001@gmail.com> writes:

> Hi everyone,
>
>
> I'm Sidhant Sharma. I'm looking to participate in GSoC 2016 (and contribute  
> to Git in general as well). I read up the pages relating to participation  
> in GSoC and selected the microproject "Add configuration options for some  
> commonly used command-line options".

There's already work in progress on this project, see the mailing list
the last few days.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016 Microproject

[Sidhant Sharma]

> There's already work in progress on this project, see the mailing list
> the last few days.
>

Okay, in that case, I'd like to try is the one titled "Make upload-pack
and receive-pack use the parse-options api". In that, I can take up
the `builtin/receive-pack.c` file. Would that be okay?


Thanks again.

Regards,
Sidhant Sharma [:tk]

Re: GSoC 2016 Microproject

[Matthieu Moy]

Sidhant Sharma <tigerkid001@gmail.com> writes:

>> There's already work in progress on this project, see the mailing list
>> the last few days.
>>
>
> Okay, in that case, I'd like to try is the one titled "Make upload-pack
> and receive-pack use the parse-options api". In that, I can take up
> the `builtin/receive-pack.c` file. Would that be okay?

I didn't see anything going on for this one, but you may want to
double-check with the ml's archives.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016 Microproject

[Sidhant Sharma]

Hi,
> I didn't see anything going on for this one, but you may want to
> double-check with the ml's archives.
>
I checked the archives and there doesn't seem to be any active work on this.
I made the required changes and ran the test suite. Though all the tests pass, there still are two queries I have.
First, I'm not quite sure what to put in the help message for the options (--quiet, --stateless-rpc, --advertise-refs and --reject-thin-pack-for-testing).
Second, regarding the reject-thin-pack-for-testing option, currently when the option is entered, `fix_thin` is unset (https://github.com/git/git/blob/master/builtin/receive-pack.c#L1736). But using `OPT_BOOL(...)` for the same, the variable would instead be set when the option is given. I think one solution can be to invert `fix_thin` after calling `parse_options`. Am I going right so far? Suggestions and corrections welcome.



Regards,
Sidhant Sharma [:tk]

Re: GSoC 2016 Microproject

[Sidhant Sharma]

Hi,
Should I make a patch for this and submit it for discussion on the mailing list?


Regards,
Sidhant Sharma [:tk]

Re: GSoC 2016 Microproject

[Matthieu Moy]

Sidhant Sharma <tigerkid001@gmail.com> writes:

> Hi,
>> I didn't see anything going on for this one, but you may want to
>> double-check with the ml's archives.
>>
> I checked the archives and there doesn't seem to be any active work on this.
> I made the required changes and ran the test suite. Though all the
> tests pass, there still are two queries I have.
> First, I'm not quite sure what to put in the help message for the
> options (--quiet, --stateless-rpc, --advertise-refs and
> --reject-thin-pack-for-testing).

They are currently undocumented. We sometimes have explicitly
undocumented options (PARSE_OPT_HIDDEN) when they are used only
internally to avoid polluting the end-user's UI.

In this case, the command is anyway not meant for end-users so I think
it would make sense to document them, but not necessarily within the the
microproject.

> Second, regarding the reject-thin-pack-for-testing option, currently
> when the option is entered, `fix_thin` is unset
> (https://github.com/git/git/blob/master/builtin/receive-pack.c#L1736).
> But using `OPT_BOOL(...)` for the same, the variable would instead be
> set when the option is given. I think one solution can be to invert
> `fix_thin` after calling `parse_options`. Am I going right so far?
> Suggestions and corrections welcome.

Or use OPT_SET_INT(..., 0) on a variable initialized to 1.

> Should I make a patch for this and submit it for discussion on the mailing list?

On this list, it is indeed often more efficient to say "here's what I'm
done. Any comments?" than "here's what I'm about to do".

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016 Microproject

[Sidhant Sharma]

>> First, I'm not quite sure what to put in the help message for the
>> options (--quiet, --stateless-rpc, --advertise-refs and
>> --reject-thin-pack-for-testing).
> They are currently undocumented. We sometimes have explicitly
> undocumented options (PARSE_OPT_HIDDEN) when they are used only
> internally to avoid polluting the end-user's UI.
>
> In this case, the command is anyway not meant for end-users so I think
> it would make sense to document them, but not necessarily within the the
> microproject.
So what may I put in the message parameter? I was thinking
perhaps the option itself, without hyphens. Would that be
correct?
>
>> Second, regarding the reject-thin-pack-for-testing option, currently
>> when the option is entered, `fix_thin` is unset
>> (https://github.com/git/git/blob/master/builtin/receive-pack.c#L1736).
>> But using `OPT_BOOL(...)` for the same, the variable would instead be
>> set when the option is given. I think one solution can be to invert
>> `fix_thin` after calling `parse_options`. Am I going right so far?
>> Suggestions and corrections welcome.
> Or use OPT_SET_INT(..., 0) on a variable initialized to 1.
Okay, will do that.
>> Should I make a patch for this and submit it for discussion on the mailing list?
> On this list, it is indeed often more efficient to say "here's what I'm
> done. Any comments?" than "here's what I'm about to do".
>
I'm really sorry, I'm not very familiar with mailing list etiquettes.
I'll keep that in mind :)



Thanks and regards,
Sidhant Sharma [:tk]

Re: GSoC 2016 Microproject

[Matthieu Moy]

Sidhant Sharma <tigerkid001@gmail.com> writes:

>>> First, I'm not quite sure what to put in the help message for the
>>> options (--quiet, --stateless-rpc, --advertise-refs and
>>> --reject-thin-pack-for-testing).
>> They are currently undocumented. We sometimes have explicitly
>> undocumented options (PARSE_OPT_HIDDEN) when they are used only
>> internally to avoid polluting the end-user's UI.
>>
>> In this case, the command is anyway not meant for end-users so I think
>> it would make sense to document them, but not necessarily within the the
>> microproject.
> So what may I put in the message parameter? I was thinking
> perhaps the option itself, without hyphens. Would that be
> correct?

If you use PARSE_OPT_HIDDEN, I think you don't need to specify a
message. Otherwise, the documentation only has value if it contains more
than just the option name, but that is the hard part if you're not
familiar with the code. The best place to find documentation is in the
history (git blame the file and see if the commit message introducing
the option enlightens you). But that's why I said this didn't have to be
part of the microproject: writting good doc requires a good
understanding of the whole thing ...

>>> Should I make a patch for this and submit it for discussion on the mailing list?
>>
>> On this list, it is indeed often more efficient to say "here's what I'm
>> done. Any comments?" than "here's what I'm about to do".
>>
> I'm really sorry, I'm not very familiar with mailing list etiquettes.
> I'll keep that in mind :)

No problem. It's OK to say what you do beforehand and to ask help. Just
don't be surprised when you don't get much feedback on message not
starting with [PATCH] ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: GSoC 2016 Microproject

[Sidhant Sharma]

> If you use PARSE_OPT_HIDDEN, I think you don't need to specify a message. Otherwise, the documentation only has value if it contains more than just the option name, but that is the hard part if you're not familiar with the code. The best place to find documentation is in the history (git blame the file and see if the commit message introducing the option enlightens you). But that's why I said this didn't have to be part of the microproject: writting good doc requires a good understanding of the whole thing ... 
I used OPT_HIDDEN_BOOL for all except for reject-thin-pack-for-testing, where I used PARSE_OPT_HIDDEN. I ran the test locally and also on Travis, and the all tests passed. How do I proceed now?



Thanks and regards,
Sidhant Sharma [:tk]

Re: GSoC 2016 Microproject

[Thomas Gummerer]

On 03/01, Sidhant Sharma wrote:
>
> > If you use PARSE_OPT_HIDDEN, I think you don't need to specify a message. Otherwise, the documentation only has value if it contains more than just the option name, but that is the hard part if you're not familiar with the code. The best place to find documentation is in the history (git blame the file and see if the commit message introducing the option enlightens you). But that's why I said this didn't have to be part of the microproject: writting good doc requires a good understanding of the whole thing ...
> I used OPT_HIDDEN_BOOL for all except for reject-thin-pack-for-testing, where I used PARSE_OPT_HIDDEN. I ran the test locally and also on Travis, and the all tests passed. How do I proceed now?

Now you can send a patch to the mailing list.  See
Documentation/SubmittingPatches for more details.

It usually is helpful to send the patches to yourself first as well,
and try to apply them using git am, to avoid mistakes in the patch
submission.

>
> Thanks and regards,
> Sidhant Sharma [:tk]
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
Thomas