GSoC 2016: Microproject

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

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:

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

On Fri, Feb 19, 2016 at 6:33 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

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

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

On Fri, Feb 19, 2016 at 9:39 AM, Mehul Jain <mehul.jain2029@gmail.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, Stefan

On Fri, Feb 19, 2016 at 11:20 PM, Stefan Beller <sbeller@google.com> wrote:

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

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:

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

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

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

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

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

On Sun, Feb 21, 2016 at 10:25 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

I apologize for top-posting on the list.

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

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

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.

On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

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.

On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

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

On Mon, Feb 22, 2016 at 5:12 PM, Mehul Jain <mehul.jain2029@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.

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

On Mon, Feb 22, 2016 at 3:50 PM, Duy Nguyen <pclouds@gmail.com> wrote:

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 # ) #

On Mon, Feb 22, 2016 at 5:30 PM, Mehul Jain <mehul.jain2029@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.

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

On Mon, Feb 22, 2016 at 4:51 PM, Duy Nguyen <pclouds@gmail.com> wrote:

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

Hi Mehul,

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

Cheers, Lars

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

On Fri, Feb 19, 2016 at 11:20 PM, Stefan Beller <sbeller@google.com> wrote:

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