From: Martin Waitz <tali@admingilde•org>
To: skimo@liacs•nl
Cc: git@vger•kernel.org, Junio C Hamano <junkio@cox•net>,
Alex Riesen <raa.lkml@gmail•com>
Subject: Re: [PATCH 2/3] entry.c: checkout available submodules
Date: Sat, 26 May 2007 00:19:14 +0200 [thread overview]
Message-ID: <20070525221913.GB8361@admingilde.org> (raw)
In-Reply-To: <20070525214205.GJ942MdfPADPa@greensroom.kotnet.org>
[-- Attachment #1: Type: text/plain, Size: 1985 bytes --]
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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2007-05-25 22:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-25 21:07 [PATCH 1/3] run-command: optionally clear git environment skimo
2007-05-25 21:07 ` [PATCH 2/3] entry.c: checkout available submodules skimo
2007-05-25 21:31 ` Martin Waitz
2007-05-25 21:42 ` Sven Verdoolaege
2007-05-25 22:19 ` Martin Waitz [this message]
2007-05-25 23:06 ` Junio C Hamano
2007-05-25 21:07 ` [PATCH 3/3] test for simple submodule checkout support skimo
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070525221913.GB8361@admingilde.org \
--to=tali@admingilde$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=junkio@cox$(echo .)net \
--cc=raa.lkml@gmail$(echo .)com \
--cc=skimo@liacs$(echo .)nl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox