Re: [PATCH v3] checkout: optimize "git checkout -b <new_branch>"

[Duy Nguyen <pclouds@gmail.com>]

On Thu, Aug 30, 2018 at 7:22 PM Elijah Newren <newren@gmail.com> wrote:
>
> Hi Duy,
>
> On Tue, Aug 21, 2018 at 7:52 AM Duy Nguyen <pclouds@gmail.com> wrote:
> >
> > On Mon, Aug 20, 2018 at 8:16 PM Elijah Newren <newren@gmail.com> wrote:
> > > Playing with sparse-checkout, it feels to me like a half-baked
> > > feature.  It seems like it required too much manual work, and it was
> > > sometimes hard to tell if I was misunderstanding configuration rules
> > > or I was just running into bugs in the code.  I think I hit both but I
> > > didn't really want to get side-tracked further, yet.  (I do want to
> > > eventually come back to it.)  The only reason someone would go through
> > > that pain is if it provided massive performance benefits.
> >
> > In my defense it was one of my first contribution when I was naiver
> > and basically an evolution of "git update-index --assume-unchanged". I
> > have something in the queue to improve/complement sparse-checkout but
> > my last update on that branch was 2.5 years ago, so it's not coming
> > soon.
> >
> > I'd love to year how sparse checkout could be improved, or even
> > replaced. I think we still have to have some configuration rules, and
> > yes the flexibility of sparse checkout (or gitignore to be precise)
> > rules is a double-edged sword.
>
> Sorry for taking a while to respond, and if what I said came across
> harshly.  I agree that the flexibility of the rules makes it more
> complicated, though I think a bigger issue may be that the feature is
> hard to make smooth unless coupled to something like partial clones.

For something like partial clones, we would need something like
partial indexes. That is, the index does not record all paths in
worktree. The problem is at write-tree time, how to create trees with
such a partial index. So far the only option I see is record
directories in the index (in the same way we record submodule's
commit), which reduces the index and we are still able to create trees
from it.

> Work on that is ongoing.  Anyway, in an attempt to be helpful, here
> were some of the pain points I ran across:
>
> ..

Thanks. I think this basically boils down to no good UI (and user
facing command also gives us a man page to describe stuff instead of
hiding everything behind git-read-tree.txt). This is something I've
been meaning to do but never got around to (also a couple of sparse
checkout optimizations). There's also "git sparse-checkout" [1] that
would be a good starting point for this, but I don't think the author
got to the point to submit it to git.

[1] https://github.com/kjp/git-tools/blob/master/git-sparse-checkout
-- 
Duy