On Wed, Nov 09 2022, Taylor Blau wrote: > On Wed, Nov 09, 2022 at 08:34:28PM +0100, Ævar Arnfjörð Bjarmason wrote: >> An RFC alternative to Glen's [1], and what I *thought* he might be be >> going for in the earlier discussion[2]. > > I am a little puzzled with what to do with this series. For one, it > doesn't seem to apply cleanly on top of 'ab/remove--super-prefix': > > $ git log --oneline -1 > 04e36effde (HEAD -> ab/remove--super-prefix) Merge branch 'ab/submodule-helper-prep-only' into ab/remove--super-prefix > > $ git am -sc3 ~/patch > Applying: submodule--helper: don't use global --super-prefix in "absorbgitdirs" > error: sha1 information is lacking or useless (submodule.c). > error: could not build fake ancestor > Patch failed at 0001 submodule--helper: don't use global --super-prefix in "absorbgitdirs" > hint: Use 'git am --show-current-patch=diff' to see the failed patch > When you have resolved this problem, run "git am --continue". > If you prefer to skip this patch, run "git am --skip" instead. > To restore the original branch and stop patching, run "git am --abort". My bad, the CL says: and can make use of (but doesn't need) the better test coverage for "absorbgitdirs" that I submitted in [3] (https://lore.kernel.org/git/patch-1.1-34b54fdd9bb-20221109T020347Z-avarab@xxxxxxxxx/)". But it actually *does* need that, sorry. But with that, this works for me: git checkout master git reset --hard @{u} git merge --no-edit ttaylorr/ab/submodule-helper-prep-only (apply https://lore.kernel.org/git/patch-1.1-34b54fdd9bb-20221109T020347Z-avarab@xxxxxxxxx/) Then apply this series. I've also got it at https://github.com/avar/git/tree/avar/nuke-global-super-prefix-use-local; but that's a locally rebased version of ab/submodule-helper-prep-only, then that [3], and finally this series. I figured I was just kicking ideas back & forth with Glen, so I didn't go through my usual sanity checking :) > But it would be nice to have a clearer path forward between this and > Glen's series. I understand that they are both still RFCs, but I am > counting on you two working together to find a path forward that is > satisfactory to you both. *nod*, I'm sure we can manage that.
