Here are random things that I'd like to see happen during 1.5.3
cycle.
* git-clone should become a very thin wrapper around
init/remote/fetch/checkout.
- it may be necessary to teach git-remote about --bare
layout.
- by getting rid of 'fetch' logic from git-clone as much as
possible, it would hopefully become easier to freeze what
git-fetch needs to do and help rewriting the latter in C.
- update native protocol with an extension to carry which
branch HEAD (or any symref) points at, instead of guessing.
We already know this information when clone is done over
HTTP, but we are discarding that information in git-clone
for the sake of implementation simplicity and having it
also guess.
* more superproject support in Porcelain-ish.
- superproject support in Porcelain-ish is mostly about
checking things out. One possible scenario:
$ git clone --recursive $url_of_superproject
may instruct "clone that, and also clone any projects that
the superproject uses, and check everything out". I would
imagine that lThis would be carried out in the following
steps.
(1) The usual "git-clone" dance, determining the directory
name to create, running mkdir and init-db, setting up
tracking refspec specification in the config, and
running the initial fetch.
(2) Because the command was not given '-n' ("do not
checkout"), HEAD is checked out. git-checkout notices
that there are commits bound to some directories in its
tree.
(3) git-checkout finds there is .gitmodules file in the
tree (and the checked-out working file), which
describes these subprojects. It looks at the config
and notices that it does not yet know about them
(obviously this is true, as this is the first checkout
after clone, but I am trying to outline how checkout
after a merge should work in the general case).
It determines where to fetch that subproject from,
perhaps it uses the default URL described in
.gitmodules file to, while asking the user for
confirmation and giving the user a chance to override
it. And it records something in the config -- now that
project is known to this repository.
(4) git-checkout then calls git-clone recursively in that
subdirectory for the subproject (which may further
contain subprojects of its own, but that would
naturally work).
- Another scenario, after "git clone" of the superproject
_without_ the above "--recursive" behaviour. There needs
to be a way to later clone and checkout a named subproject
(and that subproject alone). Perhaps
$ git checkout --populate-subproject subdir
would notice that subdir corresponds to a subproject that
is "not known" to this repository.
I am assuming .gitmodules from the upstream describes it,
but the default is not to recurse into any subproject,
which would leave the subdir _without_ its own .git
directory. A subproject becomes "known" to your repository
when you tell git that you care about it (e.g. "clone
--recursive" above), and that decision would be recorded
somewhere in .git/config of the superproject. .gitmodules
would give the default URL and probably the branch to
follow. The URL definitely needs to be overridable by
per-repository configuration as network reachability would
be different for everybody; I am not sure about the need to
make it overridable which branch the subproject should
follow, but my gut feeling is that we do not have to.
Then it does the same as (3) and (4) in "clone --reference"
above (in fact, I am envisioning that that scenario would
call "git checkout --populate-subproject" in those steps).
- We might want to have a way to tell it to stop tracking an
already "known" subproject, which means that the section in
.git/config that would track the status of the subproject
(e.g. "is it known", "what's the URL", etc.) needs another
variable that says "are we still interested in it?".
- There may be obvious "frills" we would want to eventually
have, such as defaulting the repository to find the
subproject that corresponds to subdir/ to $URL/subdir (iow
if http://repo.or.cz/cgit.git binds git.git at its src/
directory, we would expect that the repository to house
that subproject is found at http://repo.or/cz/cgit.git/src
by default), but during the first round, I think it is
better to leave things explicit. So, for the above
example, instead of defaulting the $URL/$subdir location,
always require .gitmodules to say where to fetch the
subproject from.
- "git diff", "git status" and friends might want to learn
recursive behaviour. These should be much easier than any
of the above.
Note: I am not trying to dictate the overall superproject
Porcelain design should follow the above literally, but just
throwing out a strawman. As I do not expect to be a heavy
user of superproject support myself yet, other people who
have thought about the problem longer (much longer) than I
have will certainly have better ideas.
* Perhaps add 'tree' entries in the index. This may make the
current cache-tree extension unnecessary, and I suspect it
will simplify various paths that deal with D/F conflicts in
the current codebase.
I suspect this might need 1.6, as it is a one-way backward
incompatible change for the 'index', but 'index' is local so
it might not be such a big deal. In the worst case, when the
users find "git checkout" from 1.5.2 does not work in a
repository checked out with such an updated index format, we
could ask them to "rm -f .git/index && git checkout HEAD".
* make merge-recursive and read-tree -u more robust when D/F
conflict is involved.
I think that the use of current_{file,directory}_set is
misguided and it should just ask the index if there are
conflicts. unpack-trees.c::check_updates() logic probably is
the right place to deal with what to do with the working tree
when the merge result contains D/F conflicts (i.e.
merge-recursive wants to create file~branchname instead of
not touching the working tree).
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
