Re: [RFC PATCH v3 2/2] t7406: add test for non-default branch in submodule

From: Eddy Petrișor <eddy.petrisor@gmail.com>
Date: Apr 19, 2018, 06:07 UTC
Message-ID: <CAK0XTWecZASWULXYXGauV5WKhYinD7HXyXSTJntocQt3vzr4AA@mail.gmail.com>
In-Reply-To: <CAGZ79kbT+AnVu-AJ9=OSt=Z2ErM5ocfoLfgx=qmHFfbnkqJqwg@mail.gmail.com>

2018-04-05 0:41 GMT+03:00 Stefan Beller <sbeller@google.com>:

Show 6 quoted lines

> On Wed, Apr 4, 2018 at 1:37 PM, Eddy Petrișor <eddy.petrisor@gmail.com> wrote:
>
>>> you plan to later submit as one patch including both the change as well as
>>> the test.
>>
>> Yes,

I did not forget about having a single patch. Will do it once the details are ironed out.

Show 20 quoted lines

>>>>> +       cd ../super5 &&
>>>>> +       echo super_with_2_chained_modules > super5 &&
>>>>> +       git add super5 &&
>>>>> +       test_tick &&
>>>>> +       git commit -m "commit on default branch in super5" &&
>>>>> +       git submodule add ../submodl1b1 submodl1b1 &&
>>>>> +       git config -f .gitmodules submodule."submodl1b1".branch b1 &&
>>>>> +       git add .gitmodules &&
>>>>> +       test_tick &&
>>>>> +       git commit -m "add l1 module with branch b1 in super5" &&
>>>
>>> now we do this again without the nested submodule, just one repo
>>> as a submodule?
>>
>> My intention was to have super5 -> submodl1b1@b1 -> submodl2b2@b2 on
>> the "server" side.
>> But are you saying I just implemented super5 -> sbmodl1b1@master due
>> to the previous master checkout in submodl1b1?
>
> No. I was a little confused about the code.

Actually you were 100% correct. In order to link to submodl1b1@b1 I had to move the master branch checkout after the submobl2@b2 is added.

Otherwise the submodule is added with the last commit on master, not the last one on b1 an b2, respectively.

I suspect that in the tests, because the "server side" repos are local, the git fetch-by-sha1/cloning by hash will be done correctly, without the need of a branch hint, but the problem will still exist for servers such as github which do not support fetch-by-sha1. In case I realize that a server-side repo that doesn't support fetch-by-sha1 is needed, is there a mechanism to set that up in the test case, or do I have to rethink my approach?

Show 11 quoted lines

>>>>> +       git submodule init submodl1b1 &&
>>>>> +       git clone super5 super &&
>>>
>>> does super exist here already? (I did not check, but IIRC
>>> super and super{1-4} are there as we count upwards to
>>> find a name that is ok.
>>
>> I created it in the first step of the test with the intention to have
>> super5 as the "server" and "super" as the client clone.
>
> oh, ok.

After using test_pause I realized 'super' is left over by some other test cases, so in my v4 (unjustifibly) long series I switch to using super_w because I was getting all sorts of issues and wanted to not interfere with the other tests.

>> As a general idea for a test, does it look sane?
>
> Yes, I think it is a sane approach. Thanks for writing such a test!

OK, thanks for the feedback.

Show 6 quoted lines

>> Do you think I should I start with a just one level of submodule with
>> a non-default branch (super -> l1@b1), or it this OK?
>> In my view, having 2 levels makes sure the recursive part is also
>> addressed and verified.
>
> I totally agree.

-- 
Eddy Petrișor