Re: [PATCH v3 0/9] Get rid of "git --super-prefix"

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

 



Thanks! I think we're close to getting this merged :)

Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:

> = Changes since v2:
>
> * Fixes for test_when_finished() in test setup, and got rid of
>   redundant test_config_global.
>
> * There's a new 2/9, which passes along get_super_prefix() as a
>   parameter. This allows us to gradually replace it, and drop the
>   *_sp() variants of functions that the previous version introduced,
>   and it adds "super_prefix" to the absorb_git_dir_into_superproject()
>   call in submodule_move_head(), which as Glen noticed I'd missed
>
> * Squashed the "deinit" change into that 2/9.
>
> * Explain why we keep the "fsmonitor" test bits that we do.
>
> * Dropped the new "git branch" output tests, turns out I was just
>   wrong, and was conflating it with the subsequent read-tree
>   invocation...
>
> So, this should address all outstanding feedbakc, unless I've missed
> something.

As noted in [1], I think we might have missed some sites where we should
pass super_prefix.

[1] https://lore.kernel.org/git/kl6lcz9eep9k.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx,

> The one loose end here is that I still have no idea if you can invoke
> get "read-tree" to invoke that submodule_move_head() in such a way as
> to have the "super_prefix" used, I've failed to come up with a test
> case for that.
>
> But for the purposes of this topic it doesn't really matter. In 8/10
> we'll start passing the new "--super-prefix" that "read-tree" gets
> down to that function. At worst we're handing it to it redundantly,
> but that was the case before too.
>
> So we can leave potentially turning that into a "NULL" for some other
> time, for now providing the "super_prefix" is harmless, and guarantees
> that we avoid any regression in that area from not providing it, in
> case I've missed a way to have it matter in that case.

Yeah, I tried to do the same too, and it turned out to be harder than
expected. The "absorbgitdir during read-tree" code is definitely in use
(e.g. by t1013), so it's certainly possible, but as you noted, I don't
really think it matters as long as we avoid a regression for the time
being.





[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