hoi :)
On Fri, May 25, 2007 at 11:42:05PM +0200, Sven Verdoolaege wrote:
> On Fri, May 25, 2007 at 11:31:03PM +0200, Martin Waitz wrote:
> > I think the list tends to prefer subproject over submodule.
>
> Does it? It seems that everyone writing code is use submodule
> instead of subproject. Either way, I don't really care.
I got that impression from my small poll.
> > > @@ -193,9 +220,8 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
> > > */
> > > unlink(path);
> > > if (S_ISDIR(st.st_mode)) {
> > > - /* If it is a gitlink, leave it alone! */
> > > if (S_ISGITLINK(ntohl(ce->ce_mode)))
> > > - return 0;
> > > + return checkout_submodule(ce, path, state);
> > > if (!state->force)
> > > return error("%s is a directory", path);
> > > remove_subtree(path);
> >
> > I think the call to checkout_submodule should be moved to write_entry,
> > to keep it in line with the other mode types.
>
> Well, like your patch, this only deals with cases where the submodule
> is already available. In write_entry you could potentially clone
> submodules based on some criteria, but I'm not doing this just yet
> since some people apparently prefer to get these things in pieces.
yes, first we need checkout and then can add more building blocks on
top.
Up to now the quoted code block above only handles cleaning the
tree from conflicting / old entries and write_entry creates the
real content.
For subprojects we first have to remove any non-subproject content
in that location and then later call write_subproject or similiar
in write_entry to update the subproject (or create some empty dummy
directory).
But we can also leave those details for later when we are clear about
the complete semantics. At the moment it is important to reach a
common base everybody agrees on and which is enough to experiment with
all the high level tools.
--
Martin Waitz
Attachment:
signature.asc
Description: Digital signature
