GSoC 2016: Microproject

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Matthieu Moy-2
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 <[hidden email]> 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Mehul Jain
On Fri, Feb 19, 2016 at 6:33 PM, Matthieu Moy
<[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Stefan Beller-4
On Fri, Feb 19, 2016 at 9:39 AM, Mehul Jain <[hidden email]> wrote:

> On Fri, Feb 19, 2016 at 6:33 PM, Matthieu Moy
> <[hidden email]> 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 [hidden email]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Mehul Jain
On Fri, Feb 19, 2016 at 11:20 PM, Stefan Beller <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Mehul Jain
In reply to this post by Stefan Beller-4
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 <[hidden email]> wrote:

> On Fri, Feb 19, 2016 at 9:39 AM, Mehul Jain <[hidden email]> wrote:
>> On Fri, Feb 19, 2016 at 6:33 PM, Matthieu Moy
>> <[hidden email]> 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 [hidden email]
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

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

Mehul Jain <[hidden email]> 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Mehul Jain
In reply to this post by Stefan Beller-4
On Fri, Feb 19, 2016 at 11:20 PM, Stefan Beller <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Mehul Jain
In reply to this post by Matthieu Moy-2
On Sun, Feb 21, 2016 at 10:25 AM, Matthieu Moy
<[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Matthieu Moy-2
Mehul Jain <[hidden email]> 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Karthik Nayak
On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy
<[hidden email]> wrote:

> Mehul Jain <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Mehul Jain
In reply to this post by Matthieu Moy-2
On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy
<[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Duy Nguyen
On Mon, Feb 22, 2016 at 5:12 PM, Mehul Jain <[hidden email]> wrote:

> On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy
> <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

larsxschneider
In reply to this post by Mehul Jain

> On 22 Feb 2016, at 11:12, Mehul Jain <[hidden email]> wrote:
>
> On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy
> <[hidden email]> 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--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Mehul Jain
In reply to this post by Duy Nguyen
On Mon, Feb 22, 2016 at 3:50 PM, Duy Nguyen <[hidden email]> 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
#        )
#
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

larsxschneider
In reply to this post by larsxschneider

> On 22 Feb 2016, at 11:21, Lars Schneider <[hidden email]> wrote:
>
>
>> On 22 Feb 2016, at 11:12, Mehul Jain <[hidden email]> wrote:
>>
>> On Mon, Feb 22, 2016 at 12:22 AM, Matthieu Moy
>> <[hidden email]> 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--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Duy Nguyen
In reply to this post by Mehul Jain
On Mon, Feb 22, 2016 at 5:30 PM, Mehul Jain <[hidden email]> wrote:

> On Mon, Feb 22, 2016 at 3:50 PM, Duy Nguyen <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|

Re: GSoC 2016: Microproject

Mehul Jain
On Mon, Feb 22, 2016 at 4:51 PM, Duy Nguyen <[hidden email]> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html