* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Junio C Hamano @ 2007-05-24 20:32 UTC (permalink / raw)
To: Sven Verdoolaege; +Cc: Martin Waitz, Jan Hudec, Alex Riesen, git
In-Reply-To: <20070524191438.GZ942MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
[side note: I am ignoring your reply-to: liacs.nl as its MTA
seems to use sorbs that has my ISP's outgoing sender identified
as spam source; I'll send the bounce to you privately in a
separate message.]
> On Thu, May 24, 2007 at 11:58:26AM -0700, Junio C Hamano wrote:
>> Sven Verdoolaege <skimo@kotnet.org> writes:
>> > On Thu, May 24, 2007 at 11:26:01AM -0700, Junio C Hamano wrote:
>> >> (2) In superproject .git/, we would have a bare repository for
>> >> each project used by the superproject.
>> >>
>> >> .git/subproject/kernel26/{objects,refs,...}
>> >>
>> >> This is created by making a bare clone from the upstream
>> >> URL, decided by the user with the help from suggested URL
>> >> described in the superproject .gitmodules.
>> >
>> > Do you mean a "pure" clone, i.e., without a working tree,
>> > but with separate-remotes?
>>
>> I meant a bare clone without separate remotes.
>
> Why without separate remotes?
> It has been argued before that changes in the subproject
> may come from different remotes, so the user may want
> to configure extra remotes from which to fetch.
By different remotes, which do you mean?
(1) .git/subprojects/kernel26/ repository has 'origin'
different from any of the suggested URL in .gitmodules, but
as far as it is concerned there is one 'origin';
or
(2) it has 'origin' that is what the superproject suggests, but
the user locally uses additional repositories to pull and
merge from;
If the former that is not an argument, so I'd assume the
latter. I would say in such a case, you are better off having a
usual repository to manage the development of subproject part,
not grafted to any superproject repository, and handle such
merges there (after all, a "subproject" should stand on its own
without having any of the superproject stuff). And treat THAT
repository as the 'origin' used in (1) above. It might be
easier to use non separate-remote layout in the standalone
repository for the subproject, but that is a separate issue.
>> The counter-proposal outline essentially says, for the sake of
>> simplicity, "nuke existing subproject directory whenever we need
>> to replace it with something else, and reclone a new/replacement
>> subproject directory every time we need to check it out, after
>> making sure nothing is lost".
>
> And she can't do it in the clone in his working tree if that's
> going to get nuked from time to time.
And she does not have to. She can do the development/fixes in
(temporarily) checked out subproject tree, and push it back to
the .git/subproject/kernel26/ repository in the superproject
before she leaves (i.e. before branch switching at superproject
level needs to obliterate it). The change stored in the
.git/subproject/kernel26/ repository in the superproject can
further be pushed back to its 'origin', be it the true
"upstream", or "the standalone repository for the subproject" I
mentioned above.
> But you still need figure out _what_ to fetch.
> Before you suggested to just use the default set up by
> clone with separate remotes, but you no longer have that
> in your new proposal.
I do remember saying the "default set up by clone" but I did not
mean separate remotes.
What is fetched by a bare and non-separate-remote repository vs
a repository that uses separate-remote layout from 'origin' is
exactly the same -- the difference is only 'pure/bare' layout
would use
fetch = refs/heads/*:refs/heads/*
while separate-remotes would use
fetch = refs/heads/*:/refs/remotes/origin/*
So I do not think the difference matters for our purpose of
being able to check out commits that are referenced in
superproject trees. As long as we require that the 'origin' for
"longer term repository to keep track of the subproject in
superproject" (aka repository (2) in my message you are
responding to) always contain the commit referenced by tree
objects in the superproject, which I think is a sensible thing
to require (otherwise you cannot even clone and checkout the
whole superproject), both layout would work equally well. It's
just bare/pure layout is easier to understand because it is
essentially a "mirror" of the upstream.
^ permalink raw reply
* Re: [PATCH] Teach mailsplit about Maildir's
From: Junio C Hamano @ 2007-05-24 20:12 UTC (permalink / raw)
To: Fernando J. Pereda; +Cc: Git Mailing List
In-Reply-To: <20070524195608.GA4714@ferdyx.org>
"Fernando J. Pereda" <ferdy@gentoo.org> writes:
>> > +static int split_maildir(const char *maildir, const char *dir,
>> > + int nr_prec, int skip)
>> > +{
>> > + char file[PATH_MAX];
>> > + char curdir[PATH_MAX];
>> > + char name[PATH_MAX];
>> > int ret = -1;
>> > + struct path_list list = {NULL, 0, 0, 1};
>> >
>> > + snprintf(curdir, sizeof(curdir), "%s/cur", maildir);
>> > + if (populate_maildir_list(&list, curdir) < 0)
>> > + goto out;
>> >
>> > + int i;
>>
>> Decl-after-statement.
>
> I did it because other parts of the file do it too. Do you want me to
> fix the rest of them?
My "gcc -Werror -Wall -Wdeclaration-after-statement" does not
seem to find any in the existing code, but if you found any
please fix that in a separate patch.
>> > @@ -186,9 +249,39 @@ int cmd_mailsplit(int argc, const char **argv, const char *prefix)
>> > ...
>> > + if (ret < 0) {
>> > + error("cannot split patches from %s", arg);
>> > + return 1;
>> > + }
>> > + num += ret;
>> > + }
>> > +
>> > + printf("%d\n", num);
>> >
>> > - return ret == -1;
>> > + return 0;
>> > }
>>
>> We do not signal error anymore from the command?
>
> If we reached that part of the code, there is no error to signal about.
> We signal error when either split_mbox or split_maildir fail by
> returning 1.
Ok, you are right.
Thanks.
^ permalink raw reply
* Re: [PATCH] Teach mailsplit about Maildir's
From: Fernando J. Pereda @ 2007-05-24 19:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vd50qvwaz.fsf@assigned-by-dhcp.cox.net>
On Thu, May 24, 2007 at 12:47:00PM -0700, Junio C Hamano wrote:
> "Fernando J. Pereda" <ferdy@gentoo.org> writes:
> > [--whitespace=<option>] [-C<n>] [-p<n>]
> > - <mbox>...
> > + <mbox>|<Maildir>...
> > +
> > 'git-am' [--skip | --resolved]
>
> Does the document still format Ok if you add a blank line there
> (not a rhetorical question -- I haven't checked)?
I think I tried when I first sent it, will try.
> > +
> > + if ((dir = opendir(path)) == NULL) {
> > + error("cannot diropen %s (%s)", path, strerror(errno));
> > + return -1;
> > + }
>
> Didn't you just fail opendir, not diropen?
Ouch, will fix
> > + return 1;
> > +}
>
> Usually we signal success by returning 0.
Ok. Fair enough.
>
> > +static int split_maildir(const char *maildir, const char *dir,
> > + int nr_prec, int skip)
> > +{
> > + char file[PATH_MAX];
> > + char curdir[PATH_MAX];
> > + char name[PATH_MAX];
> > int ret = -1;
> > + struct path_list list = {NULL, 0, 0, 1};
> >
> > + snprintf(curdir, sizeof(curdir), "%s/cur", maildir);
> > + if (populate_maildir_list(&list, curdir) < 0)
> > + goto out;
> >
> > + int i;
>
> Decl-after-statement.
I did it because other parts of the file do it too. Do you want me to
fix the rest of them?
>
> > + for (i = 0; i < list.nr; i++) {
> > + snprintf(file, sizeof(file), "%s/%s", curdir, list.items[i].path);
> > + FILE *f = fopen(file, "r");
>
> Likewise.
Again, because we were already doing it in other parts of the file. Will
fix.
>
> > @@ -186,9 +249,39 @@ int cmd_mailsplit(int argc, const char **argv, const char *prefix)
> > ...
> > + if (ret < 0) {
> > + error("cannot split patches from %s", arg);
> > + return 1;
> > + }
> > + num += ret;
> > + }
> > +
> > + printf("%d\n", num);
> >
> > - return ret == -1;
> > + return 0;
> > }
>
> We do not signal error anymore from the command?
If we reached that part of the code, there is no error to signal about.
We signal error when either split_mbox or split_maildir fail by
returning 1.
Will fix those issues and send a new patch. Thanks for reviewing it.
- ferdy
--
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
^ permalink raw reply
* Re: [PATCH] Teach mailsplit about Maildir's
From: Junio C Hamano @ 2007-05-24 19:47 UTC (permalink / raw)
To: Fernando J. Pereda; +Cc: Git Mailing List
In-Reply-To: <20070521182052.GB4696@ferdyx.org>
"Fernando J. Pereda" <ferdy@gentoo.org> writes:
> Signed-off-by: Fernando J. Pereda <ferdy@gentoo.org>
> ---
> Documentation/git-am.txt | 8 ++-
> Documentation/git-mailsplit.txt | 13 +++-
> builtin-mailsplit.c | 139 ++++++++++++++++++++++++++++++++-------
> builtin.h | 2 +-
> 4 files changed, 132 insertions(+), 30 deletions(-)
>
> diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
> index ba79773..25cf84a 100644
> --- a/Documentation/git-am.txt
> +++ b/Documentation/git-am.txt
> @@ -12,7 +12,8 @@ SYNOPSIS
> 'git-am' [--signoff] [--dotest=<dir>] [--keep] [--utf8 | --no-utf8]
> [--3way] [--interactive] [--binary]
> [--whitespace=<option>] [-C<n>] [-p<n>]
> - <mbox>...
> + <mbox>|<Maildir>...
> +
> 'git-am' [--skip | --resolved]
Does the document still format Ok if you add a blank line there
(not a rhetorical question -- I haven't checked)?
> diff --git a/builtin-mailsplit.c b/builtin-mailsplit.c
> index 3bca855..454f943 100644
> --- a/builtin-mailsplit.c
> +++ b/builtin-mailsplit.c
> @@ -6,9 +6,10 @@
> */
> #include "cache.h"
> #include "builtin.h"
> +#include "path-list.h"
>
> static const char git_mailsplit_usage[] =
> -"git-mailsplit [-d<prec>] [-f<n>] [-b] -o<directory> <mbox>...";
> +"git-mailsplit [-d<prec>] [-f<n>] [-b] -o<directory> <mbox>|<Maildir>...";
>
> static int is_from_line(const char *line, int len)
> {
> @@ -96,44 +97,106 @@ static int split_one(FILE *mbox, const char *name, int allow_bare)
> exit(1);
> }
>
> -int split_mbox(const char **mbox, const char *dir, int allow_bare, int nr_prec, int skip)
> +static int populate_maildir_list(struct path_list *list, const char *path)
> {
> - char *name = xmalloc(strlen(dir) + 2 + 3 * sizeof(skip));
> + DIR *dir;
> + struct dirent *dent;
> +
> + if ((dir = opendir(path)) == NULL) {
> + error("cannot diropen %s (%s)", path, strerror(errno));
> + return -1;
> + }
Didn't you just fail opendir, not diropen?
> +
> + while ((dent = readdir(dir)) != NULL) {
> + if (dent->d_name[0] == '.')
> + continue;
> + path_list_insert(dent->d_name, list);
> + }
> +
> + closedir(dir);
> +
> + return 1;
> +}
Usually we signal success by returning 0.
> +static int split_maildir(const char *maildir, const char *dir,
> + int nr_prec, int skip)
> +{
> + char file[PATH_MAX];
> + char curdir[PATH_MAX];
> + char name[PATH_MAX];
> int ret = -1;
> + struct path_list list = {NULL, 0, 0, 1};
>
> + snprintf(curdir, sizeof(curdir), "%s/cur", maildir);
> + if (populate_maildir_list(&list, curdir) < 0)
> + goto out;
>
> + int i;
Decl-after-statement.
> + for (i = 0; i < list.nr; i++) {
> + snprintf(file, sizeof(file), "%s/%s", curdir, list.items[i].path);
> + FILE *f = fopen(file, "r");
Likewise.
> @@ -186,9 +249,39 @@ int cmd_mailsplit(int argc, const char **argv, const char *prefix)
> ...
> + if (ret < 0) {
> + error("cannot split patches from %s", arg);
> + return 1;
> + }
> + num += ret;
> + }
> +
> + printf("%d\n", num);
>
> - return ret == -1;
> + return 0;
> }
We do not signal error anymore from the command?
^ permalink raw reply
* Re: [PATCH] name-rev: tolerate clock skew in committer dates
From: Johannes Schindelin @ 2007-05-24 19:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr6p6vxgs.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 24 May 2007, Junio C Hamano wrote:
> This adds a hardcoded slop value (1 day) to the cut-off
> heuristics to work this kind of problem around.
Sounds sensible. (ACK.)
> I think the algorithm could be made a bit smarter by deepening the graph
> on demand as a new commit is asked to be named (this would require
> rewriting of name_rev() function not to recurse itself but use a
> traversal list like revision.c traverser does), but that would be a
> separate issue.
I also wanted to make the decorator (optionally) smarter, to actually do
something like name_rev on demand, which would be much faster than (and
coloured, in contrast to) `git log | git -p name-rev --stdin`.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Junio C Hamano @ 2007-05-24 19:43 UTC (permalink / raw)
To: Martin Waitz; +Cc: Jan Hudec, skimo, Alex Riesen, git
In-Reply-To: <7viraixeme.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
Sorry, I hate to send "amend" message like this, but there are
some places I was not clear enough...
> How about doing something like this, instead?
>
> (1) superproject .gitmodules (in-tree) and .git/config (local
> repository) use the three-level naming in $gmane/47567.
> Namely, (1a) .gitmodules says which subdirectory has a
> checkout of what project, and names the project in
> logical/abstract terms, not with a URL (e.g. "kernel26");
> (1b) .gitmodules also associates a set of suggested URLs
> for each of the logical/abstract project name; (1c)
> .git/config records which project are of interest.
... are of interest, and perhaps which URL to use but that is
not necessary, as we can record that in repositories we create
in (2).
> (2) In superproject .git/, we would have a bare repository for
> each project used by the superproject.
>
> .git/subproject/kernel26/{objects,refs,...}
>
> This is created by making a bare clone from the upstream
> URL, decided by the user with the help from suggested URL
> described in the superproject .gitmodules.
This bare clone probably have its own config that records
remote.origin.url, which would probably be the same as one of
the URL suggested in .gitmodules for many people, but could be
different. As to what should happen when the .gitmodules that
comes from the upstream changes the set of suggested URLs
recorded in there, see $gmane/47621,
> The idea is to use this repository as a long-term
> subproject state across branch switching.
>
> (3) When we need to check out a revision of superproject whose
> .gitmodules has "kernel-src/ -> kernel26", and when we
> haven't done so (perhaps we are doing an initial checkout,
> perhaps we are switching from a different revision of the
> superproject that did not have "kernel26" project at
> kernel-src/ directory), we rm -f kernel-src/ and then
> "git-clone -l -s" from the repository we keep in (2) to
> populate kernel-src/ directory.
The last part of the above should have been:
we "rm -fr kernel-src/" and then "git-clone -l -s -n"
from the repository we keep in (2). And then check out
the commit that is pointed at by the superproject tree
(rather, "index").
> (4) Before performing the above step (3), we need to make sure
> we are not losing anything in kernel-src/ if exists. Three
> cases plus one:
>
> (4a) The path kernel-src/ in the old checkout was not a
> subproject (either it did not exist, it was a blob, or it
> was a directory with files that are tracked as part of the
> superproject). The usual "don't lose local modification"
> rule we use try to carry local changes forward across
> branch switching, but in this case we shouldn't do so.
The last part of the above should have been:
... but in this case we shouldn't even try to carry local
changes forward, as there is nowhere to carry them to.
Instead we should error out and have the user clean-up
the subproject repository (either "git reset", or "git
commit && git push" to stash the change back to
repository we prepared in (2)). We might also want to
allow the user to say "local changes in this subproject
checkout does not matter" by saying "git checkout -f
$commit" at the superproject level, but I think that is
rather dangerous.
> (4b) It has the same logical/abstract project checked out;
> ...
> (4c) It has a different project checked out; we need to be
> careful to keep local changes, and also we need to make
> sure the local changes in this subproject repository are
> pushed back to (2). It could be that automated "git push"
> after making sure everything is committed is sufficient and
> have the user handle failure cases.
>
> (4d) This applies not just "before step (3)", but in cases
> where we need to replace a checked out subproject directory
> with something else (e.g. blob or directory that belong to
> the superproject, or noneness). We would need to make sure
> no local change is lost, and the repository is synched up
> with (2).
... which is the same check and action we would do in case (4c).
^ permalink raw reply
* Re: Make "git gc" pack all refs by default
From: Johannes Schindelin @ 2007-05-24 19:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0705241132400.26602@woody.linux-foundation.org>
Hi,
On Thu, 24 May 2007, Linus Torvalds wrote:
> I've taught myself to use "git gc" instead of doing the repack explicitly,
> but it doesn't actually do what I think it should do.
>
> We've had packed refs for a long time now, and I think it just makes sense
> to pack normal branches too.
FWIW I already suggested that:
http://article.gmane.org/gmane.comp.version-control.git/28533
Since there seemed not much interest in that, I let it slip.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-24 19:25 UTC (permalink / raw)
To: Lars Hjemli
Cc: Junio C Hamano, Linus Torvalds, skimo, Shawn O. Pearce, git,
Martin Waitz, Alex Riesen
In-Reply-To: <8c5c35580705241213y64f8ec5eg1f1afbdf25413769@mail.gmail.com>
Hi,
On Thu, 24 May 2007, Lars Hjemli wrote:
> On 5/24/07, Junio C Hamano <junkio@cox.net> wrote:
> > While I disagree with some design decisions Sven's series made,
> > I am happy that the series is there for people to comment on.
> > It helps us identify the design issues by making the differences
> > of opinion people have on them stand out.
> >
>
> Possibly offtopic: I'm not so sure there should be any --submodules or
> similar options to clone/fetch/checkout/merge/diff etc.
>
> What I think would be nice is some porcelain support to manually init,
> update and see the checked out version of selected subprojects, but as
> standalone commands.
Yes, a la git-remote. I'd be much happier with that, too, especially since
I think that this can be a relatively small and easy-to-review script. I
really was intimidated by the long patch series, also because I thought
that it shouldn't be that much work on top of what Linus did.
Ciao,
Dscho
P.S.: Linus paid for his Caps Lock key, so he might as well use it.
^ permalink raw reply
* [PATCH] name-rev: tolerate clock skew in committer dates
From: Junio C Hamano @ 2007-05-24 19:21 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In git.git repository, "git-name-rev v1.3.0~158" cannot name the
rev, while adjacent revs can be named.
This was because it gives up traversal from the tips of existing
refs as soon as it sees a commit that has older commit timestamp
than what is being named. This is usually a good heuristics,
but v1.3.0~158 has a slightly older commit timestamp than
v1.3.0~157 (i.e. it's child), as these two were made in a
separate repostiory (in fact, in a different continent).
This adds a hardcoded slop value (1 day) to the cut-off
heuristics to work this kind of problem around. The current
algorithm essentially runs around from the available tips down
to ancient commits and names every single rev available that are
newer than cut-off date, so a single day slop would not add that
much overhead in repositories with long enough history where the
performance of name-rev matters.
I think the algorithm could be made a bit smarter by deepening
the graph on demand as a new commit is asked to be named (this
would require rewriting of name_rev() function not to recurse
itself but use a traversal list like revision.c traverser does),
but that would be a separate issue.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
builtin-name-rev.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-name-rev.c b/builtin-name-rev.c
index a639e2f..d3c42ed 100644
--- a/builtin-name-rev.c
+++ b/builtin-name-rev.c
@@ -4,6 +4,8 @@
#include "tag.h"
#include "refs.h"
+#define CUTOFF_DATE_SLOP 86400 /* one day */
+
static const char name_rev_usage[] =
"git-name-rev [--tags | --refs=<pattern>] ( --all | --stdin | committish [committish...] )\n";
@@ -216,6 +218,8 @@ int cmd_name_rev(int argc, const char **argv, const char *prefix)
add_object_array((struct object *)commit, *argv, &revs);
}
+ if (cutoff)
+ cutoff = cutoff - CUTOFF_DATE_SLOP;
for_each_ref(name_ref, &data);
if (transform_stdin) {
--
1.5.2.58.g98ee
^ permalink raw reply related
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Sven Verdoolaege @ 2007-05-24 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Waitz, Jan Hudec, Alex Riesen, git
In-Reply-To: <7vy7jevyjx.fsf@assigned-by-dhcp.cox.net>
On Thu, May 24, 2007 at 11:58:26AM -0700, Junio C Hamano wrote:
> Sven Verdoolaege <skimo@kotnet.org> writes:
> > On Thu, May 24, 2007 at 11:26:01AM -0700, Junio C Hamano wrote:
> >> (2) In superproject .git/, we would have a bare repository for
> >> each project used by the superproject.
> >>
> >> .git/subproject/kernel26/{objects,refs,...}
> >>
> >> This is created by making a bare clone from the upstream
> >> URL, decided by the user with the help from suggested URL
> >> described in the superproject .gitmodules.
> >
> > Do you mean a "pure" clone, i.e., without a working tree,
> > but with separate-remotes?
>
> I meant a bare clone without separate remotes.
Why without separate remotes?
It has been argued before that changes in the subproject
may come from different remotes, so the user may want
to configure extra remotes from which to fetch.
> The counter-proposal outline essentially says, for the sake of
> simplicity, "nuke existing subproject directory whenever we need
> to replace it with something else, and reclone a new/replacement
> subproject directory every time we need to check it out, after
> making sure nothing is lost".
And she can't do it in the clone in his working tree if that's
going to get nuked from time to time.
> If we were to follow the outline in the counter-proposal, I'd
> imagine that update of (2) can happen at any time. It could be
> part of "git fetch" in superprojects, of lazily done when we
> need to checkout a new revision for a particular subproject, but
> only if the last time you fetched superproject is more recent
> than the time you updated (2) for the subproject last time.
>
> Or something like that. I consider that also a minor detail in
> the implementation.
But you still need figure out _what_ to fetch.
Before you suggested to just use the default set up by
clone with separate remotes, but you no longer have that
in your new proposal.
skimo
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Lars Hjemli @ 2007-05-24 19:13 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, skimo, Johannes Schindelin, Shawn O. Pearce, git,
Martin Waitz, Alex Riesen
In-Reply-To: <7v7iqyxdp6.fsf@assigned-by-dhcp.cox.net>
On 5/24/07, Junio C Hamano <junkio@cox.net> wrote:
> While I disagree with some design decisions Sven's series made,
> I am happy that the series is there for people to comment on.
> It helps us identify the design issues by making the differences
> of opinion people have on them stand out.
>
Possibly offtopic: I'm not so sure there should be any --submodules or
similar options to clone/fetch/checkout/merge/diff etc.
What I think would be nice is some porcelain support to manually init,
update and see the checked out version of selected subprojects, but as
standalone commands.
This would make it easier to start using subprojects, and it wouldn't
force any specific politics on it. And hopefully the experience of
actually using subprojects will make it more obvious how to add
extended support later on.
Just my 2c
--
larsh
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Junio C Hamano @ 2007-05-24 18:58 UTC (permalink / raw)
To: skimo; +Cc: Martin Waitz, Jan Hudec, Alex Riesen, git
In-Reply-To: <20070524184549.GW942MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> On Thu, May 24, 2007 at 11:26:01AM -0700, Junio C Hamano wrote:
>> How about doing something like this, instead?
>>
>> (1) superproject .gitmodules (in-tree) and .git/config (local
>> repository) use the three-level naming in $gmane/47567.
>> Namely, (1a) .gitmodules says which subdirectory has a
>> checkout of what project, and names the project in
>> logical/abstract terms, not with a URL (e.g. "kernel26");
>> (1b) .gitmodules also associates a set of suggested URLs
>> for each of the logical/abstract project name; (1c)
>> .git/config records which project are of interest.
>
> What about the idea of considering any project that is already
> present to be of interest by default ?
You could do that -- I consider that a minor detail in the
implementation.
>> (2) In superproject .git/, we would have a bare repository for
>> each project used by the superproject.
>>
>> .git/subproject/kernel26/{objects,refs,...}
>>
>> This is created by making a bare clone from the upstream
>> URL, decided by the user with the help from suggested URL
>> described in the superproject .gitmodules.
>
> Do you mean a "pure" clone, i.e., without a working tree,
> but with separate-remotes?
I meant a bare clone without separate remotes.
The counter-proposal outline essentially says, for the sake of
simplicity, "nuke existing subproject directory whenever we need
to replace it with something else, and reclone a new/replacement
subproject directory every time we need to check it out, after
making sure nothing is lost".
Except that having this intermediate repository (a) helps making
such a re-clone extremely cheap "git clone -l -s -n", and (b)
provides with a place to hold locally committed changes that are
not pushed back to the true upstream (you may _never_ push it
back in the first place).
>> (4b) It has the same logical/abstract project checked out;
>> the commit recorded in the superproject tree may or may not
>> be the same as what its HEAD points at. In this case we do
>> not have to worry about swapping the git repository at
>> kernel-src/ directory, although we would need to check out
>> the correct revision, and worry about what to do with any
>> local modification (I think the usual "don't lose local
>> modification but carry them forward" rule would be Ok in
>> this case).
>
> We may also need to fetch from the remote subproject.
> Should I do this with a "git fetch" during the checkout as I do now?
If you are disconnected, you obviously cannot afford to update
(2) every time you switch branches in the superproject, and even
if you are connected, updating (2) would not be needed most of
the time if what you are doing is switching superproject
branches, as long as your last superproject fetch is not very
much more recent than your last subproject fetch.
If we were to follow the outline in the counter-proposal, I'd
imagine that update of (2) can happen at any time. It could be
part of "git fetch" in superprojects, of lazily done when we
need to checkout a new revision for a particular subproject, but
only if the last time you fetched superproject is more recent
than the time you updated (2) for the subproject last time.
Or something like that. I consider that also a minor detail in
the implementation.
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Junio C Hamano @ 2007-05-24 18:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: skimo, Lars Hjemli, Johannes Schindelin, Shawn O. Pearce, git,
Martin Waitz, Alex Riesen
In-Reply-To: <alpine.LFD.0.98.0705241105210.26602@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 24 May 2007, Sven Verdoolaege wrote:
>> ...
>> What if someone is working on his own branch of the superproject
>> that needs some changes in his own subproject?
>> He needs to modify .gitmodules, but when the changes go upstream,
>> this .gitmodules changes get merged as well.
>> Now imagine several developers doing this.
>> You end up continually having to modify .gitmodules.
>
> Ehh. What drugs are you on?
>
> That's the whole point of having local overrides. You use them for local
> branches. You do _not_ use .gitmodules for those.
>
> So ".gitmodules" is the default for people who don't do anything special.
> Only people who change the _default_ would ever change that.
>
> I really don't understand or see your objections at all. You are making
> totally idiotic arguments BASED ON DOING OBVIOUSLY STUPID THINGS. That's
> not an argument.
While I agree with the three-level thing that uses .gitmodules
and take the information from .git/config would solve the
problem, I do not think you need to shout.
While I disagree with some design decisions Sven's series made,
I am happy that the series is there for people to comment on.
It helps us identify the design issues by making the differences
of opinion people have on them stand out.
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Sven Verdoolaege @ 2007-05-24 18:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Waitz, Jan Hudec, Alex Riesen, git
In-Reply-To: <7viraixeme.fsf@assigned-by-dhcp.cox.net>
On Thu, May 24, 2007 at 11:26:01AM -0700, Junio C Hamano wrote:
> How about doing something like this, instead?
>
> (1) superproject .gitmodules (in-tree) and .git/config (local
> repository) use the three-level naming in $gmane/47567.
> Namely, (1a) .gitmodules says which subdirectory has a
> checkout of what project, and names the project in
> logical/abstract terms, not with a URL (e.g. "kernel26");
> (1b) .gitmodules also associates a set of suggested URLs
> for each of the logical/abstract project name; (1c)
> .git/config records which project are of interest.
What about the idea of considering any project that is already
present to be of interest by default ?
> (2) In superproject .git/, we would have a bare repository for
> each project used by the superproject.
>
> .git/subproject/kernel26/{objects,refs,...}
>
> This is created by making a bare clone from the upstream
> URL, decided by the user with the help from suggested URL
> described in the superproject .gitmodules.
Do you mean a "pure" clone, i.e., without a working tree,
but with separate-remotes?
> (4b) It has the same logical/abstract project checked out;
> the commit recorded in the superproject tree may or may not
> be the same as what its HEAD points at. In this case we do
> not have to worry about swapping the git repository at
> kernel-src/ directory, although we would need to check out
> the correct revision, and worry about what to do with any
> local modification (I think the usual "don't lose local
> modification but carry them forward" rule would be Ok in
> this case).
We may also need to fetch from the remote subproject.
Should I do this with a "git fetch" during the checkout as I do now?
skimo
^ permalink raw reply
* Make "git gc" pack all refs by default
From: Linus Torvalds @ 2007-05-24 18:41 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
I've taught myself to use "git gc" instead of doing the repack explicitly,
but it doesn't actually do what I think it should do.
We've had packed refs for a long time now, and I think it just makes sense
to pack normal branches too. So I end up having to do
git pack-refs --all --prune
in order to get a nice git repo that doesn't have any unnecessary files.
So why not just do that in "git gc"? It's not as if there really is any
downside to packing branches, even if they end up changing later. Quite
often they don't, and even if they do, so what?
Also, make the default for refs packing just be an unambiguous "do it",
rather than "do it by default only for non-bare repositories". If you want
that behaviour, you can always just add a
[gc]
packrefs = notbare
in your ~/.gitconfig file, but I don't actually see why bare would be any
different (except for the broken reason that http-fetching used to be
totally broken, and not doing it just meant that it didn't even get
fixed in a timely manner!).
So here's a trivial patch to make "git gc" do a better job. Hmm?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
Side note: I'd also like to get rid of "info/refs", and just make http
fetching use "packed-refs" instead. That would imply that
"update_server_info()" should do "git pack-refs --all" too! This patch
doesn't do it, though.
builtin-gc.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index 8ea165a..45025fb 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -17,11 +17,11 @@
static const char builtin_gc_usage[] = "git-gc [--prune] [--aggressive]";
-static int pack_refs = -1;
+static int pack_refs = 1;
static int aggressive_window = -1;
#define MAX_ADD 10
-static const char *argv_pack_refs[] = {"pack-refs", "--prune", NULL};
+static const char *argv_pack_refs[] = {"pack-refs", "--all", "--prune", NULL};
static const char *argv_reflog[] = {"reflog", "expire", "--all", NULL};
static const char *argv_repack[MAX_ADD] = {"repack", "-a", "-d", "-l", NULL};
static const char *argv_prune[] = {"prune", NULL};
^ permalink raw reply related
* Re: [RFC] Fourth round of support for cloning submodules
From: Junio C Hamano @ 2007-05-24 18:38 UTC (permalink / raw)
To: Linus Torvalds
Cc: Lars Hjemli, Johannes Schindelin, skimo, Shawn O. Pearce, git,
Martin Waitz, Alex Riesen
In-Reply-To: <alpine.LFD.0.98.0705241030440.26602@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> I actually really liked Junio's suggestion of
>
> [subproject "git://git.kernel.org/pub/linux-2.4.git"]
> URL = http://www.kernel.org/pub/linux-2.4.git
> ...
> Note how that example had nothing to do with subprojects per se: the URL
> rewriting is really another issue. But yes, I think it might also be worth
> it to actually be able to override the whole subproject data, ie also have
>
> [subproject "kernel/"]
> url = ...
> branch = xyzzy
>
> and allow that kind of information in .git/config to _override_ any such
> entry in .gitmodules!
I just sent out a rather longish message that peripherally
touches this and said I liked the three-level thing Steven Grimm
suggested, which is essentially what you wrote above.
I am reasonably happy that we are in agreement and I was not way
off in the design area by myself.
^ permalink raw reply
* Re: [PATCH 07/16] git-read-tree: take --submodules option
From: Junio C Hamano @ 2007-05-24 18:26 UTC (permalink / raw)
To: Martin Waitz; +Cc: Jan Hudec, skimo, Alex Riesen, git
In-Reply-To: <20070521211133.GD5412@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> On Mon, May 21, 2007 at 06:59:38PM +0200, Jan Hudec wrote:
>> Here is one possible idea:
>>
>> We could store the GIT_DIR of submodule within the GIT_DIR of the
>> superproject instead of the submodule directory itself. So instead of:
>> /
>> /.git
>> /subdir
>> /subdir/.git
>>
>> There would be:
>> /
>> /.git
>> /subdir
>> /.git/submodules/submodule-name.git
>>
>> This would require changes to the logic how git finds GIT_DIR (which would be
>> really deep change), but it would provide place to store the submodule data
>> while the submodule is not being checked out.
>
> I agree that we need something like that.
>
> We don't have to move the entire subproject.git into the superproject,
> but we need to have all _referenced_ objects in the .git dir of the
> superproject.
>
> There are several possibilities to do so:
>
> * move the entire .git dir
> * move .git/objects
> * explicitly copy all referenced objects
I was hoping that we can start from an initial cut that supports
only a superproject that had its subprojects in their places
from its initial commit, and did not have to worry about this
from day one, and deal with this kind of "more advanced" stuff
incrementally. Unfortunately it's more fun to talk about more
advanced stuff than starting with small but solid stuff.
And we would need to make sure whatever we do as the "small but
solid" initial round can later support more advanced
arrangements later, so we would need to think about the issues
now anyway to a certain degree.
How about doing something like this, instead?
(1) superproject .gitmodules (in-tree) and .git/config (local
repository) use the three-level naming in $gmane/47567.
Namely, (1a) .gitmodules says which subdirectory has a
checkout of what project, and names the project in
logical/abstract terms, not with a URL (e.g. "kernel26");
(1b) .gitmodules also associates a set of suggested URLs
for each of the logical/abstract project name; (1c)
.git/config records which project are of interest.
(2) In superproject .git/, we would have a bare repository for
each project used by the superproject.
.git/subproject/kernel26/{objects,refs,...}
This is created by making a bare clone from the upstream
URL, decided by the user with the help from suggested URL
described in the superproject .gitmodules.
The idea is to use this repository as a long-term
subproject state across branch switching.
(3) When we need to check out a revision of superproject whose
.gitmodules has "kernel-src/ -> kernel26", and when we
haven't done so (perhaps we are doing an initial checkout,
perhaps we are switching from a different revision of the
superproject that did not have "kernel26" project at
kernel-src/ directory), we rm -f kernel-src/ and then
"git-clone -l -s" from the repository we keep in (2) to
populate kernel-src/ directory.
(4) Before performing the above step (3), we need to make sure
we are not losing anything in kernel-src/ if exists. Three
cases plus one:
(4a) The path kernel-src/ in the old checkout was not a
subproject (either it did not exist, it was a blob, or it
was a directory with files that are tracked as part of the
superproject). The usual "don't lose local modification"
rule we use try to carry local changes forward across
branch switching, but in this case we shouldn't do so.
(4b) It has the same logical/abstract project checked out;
the commit recorded in the superproject tree may or may not
be the same as what its HEAD points at. In this case we do
not have to worry about swapping the git repository at
kernel-src/ directory, although we would need to check out
the correct revision, and worry about what to do with any
local modification (I think the usual "don't lose local
modification but carry them forward" rule would be Ok in
this case).
(4c) It has a different project checked out; we need to be
careful to keep local changes, and also we need to make
sure the local changes in this subproject repository are
pushed back to (2). It could be that automated "git push"
after making sure everything is committed is sufficient and
have the user handle failure cases.
(4d) This applies not just "before step (3)", but in cases
where we need to replace a checked out subproject directory
with something else (e.g. blob or directory that belong to
the superproject, or noneness). We would need to make sure
no local change is lost, and the repository is synched up
with (2).
I think an arrangement like this would solve "symlink is a bitch
for MinGW" problem Johannes Sixt brought up today with Sven's
RFC as well.
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Linus Torvalds @ 2007-05-24 18:09 UTC (permalink / raw)
To: skimo
Cc: Junio C Hamano, Lars Hjemli, Johannes Schindelin, Shawn O. Pearce,
git, Martin Waitz, Alex Riesen
In-Reply-To: <20070524175519.GU942MdfPADPa@greensroom.kotnet.org>
On Thu, 24 May 2007, Sven Verdoolaege wrote:
>
> If you allow an override, then I don't see how having the initial
> information in the tree is any better.
> When new information gets in from the tree, you're going to ignore it anyway.
Well, duh. "Paging Mr Ovious".
IF you have local overrides they get ignored.
Which is what _should_ happen, of course.
> What if someone is working on his own branch of the superproject
> that needs some changes in his own subproject?
> He needs to modify .gitmodules, but when the changes go upstream,
> this .gitmodules changes get merged as well.
> Now imagine several developers doing this.
> You end up continually having to modify .gitmodules.
Ehh. What drugs are you on?
That's the whole point of having local overrides. You use them for local
branches. You do _not_ use .gitmodules for those.
So ".gitmodules" is the default for people who don't do anything special.
Only people who change the _default_ would ever change that.
I really don't understand or see your objections at all. You are making
totally idiotic arguments BASED ON DOING OBVIOUSLY STUPID THINGS. That's
not an argument.
Linus
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-24 18:11 UTC (permalink / raw)
To: skimo
Cc: Linus Torvalds, Junio C Hamano, Lars Hjemli, Shawn O. Pearce, git,
Martin Waitz, Alex Riesen
In-Reply-To: <20070524175519.GU942MdfPADPa@greensroom.kotnet.org>
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
> On Thu, May 24, 2007 at 10:40:52AM -0700, Linus Torvalds wrote:
> >
> >
> > On Thu, 24 May 2007, Junio C Hamano wrote:
> > >
> > > Why does this have to be out-of-tree and unversioned to begin
> > > with?
> >
> > I _really_ think that the right approach is to
> >
> > - have the submodules information under version control (and I'd
> > personally call it the ".gitmodules" file, but whatever)
> >
> > This gives you the defaults, and the ability to change them. Remember:
> > if you get some "config" information at "git clone" time, you're
> > *screwed* if the thing ever changes!
>
> If you allow an override, then I don't see how having the initial
> information in the tree is any better.
Isn't that obvious? _Most_ people will _not_ override the information.
Plus, it is an easy solution to your problem, without having to touch a
lot of real core parts of Git. Simple is beautiful. And less buggy.
> When new information gets in from the tree, you're going to ignore it
> anyway.
No. Not if it is _not_ overridden.
> What happens if the URL changes?
> You have to modify .gitmodules in _every_ branch you have?
Oh yes. Exactly the same as when you have an INSTALL file and the URL of
some project changes which your project depends on. That's life.
> What if someone is working on his own branch of the superproject
> that needs some changes in his own subproject?
Uhm. Then you can either just override that URL, _or_ you can branch from
the superproject, changing .gitmodules as you wish.
> He needs to modify .gitmodules, but when the changes go upstream,
> this .gitmodules changes get merged as well.
If you change the superproject, that is. And then only if you don't have a
to-merge branch. Your problem is not specific to superprojects, and it has
been solved already.
> Now imagine several developers doing this.
> You end up continually having to modify .gitmodules.
No, just your config. Once.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Johannes Schindelin @ 2007-05-24 18:07 UTC (permalink / raw)
To: skimo; +Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <20070524174252.GT942MdfPADPa@greensroom.kotnet.org>
Hi,
On Thu, 24 May 2007, Sven Verdoolaege wrote:
> On Thu, May 24, 2007 at 02:52:25PM +0100, Johannes Schindelin wrote:
> > It is not that expensive to just give the SHA-1 with the URL, and to
> > introduce a new namespace, say
> >
> > 3f... submodule/path^{URL:blablub}
> >
> > to say that the submodule which is connected in "HEAD:path" is available
> > with the URL "blablub" and just so happens to be at commit "3f..." at the
> > moment. Heck, you can even use this instead of expensive fetches to verify
> > up-to-date, and even more, you can make sure that you are as up-to-date as
> > the remote supermodule.
>
> What about all the other branches?
> Also, the submodule may not even be in any of the tips of the branches.
Okay, bad idea.
> > Without some very intrusive surgery into the transport code of Git, in 22
> > patches, which I am not at all comfortable with.
>
> You're not comfortable with the number or with the patches?
> There's only about four or five that deal with this git-config stuff
> and any other mechanism would have to implemented as well.
If it was even only one, which is as intrusive, I would still be
uncomfortable. And yes, the large number does not make me want to review
the series either.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 17:55 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, Lars Hjemli, Johannes Schindelin, Shawn O. Pearce,
git, Martin Waitz, Alex Riesen
In-Reply-To: <alpine.LFD.0.98.0705241030440.26602@woody.linux-foundation.org>
On Thu, May 24, 2007 at 10:40:52AM -0700, Linus Torvalds wrote:
>
>
> On Thu, 24 May 2007, Junio C Hamano wrote:
> >
> > Why does this have to be out-of-tree and unversioned to begin
> > with?
>
> I _really_ think that the right approach is to
>
> - have the submodules information under version control (and I'd
> personally call it the ".gitmodules" file, but whatever)
>
> This gives you the defaults, and the ability to change them. Remember:
> if you get some "config" information at "git clone" time, you're
> *screwed* if the thing ever changes!
If you allow an override, then I don't see how having the initial
information in the tree is any better.
When new information gets in from the tree, you're going to ignore it anyway.
What happens if the URL changes?
You have to modify .gitmodules in _every_ branch you have?
What if someone is working on his own branch of the superproject
that needs some changes in his own subproject?
He needs to modify .gitmodules, but when the changes go upstream,
this .gitmodules changes get merged as well.
Now imagine several developers doing this.
You end up continually having to modify .gitmodules.
skimo
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Linus Torvalds @ 2007-05-24 17:40 UTC (permalink / raw)
To: Junio C Hamano
Cc: Lars Hjemli, Johannes Schindelin, skimo, Shawn O. Pearce, git,
Martin Waitz, Alex Riesen
In-Reply-To: <7vabvuywix.fsf@assigned-by-dhcp.cox.net>
On Thu, 24 May 2007, Junio C Hamano wrote:
>
> Why does this have to be out-of-tree and unversioned to begin
> with?
I _really_ think that the right approach is to
- have the submodules information under version control (and I'd
personally call it the ".gitmodules" file, but whatever)
This gives you the defaults, and the ability to change them. Remember:
if you get some "config" information at "git clone" time, you're
*screwed* if the thing ever changes!
So being version-controlled is not just a good idea. It's a
_requirement_ for working well.
- have a way to *override* the version-controlled information using a
local config file.
This is what you'd use to say "ignore the official information, it's
either slow (because the "official" server is on another continent) or
outdated (because the server went away)".
I actually really liked Junio's suggestion of
[subproject "git://git.kernel.org/pub/linux-2.4.git"]
URL = http://www.kernel.org/pub/linux-2.4.git
except I would actually make it a bit more generic, in that I don't think
this kind of "URL rewriting" is necessarily even subproject-specific, but
could be useful in general. IOW, it might be a good idea to have
[url "git://git.kernel.org/pub/linux-2.4.git"]
rewrite = "ssh://master.kernel.org/pub/linux-2.4.git"
or something - which allows people to set up automatic rewriting rules in
case they have alternate ways of getting to better repositories (ie people
might send me a "please pull" request with a pointer to the _public_ site,
because they also Cc: the kernel mailing list, but since I have direct SSH
access to the master site, _I_ might want to rewrite it to use that
instead!).
Note how that example had nothing to do with subprojects per se: the URL
rewriting is really another issue. But yes, I think it might also be worth
it to actually be able to override the whole subproject data, ie also have
[subproject "kernel/"]
url = ...
branch = xyzzy
and allow that kind of information in .git/config to _override_ any such
entry in .gitmodules!
Linus
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 17:42 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Shawn O. Pearce, Junio C Hamano, git, Martin Waitz, Alex Riesen
In-Reply-To: <Pine.LNX.4.64.0705241446070.4648@racer.site>
On Thu, May 24, 2007 at 02:52:25PM +0100, Johannes Schindelin wrote:
> It is not that expensive to just give the SHA-1 with the URL, and to
> introduce a new namespace, say
>
> 3f... submodule/path^{URL:blablub}
>
> to say that the submodule which is connected in "HEAD:path" is available
> with the URL "blablub" and just so happens to be at commit "3f..." at the
> moment. Heck, you can even use this instead of expensive fetches to verify
> up-to-date, and even more, you can make sure that you are as up-to-date as
> the remote supermodule.
What about all the other branches?
Also, the submodule may not even be in any of the tips of the branches.
> Without some very intrusive surgery into the transport code of Git, in 22
> patches, which I am not at all comfortable with.
You're not comfortable with the number or with the patches?
There's only about four or five that deal with this git-config stuff
and any other mechanism would have to implemented as well.
skimo
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-24 17:38 UTC (permalink / raw)
To: Junio C Hamano
Cc: Lars Hjemli, Johannes Schindelin, Shawn O. Pearce, git,
Martin Waitz, Alex Riesen
In-Reply-To: <7vabvuywix.fsf@assigned-by-dhcp.cox.net>
On Thu, May 24, 2007 at 10:13:58AM -0700, Junio C Hamano wrote:
> When you are bootstrapping, you will start by a fetch/clone of
> the superproject. Why can't that tree contain necessary
> information that is relevant to the superproject in question?
Because git is a distributed SCM.
> Isn't the information about which subprojects are used by the
> superproject specific to each superproject, and also specific to
> each version of the superproject (as a superproject can start
> using more projects than it did before)?
Perhaps for some information, but not for the "preferred" URL
to get the subprojects from. That may change in time (independently
of any changes in the superproject itself) and they
will be different for different copies of the same superproject.
skimo
^ permalink raw reply
* Re: [RFC] Fourth round of support for cloning submodules
From: Lars Hjemli @ 2007-05-24 17:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, skimo, Shawn O. Pearce, git, Martin Waitz,
Alex Riesen
In-Reply-To: <7vabvuywix.fsf@assigned-by-dhcp.cox.net>
On 5/24/07, Junio C Hamano <junkio@cox.net> wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > I think the whole point of the 'remote config' stuff is to get an
> > unversioned/out-of-tree .gitmodules file, right?
>
> Why does this have to be out-of-tree and unversioned to begin
> with?
Probably to cater for subprojects moving away from the url mentioned
in the versioned .gitmodules file.
> When you are bootstrapping, you will start by a fetch/clone of
> the superproject. Why can't that tree contain necessary
> information that is relevant to the superproject in question?
It sure can, and it would be the most natural solution. I just wanted
to mention an alternative to the 'git config --remote' solution.
--
larsh
^ 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