Re: [PATCH 5/6] Teach "fsck" not to follow subproject links

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

 



Linus Torvalds wrote:

Yes.

The issues for hosting sites are very different from the issues of individual developers having their own git repositories, and I agree 100% that both alternates and shared object directories make tons of sense for hosting.

Below I talk about a possible way we could use git
without changing it (since I recognize this would be a minority usage
pattern).

I hope it wouldn't even be a minority usage pattern. I am a firm believer that distributed SCM's and git in particular makes a lot more sense for source control hosting than CVS or SVN do. I'm really disappointed with things like sourceforge, and part of the problem is literally that a centralized SCM is really *fundamentally* wrong for a hosting entity. Using a distributed SCM just makes _so_ much more sense for hosting projects, and I've actually very much wanted to try to make sure that git can help people who host things.


And btw, I think the shared object model really works very well, but I think it has to be paired with some stricter rules than people who use their own repos tend to have. For example, end-point developers have become very used to rebasing and generally rewriting history (or just resetting to an older state), and that's something that works find in a "local repository" setup, but it's also the kinds of patterns that can really screw you in a hosted and shared-object environment.


Would it not make sense for a hosting environment to say, if you are using alternates, or shared object directories, then you need to include *all* the refs in *all* the projects if you ever do an fsck?

I'm not sure how well git will scale in this case, although it just should be a matter of how well git scales to dealing with a single project with tens of thousands of refs/tags/etc. The only problem might be in passing all those refs/tags to fsck in one go. STDIN, I guess?

Rogan
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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]