On Thu, Jan 28, 2010 at 02:22:20AM +0100, Pau Garcia i Quiles wrote: > - automagically clone submodules when I clone the repository > containing submodules (i. e. no need for git submodule init) > git clone recently gained the --recursive option.
> - be able to stick to the tip (HEAD, instead of a certain revision > which I have to manually update) > this sounds like just specifying a ref instead of a sha1. doesn't it already work? anyway, the problem with this is that it is basically impossible to get a consistent untagged checkout from the past then, i.e., one cannot get even pseudo-atomicity. this is a real problem; i've experienced it myself with the xorg repo (which has no meta structure at all, afaik). this should be solvable by using the remote reflog by timestamp, but afaik this is currently impossible, and keeping an indefinite reflog in its current form wouldn't scale at all anyway (it's just a flat text file). the theoretically right solution would be actually locking the affected repositories between the final pull [--rebase] and the push and auto-updating the supermodules up to the top level. however, this wouldn't scale too well, as the higher-up modules would be pretty contended. maybe it would work if multi-repo commits would record their requirement for an atomic push up to a certain level explicitly, and the higher-up modules would be updated non-atomically. of course, this would require a whole new infrastructure in git, involving persistent connections for multiple operations, etc. ... _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
