Re: GSoC 2016: Microproject

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx> wrote:
> On Fri, Feb 19, 2016 at 9:39 AM, Mehul Jain <mehul.jain2029@xxxxxxxxx> wrote:
>> On Fri, Feb 19, 2016 at 6:33 PM, Matthieu Moy
>> <Matthieu.Moy@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
>> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]