Re: [3/4] What's not in 1.5.2 (new topics)

From: Junio C Hamano <junkio@cox.net>
Date: May 19, 2007, 19:56 UTC
Message-ID: <7vejlcwpry.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070519181228.GP4708@mellanox.co.il>

"Michael S. Tsirkin" <mst@dev.mellanox.co.il> writes:

Show 7 quoted lines

>> Fetching from a new URL (not just "different from what is
>> defined in .gitmodules") is a major deal from security point of
>> view (you should not fetch from stranger you do not trust).
>
> I'm sorry, I'm confused. I thought the "URL" in .gitmodules
> is just a unique project key/name? So how come you are now
> speaking about fetching from it?

Sorry for confusing you. The point was by default that we should not blindly follow URL given from upstream -- the statement you quoted is one justification why my strawman uses the URL in .gitmodules as a mere hint and look-up key.

Having said that, I'd ask not to take minor details in the strawman too literally and seriously. I am 100% sure that we would be in a serious trouble if what we end up doing matches literally what my handwaving strawman suggested. The strawman was thrown out to the open primarily so that (smarter and more beautiful) people who thought the issues longer and harder to express their opinions easier by having something to compare their unique ideas against, nothing more.

I am slightly more than 50% sure that we would not want to tie subproject fetch/clone into superproject fetch/clone, and _if_ we would tie it to anything, it would be to the checkout, but that is only my gut feeling. Maybe we end up not tying subproject fetch/clone to anything that happens in the superproject; we may even do it in a completely different way than the strawman said it _might_ work. That's perfectly fine.

The expectation from me sending out that handwaving strawman was to help encouraging others to present their ideas, with justifications. And having something to compare against, even if it is just a handwaving strawman, is often much easier when presenting your ideas and showing which part of your design is important. You can say something like "the strawman fails in this scenario, which is important in real life for such and such reasons, and my design handles it this way" -- and everybody can discuss if it is an important design consideration, and what the best design to solve that problem if it is.

So don't take that strawman, especially the details in it, too seriously, but take it as what it was: a firestarter.