* Re: [PATCH] Don't allow newlines to occur in $Id:$ collapse
From: Andy Parkins @ 2007-05-25 13:50 UTC (permalink / raw)
To: git; +Cc: Joshua N Pritikin
In-Reply-To: <20070525132800.GH6667@always.joy.eth.net>
On Friday 2007 May 25, Joshua N Pritikin wrote:
> That's better but I would error out instead of silently ignoring it.
> Your choice.
We can't error out on checking a file out - that file is in the repository
already, if it's got problems - so be it, it's got to be possible to check it
out.
One could even argue that it's not actually an error, if we define keywords to
be such that they are not allowed to contain newlines, then the fact that
someone has written "$Id:" in their file, with no closing "$" just means that
it's not a keyword; and like every other non-keyword bit of data in the file
it should be left untouched.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Add git-submodule command
From: Johannes Schindelin @ 2007-05-25 13:58 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano
In-Reply-To: <8c5c35580705250646h12f4f30bt301f4c4bdc2ad530@mail.gmail.com>
Hi,
On Fri, 25 May 2007, Lars Hjemli wrote:
> On 5/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Fri, 25 May 2007, Lars Hjemli wrote:
> >
> > > +modules_init()
> > > +{
> > > + git ls-files --stage -- $@ | grep -e '^160000 ' |
> >
> > Any reason you read in the stage? It does not seem that you use it.
>
> Are there any other way to get the mode info?
Ah, I missed that. Right.
> > > + subsha1=$(cd "$path" && git-rev-parse --verify HEAD) ||
> >
> > Maybe it would be a better idea to use "git --git-dir="$path"
> > rev-parse ..."? Just in case somebody calls this with GIT_DIR
> > overridden...
> >
> > Or, unset GIT_DIR explicitely.
>
> Hmm, that's annoying (overridden GIT_DIR). I guess 'git --git-dir
> $path/.git' would be the easiest solution.
But you have to repeat it on every subsequent Git command. OTOH if you
unset GIT_DIR, you can no longer be sure that you have the correct git dir
for Git calls in the superproject...
> > > + 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...
> > 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...
> > 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". I mean, most people who want to clone a superproject
want the submodules being initialized without hassles, probably. But maybe
that should be another option: "--clone-superproject" or something. Dunno.
There's time for that after the initial git-submodule.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Josef Weidendorfer @ 2007-05-25 13:59 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Junio C Hamano, Lars Hjemli, skimo,
Shawn O. Pearce, git, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705251343550.4648@racer.site>
On Friday 25 May 2007, Johannes Schindelin wrote:
> > I assume you talk about a versioned .gitmodules file tied to the
> > superproject history, and any fetch/pull would look into this
> > file from the current working directory to lookup the default URL.
> >
> > Wouldn't this have the problem that when you check out an old
> > revision of the superproject you get out-of-date URLs, so that
> > a fetch does not work (without local overrides)?
>
> If you check out an old revision, wouldn't you have that _already_, so it
> does not matter what URL is given in .gitmodules?
Not necessary.
* Submodules can appear/disappear any time in the superproject.
Therefore, going back in time can make it necessary to have to clone
a submodule you did not have before.
* Not every submodule is interesting for every developer; therefore,
an important design-decision for submodules is to allow at git-clone time
to not clone some submodules at all. However, you can change your mind and
want to follow a given submodule later.
Above points make it necessary for the submodule feature to implement
lazy clones. You want be able to clone a submodule without error independent
of the superproject HEAD. IMHO it would be really bad porcelain design
to break out with an error each time and expect the USER to manually
override submodule URLs.
Another difference between in-tree .gitmodules and out-of-tree submodule
config is that for in-tree you any want to see configuration for submodules
which happen to be part of the superproject at this point in history.
For out-of-tree config, there has to be information for every submodule which
was referenced in the whole history of the superproject.
Josef
^ permalink raw reply
* Re: Problem using git svn clone
From: Seth Falcon @ 2007-05-25 14:13 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: git
In-Reply-To: <bf7b2dda0705241539i56f1b5b3kcd001e871e8688ef@mail.gmail.com>
"Gustaf Hendeby" <hendeby@gmail.com> writes:
> Let me clarify. When trying to check out the module with tags, the first
> example I only get the revisions, no content at all! I have added some more
> info on this below.
If you see the output of the revisions being pulled from svn this
seems very odd. Does a 'du -sh' in the created directory confirm no
data is there? Are you sure it isn't just a matter of nothing getting
checked out for you?
> The second case works as I expected it, I included it as reference, and to
> show that it worked (probably not the smartest thing to do I guess). Hence,
> probably just the first example is of interest.
>
>> The situation is as follows:
>> >
>> > I plan to use git and git svn to track a module in the middle of a SVN
>> > repository (which I have no control over) where I don't have read
>> > access more than to this specific module and the base directory, ie
>> > the layout is similar to this
>> > https://svn.foo.bar/a/b/c/trunk
>> > https://svn.foo.bar/a/b/c/tags
>> > https://svn.foo.bar/a/b/c/branches
>> > and I have read access to https://svm.foo.bar/a,
>> > https://svn.foo.bar/a/b/c and below, but nothing else.
>> >
>> > What I want to do is clone the whole thing, including tags and
>> > branches. I expected to be able to use the following command to do
>> > this (git v1.5.2):
>> >
>> > $ git svn clone https://svn.foo.bar/a/b/c -T trunk -t tags -b branches
>> >
>> > Initialized empty Git repository in .git/
>> > Using higher level of URL: https://svn.foo.bar/a/b/c =>
>> https://svn.foo.bar/a
>> >
>> > W: Ignoring error from SVN, path probably does not exist: (175002): RA
>> > layer request failed: REPORT request failed on '/a/!svn/bc/100':
>> > REPORT of '/a/!svn/bc/100': Could not read chunk size: Secure
>> > connection truncated (https://svn.foo.bar)
>> > r306 = 83f0c10b988a8f1e77a3f354126c52f0cfdecf76 (trunk)
>> > [...]
>> > Found possible branch point: https://svn.foo.bar/a/b/c/trunk =>
>> > https://svn.foo.bar/a/b/c/tags/0.1, 314
>> > Found branch parent: (tags/0.1) ad6a2361d0e69d6288ef226bb335bb4bf3bdd12e
>> > Following parent with do_update
>> > Successfully followed parent
>> > r315 = 3b92c4885b9d6f60241533dd99fa5023eebb1c64 (tags/0.1)
>> > r316 = 02e3b828b4f11c5fab9d10d85076a8ff209afa00 (trunk)
>> > [...]
>> >
>> > However, it seems I just get the info about the revisions (shows up
>> > nicely in gitk) but no content at all. The config file reads:
>
>
> I'm really sorry, I mixed up the config files. :( So I actually get this
> for the first example not the second:
>
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [svn-remote "svn"]
> url = https://foo.bar/a
> fetch = b/c/trunk:refs/remotes/trunk
> branches = b/c/branches/*:refs/remotes/*
> tags = b/c/tags/*:refs/remotes/tags/*
>
> Which looks good I guess... But to be a bit more clear about what this
> actually gives me in the directory I just cloned to, and this is the
> problem:
>
> $ git checkout -f master
What's in .git/refs/remotes?
Does 'git checkout -b mytrunk refs/remotes/git-svn' work?
> Already on branch "master"
> $ ls -a
> . .. .git
> $ du -hs .git/objects
> 186K .git/objects
A du of the entire .git dir would be more informative.
+ seth
^ permalink raw reply
* Re: [PATCH] Add git-submodule command
From: Lars Hjemli @ 2007-05-25 14:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0705251451530.4648@racer.site>
On 5/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Fri, 25 May 2007, Lars Hjemli wrote:
> > On 5/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-25 14:16 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Linus Torvalds, Junio C Hamano, Lars Hjemli, skimo,
Shawn O. Pearce, git, Martin Waitz, Alex Riesen
In-Reply-To: <200705251559.53846.Josef.Weidendorfer@gmx.de>
Hi,
On Fri, 25 May 2007, Josef Weidendorfer wrote:
> On Friday 25 May 2007, Johannes Schindelin wrote:
> > > I assume you talk about a versioned .gitmodules file tied to the
> > > superproject history, and any fetch/pull would look into this
> > > file from the current working directory to lookup the default URL.
> > >
> > > Wouldn't this have the problem that when you check out an old
> > > revision of the superproject you get out-of-date URLs, so that
> > > a fetch does not work (without local overrides)?
> >
> > If you check out an old revision, wouldn't you have that _already_, so it
> > does not matter what URL is given in .gitmodules?
>
> Not necessary.
> * Submodules can appear/disappear any time in the superproject.
> Therefore, going back in time can make it necessary to have to clone
> a submodule you did not have before.
> * Not every submodule is interesting for every developer; therefore,
> an important design-decision for submodules is to allow at git-clone time
> to not clone some submodules at all. However, you can change your mind and
> want to follow a given submodule later.
Okay, so there are exceptions to the rule, just as everywhere.
We already talked about being able to override .gitmodules from
.git/config. I think that should really, really be sufficient, as you
cannot hope to have a one-size-fits-them-all solution for the exceptions
you described. You'll have to cope with them manually anyway.
We should not design for the exception. Therefore I think the .gitmodules,
overrideable by .git/config is sufficient.
And the point about my config being private still stands. You have no
business looking into my config.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-25 14:38 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Josef Weidendorfer, Linus Torvalds, Junio C Hamano, Lars Hjemli,
Shawn O. Pearce, git, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705251514220.4648@racer.site>
On Fri, May 25, 2007 at 03:16:56PM +0100, Johannes Schindelin wrote:
> And the point about my config being private still stands. You have no
> business looking into my config.
Put your private configuration in config and your public configuration
in submodulesconfig.
A public repo typically wouldn't have any submodules configuration
in config (or any other private information for that matter), but
we wouldn't read it anyway.
skimo
^ permalink raw reply
* Re: [PATCH] Don't allow newlines to occur in $Id:$ collapse
From: Joshua N Pritikin @ 2007-05-25 14:40 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200705251451.00999.andyparkins@gmail.com>
On Fri, May 25, 2007 at 02:50:53PM +0100, Andy Parkins wrote:
> One could even argue that it's not actually an error, if we define keywords to
> be such that they are not allowed to contain newlines, then the fact that
> someone has written "$Id:" in their file, with no closing "$" just means that
> it's not a keyword; and like every other non-keyword bit of data in the file
> it should be left untouched.
Ah, so the original patch, before I started kibitzing, was correct.
Sorry for the noise.
^ permalink raw reply
* Re: Problem using git svn clone
From: Gustaf Hendeby @ 2007-05-25 14:46 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m21wh5kn3b.fsf@ziti.local>
On 5/25/07, Seth Falcon <sethfalcon@gmail.com> wrote:
> "Gustaf Hendeby" <hendeby@gmail.com> writes:
> > Let me clarify. When trying to check out the module with tags, the first
> > example I only get the revisions, no content at all! I have added some more
> > info on this below.
>
> If you see the output of the revisions being pulled from svn this
> seems very odd. Does a 'du -sh' in the created directory confirm no
> data is there? Are you sure it isn't just a matter of nothing getting
> checked out for you?
The following result is the same directly after the clone attempt and
after a git checkout -f master:
$ du -hs
357K .
$ ls -a
. .. .git
If it is just not checked out I don't know what I'm doing wrong trying
to check it out.
> > The second case works as I expected it, I included it as reference, and to
> > show that it worked (probably not the smartest thing to do I guess). Hence,
> > probably just the first example is of interest.
> >
> >> The situation is as follows:
> >> >
> >> > I plan to use git and git svn to track a module in the middle of a SVN
> >> > repository (which I have no control over) where I don't have read
> >> > access more than to this specific module and the base directory, ie
> >> > the layout is similar to this
> >> > https://svn.foo.bar/a/b/c/trunk
> >> > https://svn.foo.bar/a/b/c/tags
> >> > https://svn.foo.bar/a/b/c/branches
> >> > and I have read access to https://svm.foo.bar/a,
> >> > https://svn.foo.bar/a/b/c and below, but nothing else.
> >> >
> >> > What I want to do is clone the whole thing, including tags and
> >> > branches. I expected to be able to use the following command to do
> >> > this (git v1.5.2):
> >> >
> >> > $ git svn clone https://svn.foo.bar/a/b/c -T trunk -t tags -b branches
> >> >
> >> > Initialized empty Git repository in .git/
> >> > Using higher level of URL: https://svn.foo.bar/a/b/c =>
> >> https://svn.foo.bar/a
> >> >
> >> > W: Ignoring error from SVN, path probably does not exist: (175002): RA
> >> > layer request failed: REPORT request failed on '/a/!svn/bc/100':
> >> > REPORT of '/a/!svn/bc/100': Could not read chunk size: Secure
> >> > connection truncated (https://svn.foo.bar)
> >> > r306 = 83f0c10b988a8f1e77a3f354126c52f0cfdecf76 (trunk)
> >> > [...]
> >> > Found possible branch point: https://svn.foo.bar/a/b/c/trunk =>
> >> > https://svn.foo.bar/a/b/c/tags/0.1, 314
> >> > Found branch parent: (tags/0.1) ad6a2361d0e69d6288ef226bb335bb4bf3bdd12e
> >> > Following parent with do_update
> >> > Successfully followed parent
> >> > r315 = 3b92c4885b9d6f60241533dd99fa5023eebb1c64 (tags/0.1)
> >> > r316 = 02e3b828b4f11c5fab9d10d85076a8ff209afa00 (trunk)
> >> > [...]
> >> >
> >> > However, it seems I just get the info about the revisions (shows up
> >> > nicely in gitk) but no content at all. The config file reads:
> >
> >
> > I'm really sorry, I mixed up the config files. :( So I actually get this
> > for the first example not the second:
> >
> > [core]
> > repositoryformatversion = 0
> > filemode = true
> > bare = false
> > logallrefupdates = true
> > [svn-remote "svn"]
> > url = https://foo.bar/a
> > fetch = b/c/trunk:refs/remotes/trunk
> > branches = b/c/branches/*:refs/remotes/*
> > tags = b/c/tags/*:refs/remotes/tags/*
> >
> > Which looks good I guess... But to be a bit more clear about what this
> > actually gives me in the directory I just cloned to, and this is the
> > problem:
> >
> > $ git checkout -f master
>
> What's in .git/refs/remotes?
$ ls -R .git/refs/remotes/
.git/refs/remotes/:
tags trunk
.git/refs/remotes/tags:
0.1 0.1.1 0.2.0 0.2.1
So, in some way there seems to be tag information, but git doesn't
seem to handle them as tags.
>
> Does 'git checkout -b mytrunk refs/remotes/git-svn' work?
$ git checkout -b mytrunk refs/remotes/git-svn
git checkout: updating paths is incompatible with switching branches/forcing
Did you intend to checkout 'refs/remotes/git-svn' which can not be
resolved as commit?
However
$ git checkout -b mytrunk refs/remotes/trunk
works but is without any content.
>
> > Already on branch "master"
> > $ ls -a
> > . .. .git
> > $ du -hs .git/objects
> > 186K .git/objects
>
> A du of the entire .git dir would be more informative.
$ du -hs .git
356K .git
For the checkout of the trunk, that works but don't obtain what I'm
looking for has:
$ du -hs .git
5.9M .git
More stuff has been stored here. The clone process here also
indicates lots of added and changed files, not just list SVN revision
numbers with matching SHA1s as in the case shown above.
Also, this may be totally natural, but I find the warning that I get
at the start of the clone quite strange (from above):
W: Ignoring error from SVN, path probably does not exist: (175002): RA
layer request failed: REPORT request failed on '/a/!svn/bc/100':
REPORT of '/a/!svn/bc/100': Could not read chunk size: Secure
connection truncated (https://svn.foo.bar)
>From where comes the !svn/bc/100 ? Is it supposed to be like that?
Also, it feels a bit dangerous to me to fall back to a position in the
SVN tree where there is a level that I don't have any access to
between the base and the module I want and have access to.
/Gustaf
^ permalink raw reply
* Re: [PATCH] Add git-submodule command
From: Johannes Schindelin @ 2007-05-25 14:47 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git, Junio C Hamano
In-Reply-To: <8c5c35580705250716j27695a01kd1db222be6c7eac7@mail.gmail.com>
Hi,
On Fri, 25 May 2007, Lars Hjemli wrote:
> On 5/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Fri, 25 May 2007, Lars Hjemli wrote:
> > > On 5/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > > 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?
I don't have any superproject to try with ;-)
Actually, I missed the "$@" in modules_init. You might want to change the
documentation, though, since it suggests (at least to yours truly) that
you _need_ to pass a path with "--init".
Even happier,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-25 14:51 UTC (permalink / raw)
To: skimo
Cc: Josef Weidendorfer, Linus Torvalds, Junio C Hamano, Lars Hjemli,
Shawn O. Pearce, git, Martin Waitz, Alex Riesen
In-Reply-To: <20070525143815.GF942MdfPADPa@greensroom.kotnet.org>
Hi,
On Fri, 25 May 2007, Sven Verdoolaege wrote:
> On Fri, May 25, 2007 at 03:16:56PM +0100, Johannes Schindelin wrote:
> > And the point about my config being private still stands. You have no
> > business looking into my config.
>
> Put your private configuration in config and your public configuration
> in submodulesconfig.
> A public repo typically wouldn't have any submodules configuration
> in config (or any other private information for that matter), but
> we wouldn't read it anyway.
Why complicate things? The information you want to put into
submodulesconfig is an information you would most likely want to give
cloners.
And as it happens, we _have_ a perfect transport mechanism for clones. You
only have to put the information into the object database itself, and --
voila -- no need to change any core level plumbing.
That's why I keep harping on .gitmodules, since it _is_ the obvious
correct, simple and elegant way to do things here.
So, just "s/\.git\/submodulesconfig/.gitmodules/g" in your head, and
you're done.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Josef Weidendorfer @ 2007-05-25 14:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Junio C Hamano, Lars Hjemli, skimo,
Shawn O. Pearce, git, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705251514220.4648@racer.site>
On Friday 25 May 2007, Johannes Schindelin wrote:
> On Fri, 25 May 2007, Josef Weidendorfer wrote:
> > * Submodules can appear/disappear any time in the superproject.
> > Therefore, going back in time can make it necessary to have to clone
> > a submodule you did not have before.
> > * Not every submodule is interesting for every developer; therefore,
> > an important design-decision for submodules is to allow at git-clone time
> > to not clone some submodules at all. However, you can change your mind and
> > want to follow a given submodule later.
>
> Okay, so there are exceptions to the rule, just as everywhere.
The question here is in how many superprojects the exception
will become the rule, which would make manual overriding quite
cumbersome.
However, the exact policy for finding a fitting URL for a submodule
is not a fundamental design decision, and can be incrementally
improved, depending on use cases.
I agree with Junio that a simply, basic and robust submodule
implementation currently is important as first goal.
> We should not design for the exception. Therefore I think the .gitmodules,
> overrideable by .git/config is sufficient.
>
> And the point about my config being private still stands. You have no
> business looking into my config.
I totally agree.
Josef
^ permalink raw reply
* Re: [PATCH] Add git-submodule command
From: Lars Hjemli @ 2007-05-25 14:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0705251539260.4648@racer.site>
On 5/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 25 May 2007, Lars Hjemli wrote:
>
> > On 5/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > On Fri, 25 May 2007, Lars Hjemli wrote:
> > > > On 5/25/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > >
> > > > > 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?
>
> I don't have any superproject to try with ;-)
You could always try cgit ;-)
>
> Actually, I missed the "$@" in modules_init. You might want to change the
> documentation, though, since it suggests (at least to yours truly) that
> you _need_ to pass a path with "--init".
Ok, will do.
--
larsh
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-25 14:54 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Linus Torvalds, Junio C Hamano, Lars Hjemli, skimo,
Shawn O. Pearce, git, Martin Waitz, Alex Riesen
In-Reply-To: <200705251651.35234.Josef.Weidendorfer@gmx.de>
Hi,
On Fri, 25 May 2007, Josef Weidendorfer wrote:
> On Friday 25 May 2007, Johannes Schindelin wrote:
> > On Fri, 25 May 2007, Josef Weidendorfer wrote:
> >
> > > * Submodules can appear/disappear any time in the superproject.
> > > Therefore, going back in time can make it necessary to have to clone
> > > a submodule you did not have before.
> > >
> > > * Not every submodule is interesting for every developer; therefore,
> > > an important design-decision for submodules is to allow at git-clone
> > > time to not clone some submodules at all. However, you can change
> > > your mind and want to follow a given submodule later.
> >
> > Okay, so there are exceptions to the rule, just as everywhere.
>
> The question here is in how many superprojects the exception will become
> the rule, which would make manual overriding quite cumbersome.
I never disputed that manual overriding is cumbersome. However, I dispute
that automatic overriding is _possible_.
> I agree with Junio that a simply, basic and robust submodule
> implementation currently is important as first goal.
Good. Me, too.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Linus Torvalds @ 2007-05-25 15:35 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Johannes Schindelin, Junio C Hamano, Lars Hjemli, skimo,
Shawn O. Pearce, git, Martin Waitz, Alex Riesen
In-Reply-To: <200705251559.53846.Josef.Weidendorfer@gmx.de>
On Fri, 25 May 2007, Josef Weidendorfer wrote:
>
> * Submodules can appear/disappear any time in the superproject.
> Therefore, going back in time can make it necessary to have to clone
> a submodule you did not have before.
You missed the obvious thing here: if a submodule
appears/disappears/moves, then the module info *has* to be versioned.
Otherwise your module setup will be *wrong*.
Think about it. If you move the kernel module somewhere else (say, you
make it be in "old-kernel"), and then replace the "kernel" module with a
_new_ submodule, if you don't version the .gitmodules file, you're simply
_screwed_. You'll be loading the "kernel" module from the wrong place
when you move around in history!
In contrast, if you version it, everything JUST WORKS.
So:
- submodule information *has* to be versioned. If it isn't, it's broken.
It really _is_ that simple.
- because some people will want to replace repository addresses etc, you
want to have a per-repo (or user, or system) *mapping* of that
versioned submodule information, so that people can override the actual
location. But that doesn't obviate the need for the basic module
information having to be versioned.
So no, we cannot have the fundamental module info setup anywhere else than
in something like .gitmodules.
Linus
^ permalink raw reply
* Re: Problem using git svn clone
From: Seth Falcon @ 2007-05-25 15:39 UTC (permalink / raw)
To: Gustaf Hendeby; +Cc: git
In-Reply-To: <bf7b2dda0705250746p33cb198exe1fe5daa6b18d801@mail.gmail.com>
"Gustaf Hendeby" <hendeby@gmail.com> writes:
> On 5/25/07, Seth Falcon <sethfalcon@gmail.com> wrote:
>> "Gustaf Hendeby" <hendeby@gmail.com> writes:
>> > Let me clarify. When trying to check out the module with tags, the first
>> > example I only get the revisions, no content at all! I have added some more
>> > info on this below.
>>
>> If you see the output of the revisions being pulled from svn this
>> seems very odd. Does a 'du -sh' in the created directory confirm no
>> data is there? Are you sure it isn't just a matter of nothing getting
>> checked out for you?
>
> The following result is the same directly after the clone attempt and
> after a git checkout -f master:
>
> $ du -hs
> 357K .
> $ ls -a
> . .. .git
>
> If it is just not checked out I don't know what I'm doing wrong trying
> to check it out.
That does seem like either something is broken or not doing what you
expect (how's that for non-informative?).
I'm not sure I have enough expertise to help further. If you care
about getting to the bottom of this, then I suspect you need to help
specify something that can be reproduced by others (which can be
difficult).
In the meantime, if I understood your comments, you did find a way to
clone the repos as you wanted just with a different command line...
+ seth
--
Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center
http://bioconductor.org
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Junio C Hamano @ 2007-05-25 16:16 UTC (permalink / raw)
To: Sven Verdoolaege
Cc: Johannes Schindelin, Lars Hjemli, Shawn O. Pearce, git,
Martin Waitz, Alex Riesen
In-Reply-To: <20070525100030.GB942MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> I'm obviously not going to stop anyone from putting URLs in .gitmodules
> and I can see that it would be useful in practice, but I still think
> that it doesn't matter where the submodule was located at any
> given point in history (from the point of view of the superproject).
> It only matters where the submodule is located now.
>
> You may be bisecting a problem and you may need to clone a submodule
> for a point in history when the submodule was placed somewhere else.
> (You may not have had a need to checkout the submodule before,
> or it may simply not be used in the current version of the supermodule.)
> So, I think it would still be useful to have an optional additional
> out-of-tree mechanism of getting usable URLs if the URLs in .gitmodules
> or your local config don't work.
I thought that was already solved in my original two-level
strawman and can naturally be extended to the three-level
strawman. What am I missing?
gmane=http://article.gmane.org/gmane.comp.version-control.git/
$gmane/47502
$gmane/47548
$gmane/47621
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Josef Weidendorfer @ 2007-05-25 16:23 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Junio C Hamano, Lars Hjemli, skimo,
Shawn O. Pearce, git, Martin Waitz, Alex Riesen
In-Reply-To: <alpine.LFD.0.98.0705250830220.26602@woody.linux-foundation.org>
On Friday 25 May 2007, Linus Torvalds wrote:
> On Fri, 25 May 2007, Josef Weidendorfer wrote:
> >
> > * Submodules can appear/disappear any time in the superproject.
> > Therefore, going back in time can make it necessary to have to clone
> > a submodule you did not have before.
>
> You missed the obvious thing here: if a submodule
> appears/disappears/moves, then the module info *has* to be versioned.
I never refused the need for a versioned .gitmodules file in-tree;
I totally agree with you here. Perhaps I forgot to mention this
because I took it for granted.
> - because some people will want to replace repository addresses etc, you
> want to have a per-repo (or user, or system) *mapping* of that
> versioned submodule information,
Yes.
So now we have 2 levels of submodule configuration:
(1) In-tree, versioned together with the superproject tree
(2) Local overrides via .git/config.
AFAICS the whole discussion here is about whether we need
a further configuration level with different visibility:
one which in not versioned together with the superproject
history, but which can be cloned, ie. a superproject-wide
configuration (*1*).
And I can see a need here for submodule URLs.
But as I just said in another mail in this thread, that
would be an additional feature which can be added later
if we see that - because of whatever strange use cases
for submodules - some git users are forced to constantly
adapt 50 URL rewritings in their local config.
Josef
*1* For project-wide configuration, independent of the
actual project history, a completely separate branch
can be used (lets say refs/projectconfig), which
contains one blob, the config file: "projectconfig".
By making "git-config" to also parse
"refs/projectconfig:projectconfig" before the other
config files if existing, this gives us a natural way
to provide project wide settings.
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-25 16:28 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Lars Hjemli, Shawn O. Pearce, git,
Martin Waitz, Alex Riesen
In-Reply-To: <7vabvsswtd.fsf@assigned-by-dhcp.cox.net>
On Fri, May 25, 2007 at 09:16:30AM -0700, Junio C Hamano wrote:
> Sven Verdoolaege <skimo@kotnet.org> writes:
> > So, I think it would still be useful to have an optional additional
> > out-of-tree mechanism of getting usable URLs if the URLs in .gitmodules
> > or your local config don't work.
>
> I thought that was already solved in my original two-level
> strawman and can naturally be extended to the three-level
> strawman. What am I missing?
Maybe I'm missing something but you only seem to talk about .gitmodules
and local config there, while this would be a way of automatically getting
URLs that are either not available in .gitmodules or the local config
or are outdated or should be overridden.
skimo
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-25 16:37 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Linus Torvalds, Junio C Hamano, Lars Hjemli, skimo,
Shawn O. Pearce, git, Martin Waitz, Alex Riesen
In-Reply-To: <200705251823.37062.Josef.Weidendorfer@gmx.de>
Hi,
On Fri, 25 May 2007, Josef Weidendorfer wrote:
> AFAICS the whole discussion here is about whether we need
> a further configuration level with different visibility:
> one which in not versioned together with the superproject
> history, but which can be cloned, ie. a superproject-wide
> configuration (*1*).
I smell centralization here. _Forced_ centralization.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-25 16:43 UTC (permalink / raw)
To: skimo
Cc: Junio C Hamano, Lars Hjemli, Shawn O. Pearce, git, Martin Waitz,
Alex Riesen
In-Reply-To: <20070525162838.GI942MdfPADPa@greensroom.kotnet.org>
Hi,
On Fri, 25 May 2007, Sven Verdoolaege wrote:
> On Fri, May 25, 2007 at 09:16:30AM -0700, Junio C Hamano wrote:
> > Sven Verdoolaege <skimo@kotnet.org> writes:
> > > So, I think it would still be useful to have an optional additional
> > > out-of-tree mechanism of getting usable URLs if the URLs in .gitmodules
> > > or your local config don't work.
> >
> > I thought that was already solved in my original two-level
> > strawman and can naturally be extended to the three-level
> > strawman. What am I missing?
>
> Maybe I'm missing something but you only seem to talk about .gitmodules
> and local config there, while this would be a way of automatically getting
> URLs that are either not available in .gitmodules or the local config
> or are outdated or should be overridden.
I do not see what you're getting at.
Either you want to fetch the URLs from an upstream, in which case they
should be fetched. Why not in ".gitmodules"? If the URLs don't work, you
should blame the maintainer, not fsck up the tool.
Or you want some sort of "fallback" set of URLs. I cannot think of any
reasonable use case here.
Or you want to receive overrides, such as when a submodule has moved, so
that it still works when you check out older versions (and do not have the
objects locally already). But to make such overrides automatic wreaks
havoc IMHO.
Also, this is rare enough that I'd rather not fsck up an elegant solution,
where you have to treat such special cases manually, for something which
affects "normal" users, which just track the project.
Maybe I'm wrong. But then, Josef is right, we can talk about that later.
It's not like you need a feature like that from day one.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Josef Weidendorfer @ 2007-05-25 17:09 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Junio C Hamano, Lars Hjemli, skimo,
Shawn O. Pearce, git, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705251736400.4648@racer.site>
On Friday 25 May 2007, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 25 May 2007, Josef Weidendorfer wrote:
>
> > AFAICS the whole discussion here is about whether we need
> > a further configuration level with different visibility:
> > one which in not versioned together with the superproject
> > history, but which can be cloned, ie. a superproject-wide
> > configuration (*1*).
>
> I smell centralization here. _Forced_ centralization.
?
Everybody would be free to change the config in such a project
config branch, or use another version of it.
Hmm. Perhaps this is one of my complicating ideas ;-)
Josef
>
> Ciao,
> Dscho
>
^ permalink raw reply
* Re: Problem using git svn clone
From: Gustaf Hendeby @ 2007-05-25 17:41 UTC (permalink / raw)
To: Seth Falcon; +Cc: git
In-Reply-To: <m23b1kkj4k.fsf@ziti.local>
On 5/25/07, Seth Falcon <sethfalcon@gmail.com> wrote:
> "Gustaf Hendeby" <hendeby@gmail.com> writes:
> > On 5/25/07, Seth Falcon <sethfalcon@gmail.com> wrote:
> >> "Gustaf Hendeby" <hendeby@gmail.com> writes:
> I'm not sure I have enough expertise to help further. If you care
> about getting to the bottom of this, then I suspect you need to help
> specify something that can be reproduced by others (which can be
> difficult).
Ok fair enough, I am *very* *thankful* for your attempt to help me!
>
> In the meantime, if I understood your comments, you did find a way to
> clone the repos as you wanted just with a different command line...
Well, not really what I want since I lose all tags, but close enough
to be useful. That will have do for time being.
One again, thanks!
/Gustaf
^ permalink raw reply
* [PATCH] Add git-submodule command
From: Lars Hjemli @ 2007-05-25 18:09 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <8c5c35580705250752k2021f02dv804d87da5c0d5da7@mail.gmail.com>
This command can be used to initialize, update and inspect submodules. It
uses a .gitmodules file, readable by git-config, in the top level directory
of the 'superproject' to specify a mapping between submodule paths and
repository url. There is currently no way to override the mappings in the
.gitmodules file, except by manually creating the subproject repository.
Example .gitmodules layout:
[module "git"]
url = git://git.kernel.org/pub/scm/git/git.git
branch = maint
The branch-key in .gitmodules is optional. When specified, 'git-submodule -u'
will checkout the named branch if its tip matches the commit-sha1 in the
superprojects index. Otherwise, 'git-submodule -u' will create a detached
HEAD in the submodule.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
This is an updated patch that hopefully deals with all the previous issues.
I've also added support for specifying module.$path.branch in .gitmodules,
but not support for general url rewriting based on local config. If that
is a wanted feature, it should be trivial to add later on.
Btw: testing this quickly becomes tedious, so I'll try to make a proper
testscript later tonight.
Documentation/git-submodule.txt | 63 ++++++++++++++
Makefile | 2 +-
git-submodule.sh | 178 +++++++++++++++++++++++++++++++++++++++
3 files changed, 242 insertions(+), 1 deletions(-)
create mode 100644 Documentation/git-submodule.txt
create mode 100755 git-submodule.sh
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
new file mode 100644
index 0000000..81236aa
--- /dev/null
+++ b/Documentation/git-submodule.txt
@@ -0,0 +1,63 @@
+git-submodule(1)
+================
+
+NAME
+----
+git-submodule - Initialize, update or inspect submodules
+
+
+SYNOPSIS
+--------
+'git-submodule' [--init | --update | --cached] [--quiet] [--] [<path>...]
+
+
+DESCRIPTION
+-----------
+The command shows the status of each specified submodule path, or all
+submodules if none is specified. Each submodule sha1 is prefixed with '-'
+if the submodule is uninitialized and '+' if the checked out version of
+the submodule is different from the commit sha1 stored in the index.
+
+
+OPTIONS
+-------
+<path>::
+ Path to submodule(s)
+
+-i, --init::
+ Initialize the specified submodules, i.e. clone the git repository
+ specified in .gitmodules and checkout the sha1 specified in the
+ index.
+
+-u, --update::
+ Update the specified submodules, i.e. checkout the sha1 specified
+ in the index
+
+--cached::
+ Display the sha1 stored in the index, not the currently checked
+ out revsion.
+
+-q, --quiet::
+ Be quiet
+
+
+FILES
+-----
+When cloning submodules, a .gitmodules file in the top-level directory
+of the containing work-tree is examined for the url of each submodule.
+The url is the value of the key module.$path.url.
+
+When updating submodules, the same .gitmodules file is examined for a key
+named 'module.$path.branch'. If found, and if the named branch is currently
+at the same revision as the commit-id in the containing repositories index,
+the specified branch will be checked out in the submodule. If not found, or
+if the branch isn't currently positioned at the wanted revision, a checkout
+of the wanted sha1 will happen in the submodule, leaving its HEAD detached.
+
+Author
+------
+Written by Lars Hjemli <hjemli@gmail.com>
+
+GIT
+---
+Part of the gitlink:git[7] suite
diff --git a/Makefile b/Makefile
index 29243c6..5cf2169 100644
--- a/Makefile
+++ b/Makefile
@@ -209,7 +209,7 @@ SCRIPT_SH = \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
git-merge-resolve.sh git-merge-ours.sh \
- git-lost-found.sh git-quiltimport.sh
+ git-lost-found.sh git-quiltimport.sh git-submodule.sh
SCRIPT_PERL = \
git-add--interactive.perl \
diff --git a/git-submodule.sh b/git-submodule.sh
new file mode 100755
index 0000000..51a0f47
--- /dev/null
+++ b/git-submodule.sh
@@ -0,0 +1,178 @@
+#!/bin/sh
+#
+# git-submodules.sh: init, update or list git submodules
+#
+# Copyright (c) 2007 Lars Hjemli
+
+USAGE='[--init | --update | --cached] [--quiet] [--] [<path>...]'
+. git-sh-setup
+require_work_tree
+
+init=
+update=
+quiet=
+cached=
+
+#
+# print stuff on stdout unless -q was specified
+#
+say()
+{
+ if test -z "$quiet"
+ then
+ echo -e "$@"
+ fi
+}
+
+#
+# Run clone + checkout on missing submodules
+#
+# $@ = requested paths (default to all)
+#
+modules_init()
+{
+ git ls-files --stage -- $@ | grep -e '^160000 ' |
+ while read mode sha1 stage path
+ do
+ test -d "$path/.git" && continue
+
+ if test -d "$path"
+ then
+ rmdir "$path" 2>/dev/null ||
+ die "Directory '$path' exist, but not as a submodule"
+ fi
+
+ test -e "$path" &&
+ die "A file already exist at path '$path'"
+
+ url=$(GIT_CONFIG=.gitmodules git-config module."$path".url)
+ test -z "$url" &&
+ die "No url found for submodule '$path' in .gitmodules"
+
+ git-clone "$url" "$path" ||
+ die "Clone of submodule '$path' failed"
+
+ $(unset GIT_DIR && cd "$path" && git-checkout -q "$sha1") ||
+ die "Checkout of submodule '$path' failed"
+
+ say "Submodule '$path' initialized"
+ done
+}
+
+#
+# Checkout correct revision of each initialized submodule
+#
+# $@ = requested paths (default to all)
+#
+modules_update()
+{
+ git ls-files --stage -- $@ | grep -e '^160000 ' |
+ while read mode rev stage path
+ do
+ if ! test -d "$path/.git"
+ then
+ say "Submodule '$path' not initialized"
+ continue;
+ fi
+ subsha1=$(unset GIT_DIR && cd "$path" && git-rev-parse --verify HEAD) ||
+ die "Unable to find current revision of submodule '$path'"
+
+ if test "$subsha1" != "$rev"
+ then
+ $(unset GIT_DIR && cd "$path" && git-fetch)
+ branch=$(GIT_CONFIG=.gitmodules git-config module."$path".branch)
+ if test "$branch" != ""
+ then
+ branch_sha1=$(unset GIT_DIR && cd "$path" &&
+ git-rev-parse --verify "$branch")
+ if test "$branch_sha1" = "$rev"
+ then
+ rev="$branch"
+ fi
+ fi
+ $(unset GIT_DIR && cd "$path" && git-checkout -q "$rev") ||
+ die "Unable to checkout '$rev' in submodule '$path'"
+
+ say "Submodule '$path': checked out '$rev'"
+ fi
+ done
+}
+
+#
+# List all registered submodules, prefixed with:
+# - submodule not initialized
+# + different version checked out
+#
+# If --cached was specified the revision in the index will be printed
+# instead of the currently checked out revision.
+#
+# $@ = requested paths (default to all)
+#
+modules_list()
+{
+ git ls-files --stage -- $@ | grep -e '^160000 ' |
+ while read mode sha1 stage path
+ do
+ if ! test -d "$path/.git"
+ then
+ say "-$sha1 $path"
+ continue;
+ fi
+ revname=$(unset GIT_DIR && cd "$path" && git-describe $sha1)
+ if git diff-files --quiet -- "$path"
+ then
+ say " $sha1 $path\t($revname)"
+ else
+ if test -z "$cached"
+ then
+ sha1=$(unset GIT_DIR && cd "$path" && git-rev-parse --verify HEAD)
+ revname=$(unset GIT_DIR && cd "$path" && git-describe $sha1)
+ fi
+ say "+$sha1 $path\t($revname)"
+ fi
+ done
+}
+
+
+while case "$#" in 0) break ;; esac
+do
+ case "$1" in
+ -i|--init)
+ init=1
+ ;;
+ -u|--update)
+ update=1
+ ;;
+ -q|--quiet)
+ quiet=1
+ ;;
+ --cached)
+ cached=1
+ ;;
+ --)
+ break
+ ;;
+ -*)
+ usage
+ ;;
+ *)
+ break
+ ;;
+ esac
+ shift
+done
+
+case "$init,$update,$cached" in
+1,,)
+ modules_init $@
+ ;;
+,1,)
+ modules_update $@
+ ;;
+,,*)
+ modules_list $@
+ ;;
+*)
+ usage
+ ;;
+esac
--
1.5.2.74.gea9f
^ permalink raw reply related
* Re: [PATCH] Add git-submodule command
From: Johannes Schindelin @ 2007-05-25 18:41 UTC (permalink / raw)
To: Lars Hjemli, Junio C Hamano; +Cc: git
In-Reply-To: <11801165433267-git-send-email-hjemli@gmail.com>
Hi,
On Fri, 25 May 2007, Lars Hjemli wrote:
> Btw: testing this quickly becomes tedious, so I'll try to make a proper
> testscript later tonight.
Very good.
> +'git-submodule' [--init | --update | --cached] [--quiet] [--] [<path>...]
I did not realize this earlier, but we seem to have more and more programs
where actions are specified without "--", i.e. "git-svn fetch", or
"git-bundle create".
I actually like that, to separate actions from options. Hmm?
> +-i, --init::
> + Initialize the specified submodules, i.e. clone the git repository
> + specified in .gitmodules and checkout the sha1 specified in the
> + index.
How about "Initialize the submodules...", and then another sentence "If
you do not want to initialize all submodules, you can specify the subset
to initialize"?
> +-u, --update::
> + Update the specified submodules, i.e. checkout the sha1 specified
> + in the index
The full stop is missing here. And again, I would add another sentence
"Submodules which have not been initialized are not touched by this
operation."
> +FILES
> +-----
> +When cloning submodules, a .gitmodules file in the top-level directory
> +of the containing work-tree is examined for the url of each submodule.
> +The url is the value of the key module.$path.url.
IIRC Junio talked about a name for overriding. But I think it would be
even better to to override by mapping the URLs from .gitmodules to the
locally-wanted URLs.
Junio?
> +When updating submodules, the same .gitmodules file is examined for a key
> +named 'module.$path.branch'. If found, and if the named branch is currently
> +at the same revision as the commit-id in the containing repositories index,
> +the specified branch will be checked out in the submodule. If not found, or
> +if the branch isn't currently positioned at the wanted revision, a checkout
> +of the wanted sha1 will happen in the submodule, leaving its HEAD detached.
A very good description, and I think this is the only method to checkout
the submodule which makes sense. (Just maybe default the value of
module.<path>.branch to "master"?)
> +++ b/git-submodule.sh
> @@ -0,0 +1,178 @@
> +#!/bin/sh
> +#
> +# git-submodules.sh: init, update or list git submodules
> +#
> +# Copyright (c) 2007 Lars Hjemli
> +
> +USAGE='[--init | --update | --cached] [--quiet] [--] [<path>...]'
> +. git-sh-setup
> +require_work_tree
Maybe
test -f "$GIT_DIR"/.gitmodules || die "Not a superproject"
Hmm?
> + rmdir "$path" 2>/dev/null ||
Just out of curiousity: is rmdir portable? I always used "rm -r"...
> +case "$init,$update,$cached" in
> +1,,)
> + modules_init $@
> + ;;
:-)
Now I run out of comments...
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox