Re: [PATCH v11 1/8] t/t5505-remote: set default branch to main

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

 



On Wed Oct 23, 2024 at 17:09, Taylor Blau <me@xxxxxxxxxxxx> wrote:
> On Tue, Oct 22, 2024 at 10:14:12PM +0200, Bence Ferdinandy wrote:
>>
>> On Tue Oct 22, 2024 at 21:53, Kristoffer Haugsbakk <kristofferhaugsbakk@xxxxxxxxxxxx> wrote:
>> > On Tue, Oct 22, 2024, at 21:45, Bence Ferdinandy wrote:
>> >> Consider the bare repository called "mirror" in the test.  Running `git
>> >> remote add --mirror -f origin ../one` will not change HEAD, consequently
>> >> if init.defaultBranch is not the same as what HEAD in the remote
>> >> ("one"), HEAD in "mirror" will be pointing to a non-existent reference.
>> >> Hence if "mirror" is used as a remote by yet another repository,
>> >> ls-remote will not show HEAD. On the other hand, if init.defaultBranch
>> >> happens to match HEAD in "one", then ls-remote will show HEAD.
>> >>
>> >> Since the CI globally exports GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main,
>> >> there's a drift between how the test repositories are set up in the CI
>> >> and during local testing. This issue does not manifest currently, as the
>> >> test does not do any remote HEAD manipulation where this would come up,
>> >> but should such things be added, a locally passing test would break the
>> >> CI vice-versa.
>> >>
>> >> Set GIT_TEST_DEFAULT_INITIAL_BRANCH_NAME=main in the test to be
>> >> consistent with the CI.
>> >> ---
>> >>
>> >> Notes:
>> >>     v9: - new patch
>> >>         - a bandaid for the CI issue noticed by Taylor (cf:
>> >>           https://lore.kernel.org/git/Zw8IKyPkG0Hr6%2F5t@nand.local/),
>> >> but
>> >>           see
>> >>
>> >> https://lore.kernel.org/git/D4ZAELFWJMKN.S88LJ6YK31LZ@xxxxxxxxxxxxxx/
>> >> for the root cause in detail
>> >
>> > Why no signoff?
>>
>> Because I always forget :( I've been thinking on making it by default, but
>> I didn't want to add it to all the work related commits, where I'd be the only
>> one doing it, but I just found the format.signoff setting, so I should be
>> covered for future patches.
>>
>> I'll wait some time before sending a fix for this :)
>
> Yeah, I was going to suggest format.signOff as well. If you don't want
> to add your S-o-b to work commits but do want to add it to patches you
> send to the Git list, you could just stop there (assuming that you don't
> use format-patch for work-related patches).

The projects I contribute to seem to have a bidirectional mapping of requiring
S-o-b and format patch so I should be good with this :)

>
> Alternatively, you could set it in your copy of git.git's own
> configuration in $GIT_DIR/config, so that it doesn't apply to work you
> do outside of that repository.
>
> Either way, I'm going to avoid queueing this round since it is missing
> the required Signed-off-by line.

In that case I'll send a v12 with the S-o-b so the series can get back into
circulation.

Best,
Bence

>
> Thanks,
> Taylor




-- 
bence.ferdinandy.com






[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]

  Powered by Linux