From: Junio C Hamano <junkio@cox.net>
To: git@vger.kernel.org
Subject: [3/4] What's not in 1.5.2 (new topics)
Date: Wed, 16 May 2007 15:47:15 -0700 [thread overview]
Message-ID: <11793556371774-git-send-email-junkio@cox.net> (raw)
In-Reply-To: <11793556363795-git-send-email-junkio@cox.net>
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).
next prev parent reply other threads:[~2007-05-16 22:47 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-16 22:47 [0/4] What's not in 1.5.2 (overview) Junio C Hamano
2007-05-16 22:47 ` [1/4] What's not in 1.5.2 (have been cooking in next) Junio C Hamano
2007-05-16 22:47 ` [2/4] What's not in 1.5.2 (will cook " Junio C Hamano
2007-05-16 22:47 ` Junio C Hamano [this message]
2007-05-17 4:39 ` [3/4] What's not in 1.5.2 (new topics) Andy Parkins
2007-05-17 5:21 ` Junio C Hamano
2007-05-17 7:51 ` Andy Parkins
2007-05-17 11:02 ` Alex Riesen
2007-05-17 12:46 ` Petr Baudis
2007-05-17 13:46 ` Jeff King
2007-05-17 16:10 ` Petr Baudis
2007-05-17 16:25 ` Jeff King
2007-05-17 17:30 ` Petr Baudis
2007-05-17 17:35 ` Jeff King
2007-05-17 18:49 ` Junio C Hamano
2007-05-18 12:58 ` Jeff King
2007-05-17 18:47 ` Junio C Hamano
2007-05-17 13:45 ` Nicolas Pitre
2007-05-17 21:58 ` Michael S. Tsirkin
2007-05-17 23:41 ` Josef Weidendorfer
2007-05-18 0:32 ` Steven Grimm
2007-05-18 4:50 ` Petr Baudis
2007-05-18 9:18 ` Josef Weidendorfer
2007-05-19 0:56 ` Torgil Svensson
2007-05-18 12:00 ` Jakub Narebski
2007-05-18 12:41 ` Petr Baudis
2007-05-19 16:38 ` Jakub Narebski
2007-05-18 18:37 ` Junio C Hamano
2007-05-18 18:40 ` Julian Phillips
2007-05-18 18:45 ` Junio C Hamano
2007-05-20 0:16 ` Petr Baudis
2007-05-25 9:55 ` News reader woes (was: Re: [3/4] What's not in 1.5.2 (new topics)) Jakub Narebski
2007-05-18 7:57 ` [3/4] What's not in 1.5.2 (new topics) Andy Parkins
2007-05-18 8:43 ` Josef Weidendorfer
2007-05-18 9:21 ` Andy Parkins
2007-05-18 11:08 ` Michael S. Tsirkin
2007-05-18 12:27 ` Josef Weidendorfer
2007-05-18 12:46 ` Michael S. Tsirkin
2007-05-18 15:06 ` Aidan Van Dyk
2007-05-18 15:31 ` Michael S. Tsirkin
2007-05-19 12:50 ` Sven Verdoolaege
2007-05-21 1:10 ` Jakub Narebski
2007-05-18 17:00 ` Junio C Hamano
2007-05-19 18:12 ` Michael S. Tsirkin
2007-05-19 19:56 ` Junio C Hamano
2007-05-18 8:57 ` Michael S. Tsirkin
2007-05-18 9:40 ` Andy Parkins
2007-05-18 10:16 ` Johannes Sixt
2007-05-18 11:22 ` Michael S. Tsirkin
2007-05-18 12:36 ` Andy Parkins
2007-05-19 1:02 ` Steven Grimm
2007-05-19 16:55 ` Josef Weidendorfer
[not found] ` <200705181524.40705.Josef.Weidendorfer@gmx.de>
[not found] ` <20070518133922.GK4708@mellanox.co.il>
[not found] ` <200705181751.15435.Josef.Weidendorfer@gmx.de>
2007-05-18 16:08 ` Petr Baudis
2007-05-18 16:21 ` Michael S. Tsirkin
2007-05-16 22:47 ` [4/4] What's not in 1.5.2 (other bits and pieces) Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=11793556371774-git-send-email-junkio@cox.net \
--to=junkio@cox.net \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).