On Mon, Jul 7, 2014 at 3:46 AM, Max Kirillov <m...@max630.net> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to