On Wed, 10 Oct 2007, Han-Wen Nienhuys wrote: > > I recall reading a few months ago that it was "clone -l" that gave you > the jeebies, rather than "clone -s". Yes, "clone -l" gives me the jeebies, because I'm a totally anal person when it comes to disk corruption and a worry-wart. I've just had it happen too many times (usually because a disk simply goes bad), and "git clone -l" basically means that if one repository gets corrupted, then so does the other one. But clone -s gives me even *more* jeebies, although I think it's in some respect also more useful. The alternates thing is really useful for servers in particular, where you basically want to have multiple "branches" maintained by lots of people, but all based on some expected base version. So if you think of alternates as a "kernel.org" or "repo.or.cz" thing, where you might have a hundred different repositories all based on the same "standard" version, then I think you basically have the right model. In that situation, "git clone -l" doesn't work that well, since the repositories just start out sharing data, but don't do it long term. So "git clone -l" (which is the default now - my jeebies really are my personal psychological problem) is really useful for latency reasons for a local clone, and has basically no real downsides. It's not useful for *backups*, but it's useful for development. > > So the rule really is: never *ever* do anything but fast-forward in a repo > >[..] > > Methinks this is all too difficult. I will use clone -l henceforth. Is > there any reason to prefer -s over -l? Good. And no, for actual *development* there is no reason to prefer -s over -l (and as mentioned, '-l' is the default in modern versions). For a git *server* setup, -s is better, since it's more long-term. But in that situation, it also requires that the server maintainer have some rules (ie only use "-s" for stable base trees and/or use extra care when repacking the base). > Given your lengthy exposition on the dangers of alternates, I would say > this is a features that deserves to be buried or at least deemphasized > in the documentation. I do agree. We should make the dangers very clear. > For cherrypicking convenience, I would still appreciate it if there > was a mechanism similar to alternates that would allow me to view > objects from an alternate repo; objects found through this mechanism > should never be assumed to be present in the database, of course. Well, the way that really should work is that you "git fetch remote" and work on the end result in a "remote branch". That *will* make the objects present in the database, but not in your actual branches (until you cherry-pick), but there really are no real downsides. If the remote is truly related to your local tree, it all delta's so well that the disk space issues should basically be none. Linus - 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
