Re: Mozilla version control requirements and git

[Junio C Hamano <junkio@cox.net>]

"Jon Smirl" <jonsmirl@gmail.com> writes:

> Partial repo pulls and an issue to. The mozilla repo has much more
> than a browser in it, it also has a large mail/news program. A partial
> repo pull may not be what is needed for git, instead git needs a
> partial repo checkout.

That does not contradict with the underlying data model of git,
and it would certainly be possible with a specialized Porcelain.

Since git tracks the entire tree, the tree object contained in
the commit you create _must_ describe the entire project tree,
but that does not necessarily mean that your working tree needs
to have the entire tree checked out.

The git corelevel is designed to be operable with sparsely
populated working tree, and the problem you are seeing is
primarily coming from the fact that some wrappers you are seeing
as "git UI" are specifically done to help workflows that _wants_
to have fully populated working tree (e.g. "git commit -a" and
"git checkout").  There are other wrappers that are designed to
work well in sparsely populated working tree, including "git-am"
and "git-merge".  They should be usable pretty much as they are.

To support "narrow checkout" workflow, some wrappers either need
to be told about the "interesting area", or a set of different
wrappers specifically designed to support "narrow checkout"
workflow can be written.  I am not sure which is more desirable.
I have a gut feeling that "git commit" can be used as is (you cd
into the area you are interested in, and say "git commit ."
instead of saying "git commit -a"), while it would be less
confusing to keep "git checkout" the whole-tree operation and
have a specialized porcelain for a narrow checkout, but this is
me saying things without thinking things through.

I imagine such a "narrow checkout" workflow Porcelain would work
like this:

 - the user tells it which parts of the whole project she is
   interested in.

 - when checking things out, the Porcelain populates the index
   in full [*1*] and then checks out only specified subtrees to
   the working tree.

 - when checking things in, the changes outside the specified
   area are ignored (well, outside there should be no files in
   working tree so ignoring them should be trivial).  write-tree
   writes from the whole index and creates the tree object and
   then commit object just as usual.  The net effect is that the
   parts outside the areas of interest stay the same as the
   previous HEAD commit, which is exactly what the user wanted
   anyway.

You could optimize the above further by populating the index
sparsely as well (i.e. *1* above is not a requirement), but you
would need to merge in the changes made to that sparse index
into the full tree read from the HEAD commit before writing the
next tree object out anyway, so I doubt it is worth it.


-- 
VGER BF report: U 0.842228