Steven Grimm <koreth@xxxxxxxxxxxxx> wrote:
> Andy Parkins wrote:
> >Unfortunately, during development, you've switched libsubmodule1 to
> >branch "development", but supermodule isn't tracking libsubmodule1/HEAD
> >it's tracking libsubmodule1/master. Your supermodule commit doesn't
> >capture a snapshot of the tree you're using.
> >
>
> Or maybe not a merge, but worse, you'd *replace* the
> previously committed master with what's in your dev branch.
Right, you would be replacing the prior branch of that submodule with
the new submodule branch.
I think the safety valve you are looking for here is two things:
* don't automatically update the submodule's HEAD into the
supermodule's index.
* make sure the submodule's HEAD is a fast-forward of the
supermodule's index, with a --force option to force it
anyway.
Otherwise the developer just has to know what he/she is doing.
Today you can put stuff that isn't ready for prime-time into a
repository on the wrong branch just by applying the wrong patch,
or cherry-picking the wrong commit, etc... the user can (and
will) make mistakes. But they can also easily recover from them
by rewinding history and redoing it.
> On a related note, it would be great from a usability point of view if
> there were a way to say "I always want to be on the same branch in all
> submodules and the supermodule."
That's not really an issue.
A branch doesn't exist just because you checked-out the branch, or
because you created it. A branch exists because there were two or
more commits (B and C) which use the same parent (A) and two or more
of those commits survive, e.g. they have refs which point to them
(directly or indirectly) or they were merged into another commit
which itself survives.
Therefore if the supermodule is on the "development branch" the
submodules are also immediately on the same branch, because their
HEADs are derived from whatever is stored in the supermodule's tree.
And that tree is derived from whatever "development branch" means.
Really what you want/need is a special head in the submodule
which acts as the "branch that corresponds to the supermodule".
This probably should just be a naked SHA1 stored in HEAD, which
is committable only because a supermodule exists in a higher level
directory.
The fact that the submodule project has branches *at all* is
totally irrelevant once you start to speak about that submodule
within the supermodule, as its the supermodule which determines
the branch of the submodule.
> But I think the Perforce-style
> "compose a single workspace out of different bits of a larger project"
> model is hugely useful
That's a mess.
You start to get into weird cases where the directory structure
expected by the build process is no longer intact, because the user
has sliced it apart in weird ways. And there's no single version
which corresponds to that workspace as (if I recall correctly)
you can pick different tags or branches at will. I believe that
ClearCase has the same bug.
You also can't version that now spliced workspace, aside from taking
the configuration file and putting that under version control too.
However I think the proposal on the table will support that to some
degree, in that you can take any version of any repository and embed
it at any directory of any other repository. This means you can
for example embed the Linux kernel, glibc and gcc projects into
a larger "embedded device" repository, but you cannot alter the
structure of any of those three projects without making your own
locally developed branch of them. Which is actually the correct
thing to do as any subslicing of a repository is exactly that:
a locally developed branch of that repository.
--
Shawn.
-
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