On Mon, Jul 7, 2014 at 3:46 AM, Max Kirillov <max@xxxxxxxxxx> wrote: > Hi. > > What future does this have? Currently it is marked as > "Stalled", but still mergeable with some trivial conflicts > and seem to be working (except some bugs in interaction with > submodules, see below). It would be very nice if this > feature is officially supported. It's to be re-rolled soon. I have a patch about sparse-checkout and Dennis may contribute another one to enable "checkout --to" from a bare repository. By the way Dennis has been testing this feature and he reported (off-list) it worked fine, which is good news. I have done nothing so far because my git time (or energy to be precise) is limited these days, and I wanted to see if Dennis reported any new bugs. > I also have a comment about how it interacts with submodules. > Would it be more appropriate to mark "modules" as a > per-checkout directory? Because each of the working tree's > submodule is obviously a separated directory in filesystem, > and in most cases (at least in my practice) they are > checked-out to different revisions. Submodule interaction is something I have avoided so far because I'm not a big user and admittedly does not follow its development closely. I think we could get this in first, then let submodule people aware about this feature and let them decide how to use it. > So, currently (before proper linking of submodules checkouts > implemented), if make submodules per-checkout (actually it > appears to somehow work even with current code, maybe > because some submodule code ignores the common_dir), one > could run "git submodule update" if necessary, and get fully > separated clones, which would work normally. > > It still may break if submodules are removed, added or > renamed, but this seems to be inevitable until config is > separated to per-checkout and common parts, which I suppose > is a much bigger task. -- Duy -- 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