Re: [PATCH v2 4/4] promisor-remote: teach lazy-fetch in any repo

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

 



Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes:

>> Jonathan Tan <jonathantanmy@xxxxxxxxxx> writes:
>> 
>> >> by filling appropriate environ[] array to be run in a repository
>> >> that is different from ours (which is "other repo" part of its name)
>> >> not to want to even know which repository the "other" repo is?
>> >
>> > Good point. I'll update prepare_other_repo_env() to have a gitdir
>> > parameter.
>> 
>> I actually meant that the function should take an in-core "repo"
>> structure.
>
> But that seems like we're passing much more than we need - we only need
> the git_dir. Also, there is a function that wants to pass a literal "."
> as the gitdir; if we do this, I'll have to check if there is still a
> struct repository that we can pass that will result in the same gitdir.

OK.  If the caller at the point does not have anything but git-dir,
there may not be much point in instantiating a full in-core repo
structure to pass to prepare_other_repo_env() to it.  If the helper
needs to learn more about that repository, it can go from the
git-dir and do things itself.

>> >> Object type and object sizes are something that you can
>> >> safely express in plain text, would be handy for testing, and would
>> >> not require too much extra code, I'd imagine.
>> >
>> > It would, but we can already use "git cat-file -s" (or -t) for that. The
>> > helper is meant to test a specific code path wherein we access a
>> > submodule object during a process running in the superproject.
>> 
>> I know, but can you use "git cat-file -s" to check the codepath you
>> care about?  I do not think so.  Hence the suggestion.
>
> I'm still not convinced that we'll need it in the future, but you're
> right that it is not too much trouble. I'll add it in.

As your answer to my initial question was that this is purely a
stop-gap testing measure until we get the support fully plumbed in
so that the real-world codepath can be tested end-to-end, I do not
think it matters all that much.  If it is easy to add, I suspect
that it would help to catch more bugs, but I wouldn't lose sleep if
it doesn't get added.

Thanks.



[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