On 5/25/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
On Fri, 25 May 2007, Lars Hjemli wrote:
> On 5/25/07, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> > On Fri, 25 May 2007, Lars Hjemli wrote:
> > > + die "Unable to find current revision of submodule '$path'"
> > > +
> > > + if test "$subsha1" != "$sha1"
> > > + then
> > > + $(cd "$path" && git-fetch && git-checkout -q
> > "$sha1") ||
> >
> > This will make a detached HEAD, right? Do you want that? (I am not
> > really interested in submodules myself, so I haven't thought about it,
> > and I haven't followed that monster discussion.)
>
> Well, we might want to be smarter about this, but on the other hand: if
> the user cares, he can always do 'cd $path && git checkout $branch',
> since 'git submodule -u' will skip submodules with the correct commit
> checked out.
Fair enough, I guess...
The only alternative I can think of is to check if module.$path.branch
is specified in .gitmodules: if it is, and it's pointing at the wanted
sha1, the right thing would be to checkout that branch. Any other sort
of dwim is bound to get it wrong.
> > I'll let Junio comment on that command line parsing...
>
> Heh, I'm a shell illiterate...
;-)
I guess Junio would like one of his famous
case ,"$init","$update",[...] in
*1*1) usage
esac
to prevent running with two actions...
Ahh, that's something I can handle
> > All in all, I like it: it is short, to the point, and it should do the
> > job (maybe with a few enhancements like "--update" without arguments
> > means _all_ submodules).
>
> Well, it does (or should) update all initialized submodules, but maybe
> that's not what you meant?
Oops. I meant "init".
Hmm, it does (or should) clone all submodules if you run 'git
submodule --init' (no paths specified). Did it fail for you?
--
larsh
-
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
