Hi Ævar, I originally replied in a very verbose manner, going step by step through the "one-liner", but decided to rephrase everything. So here goes. On Sat, 13 May 2017, Ævar Arnfjörð Bjarmason wrote: > Let's drop this current gawk import series. Well, the reason why you imported the current gawk regex is that we (you?) decided originally that it'd be easier to go with that one rather than with the gnulib one (which they friendly-forked). If you switch to gnulib, I would like to see (in the commit message) the original reason we picked gawk (which forked gnulib's regex code, after all), and why that reason no longer applies. I also would strongly prefer a *non* one-liner, in a commit message that adds the relevant source code from gawk or gnulib *verbatim*, followed by patches that adjust the code to Git's needs. That way, a future update can repeat the commands outlined in the first commit message and then cherry-pick the subsequent patches. And remember that you do not need to clone the entire repository. You can 1) fetch into the current one, and 2) use a shallow fetch. Example: git fetch --depth 1 http://git.savannah.gnu.org/r/gawk.git \ gawk-4.1.4 The next commands could be something like git read-tree --prefix=compat/regex/ FETCH_HEAD: git clean -dfx -- compat/regex/ Oh, and please do not use `master`. If Git is any indication, a tagged release will most often be a bit more robust than any in-between commit. Thanks, Dscho