Re: [PATCH v4 0/8] git doc + "git help": move "format" docs from technical/*

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

 



On Mon, Jul 18 2022, Ævar Arnfjörð Bjarmason wrote:

> On Mon, Jul 18 2022, Junio C Hamano wrote:
>
>> Ævar Arnfjörð Bjarmason  <avarab@xxxxxxxxx> writes:
>>
>>> This series improves the discoverability of the technical/*
>>> documentation covering those "formats" where we interact with users
>>> (e.g. "gitattributes") by moving them to its own "git help" category.
>>>
>>> It then moves various technical documentation from technical/* to our
>>> main documentation namespace, allowing us to cross-link e.g. from
>>> "git-bundle(1)" to a new "gitformat-bundle(5)".
>>
>> This may be a good direction to go in in the longer term, but there
>> are already topics in flight that change these documents.  Luckily
>> none in 'next' yet, but there are two that have been in 'seen' and
>> need to coordinate with this change.
>
> The v4 merges cleanly for me, unless there's a semantic conflict you've
> spotted that I've missed.
>
> But I assume you mean a "seen" you haven't pushed out yet, which
> includes SZEDER's change here:
> https://lore.kernel.org/git/220718.86cze2y22q.gmgdl@xxxxxxxxxxxxxxxxxxx/
>
> I sent out the v3 with a merge resolution for the only conflict at the
> time:
> https://lore.kernel.org/git/cover-v3-0.7-00000000000-20220712T195419Z-avarab@xxxxxxxxx/
>
> But as noted in the v4 CL I thought I'd make even that trivial conflict
> go away in v4, but it looks like I'll need to roll a v5.
>
> I don't want to make it a hassle for you to carry this topic, and I have
> waited a few months to submit this, as there were always various
> Documentation/technical/ changes in-flight.
>
> Would you prefer to have this entirely conflict free, or to have me
> solve the (small) conflicts locally and note the resolution (per
> --remerge-diff) in the CLs?

FWIW this merges cleanly with "seen" due to the magic of "git merge",
i.e. even with the rename we resolve the conflict with SZEDER's work
smoothly.

But there's other reasons to re-roll, just say'n for when you eventually
(hopefully) pick up such a re-roll ...




[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