Junio C Hamano <junkio@xxxxxxx> writes:
Sorry, I hate to send "amend" message like this, but there are
some places I was not clear enough...
> How about doing something like this, instead?
>
> (1) superproject .gitmodules (in-tree) and .git/config (local
> repository) use the three-level naming in $gmane/47567.
> Namely, (1a) .gitmodules says which subdirectory has a
> checkout of what project, and names the project in
> logical/abstract terms, not with a URL (e.g. "kernel26");
> (1b) .gitmodules also associates a set of suggested URLs
> for each of the logical/abstract project name; (1c)
> .git/config records which project are of interest.
... are of interest, and perhaps which URL to use but that is
not necessary, as we can record that in repositories we create
in (2).
> (2) In superproject .git/, we would have a bare repository for
> each project used by the superproject.
>
> .git/subproject/kernel26/{objects,refs,...}
>
> This is created by making a bare clone from the upstream
> URL, decided by the user with the help from suggested URL
> described in the superproject .gitmodules.
This bare clone probably have its own config that records
remote.origin.url, which would probably be the same as one of
the URL suggested in .gitmodules for many people, but could be
different. As to what should happen when the .gitmodules that
comes from the upstream changes the set of suggested URLs
recorded in there, see $gmane/47621,
> The idea is to use this repository as a long-term
> subproject state across branch switching.
>
> (3) When we need to check out a revision of superproject whose
> .gitmodules has "kernel-src/ -> kernel26", and when we
> haven't done so (perhaps we are doing an initial checkout,
> perhaps we are switching from a different revision of the
> superproject that did not have "kernel26" project at
> kernel-src/ directory), we rm -f kernel-src/ and then
> "git-clone -l -s" from the repository we keep in (2) to
> populate kernel-src/ directory.
The last part of the above should have been:
we "rm -fr kernel-src/" and then "git-clone -l -s -n"
from the repository we keep in (2). And then check out
the commit that is pointed at by the superproject tree
(rather, "index").
> (4) Before performing the above step (3), we need to make sure
> we are not losing anything in kernel-src/ if exists. Three
> cases plus one:
>
> (4a) The path kernel-src/ in the old checkout was not a
> subproject (either it did not exist, it was a blob, or it
> was a directory with files that are tracked as part of the
> superproject). The usual "don't lose local modification"
> rule we use try to carry local changes forward across
> branch switching, but in this case we shouldn't do so.
The last part of the above should have been:
... but in this case we shouldn't even try to carry local
changes forward, as there is nowhere to carry them to.
Instead we should error out and have the user clean-up
the subproject repository (either "git reset", or "git
commit && git push" to stash the change back to
repository we prepared in (2)). We might also want to
allow the user to say "local changes in this subproject
checkout does not matter" by saying "git checkout -f
$commit" at the superproject level, but I think that is
rather dangerous.
> (4b) It has the same logical/abstract project checked out;
> ...
> (4c) It has a different project checked out; we need to be
> careful to keep local changes, and also we need to make
> sure the local changes in this subproject repository are
> pushed back to (2). It could be that automated "git push"
> after making sure everything is committed is sufficient and
> have the user handle failure cases.
>
> (4d) This applies not just "before step (3)", but in cases
> where we need to replace a checked out subproject directory
> with something else (e.g. blob or directory that belong to
> the superproject, or noneness). We would need to make sure
> no local change is lost, and the repository is synched up
> with (2).
... which is the same check and action we would do in case (4c).
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
