RE: [RFC PATCH v3 0/7] Introduce clar testing framework
- From
rsbecker@nexbridge.com <rsbecker@nexbridge.com>
- Date
- Aug 12, 2024, 20:58 UTC
- Message-ID
- <033401daecfa$773fa5d0$65bef170$@nexbridge.com>
- In-Reply-To
- <xmqqy151zcsc.fsf@gitster.g>
On Monday, August 12, 2024 4:50 PM, Junio C Hamano wrote:
Show 20 quoted lines
>Josh Steadmon <steadmon@google.com> writes: > >> I'm generally in favor of this change, but I'm still unsure what our >> plan is for importing this from upstream clar. Are we going to vendor >> our own copy here and (hopefully) someone will pay attention to >> upstream fixes and apply them to our copy? Or will we replace this >> with a submodule? > >As long as we do not have to make any changes to the "vendored" code ourselves, >that would not matter. We will not randomly update the gitlink that specifies "we >want to use _this_ version and not other version of upstream clar" without good >reasons if you are using it as a submodule, and we would need to justify why we >are updating the hierarchy if we import the hierarchy as vendored source. So the >hassle of "updating from upstream" is pretty much the same. > >For something as small as "clar", I think it is fine to start with the currently proposed >layout and see what happens. If we can keep going without touching the imported >part of the sources at all, and the system proves to be useful and stable, that is a >good time to suggest moving it out and binding the selected version of the >upstream as a submodule.
I think we already have a copy customized for git's use. The main clar repo on its own has portability issues. I have contributed a few fixes, but they need work.