* Re: [RFC] Introduce "git stage" (along with some heresy)
From: Marko Macek @ 2006-12-01 20:44 UTC (permalink / raw)
To: git
In-Reply-To: <87slfzfri7.wl%cworth@cworth.org>
Carl Worth wrote:
> [This message, (yes,another long one from me), proposes 3 changes. The
> first should be uncontroversial I think, while the second and third
> are clear heresy, (and the second would require some amount of
> re-training or re-configuration by existing git user). Pick and choose
> as you see fit. I don't think they actually depend on each other,
> though I'll present them here as parts of a whole.]
/me likes (both emails).
Q: should git-commit require either -a or --staged when there is a
staged commit?
Mark
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-01 21:04 UTC (permalink / raw)
To: git
In-Reply-To: <20061201193802.GI18810@admingilde.org>
On Friday 2006, December 01 19:38, Martin Waitz wrote:
> On Fri, Dec 01, 2006 at 07:17:17PM +0000, Andy Parkins wrote:
> > In fact, why should the submodule commits be even visible in the
> > supermodule? That tree->submodule commit is sufficient; there isn't
> > any need to view submodule history in the supermodule.
>
> Well, but there is a need for a common object traversal.
> You need that when sending all objects between two supermodule versions
> and also when you determine which objects are still reachable.
No you don't; when traversing the supermodule history you will come across
trees that have submodule commit hashes in them, that is all the other end
needs to know. If it wants it can then connect to the submodule and clone
submodule to submodule. The whole operation doesn't have to be done in the
supermodule though.
> The easiest way to implement the common object traversal is to have all
> objects in one object repository.
That's true; but is it the right way? I really really think the submodule
objects should be in the submodule itself.
> It may be possible to use two object stores and still do the common
> object traversal but I do not think that gives you any benefits.
There is one benefit - you can git-clone the submodule just as you would if it
were not a submodule. In fact, from the submodule's point of view it knows
nothing about the supermodule.
> You still don't have a totally separated repository then, because
> you can't do a reachability analysis in the submodule repository alone.
I'm going to guess by reachability analysis, you mean that the submodule
doesn't know that some of it's commits are referenced by the supermodule. As
I suggested elsewhere in the thread, that's easily fixed by making a
refs/supermodule/commitXXXX file for each supermodule commit that references
as particular submodule commit. Then you can git-prune, git-fsck whenever
you want.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* GIT plugin for Jira (issue tracker)
From: Sean Kelley @ 2006-12-01 21:28 UTC (permalink / raw)
To: git
I was curious if anyone has created a GIT plugin for the Jira issue
tracker? I have come across a mercurial plugin. I have an idea that
I could nightly track our GIT repository with mercurial then I could
use the mercurial plugin with Jira. But I wanted to check first on
the existence of a GIT plugin for Jira.[1]
Thanks,
Sean
[1] http://www.atlassian.com/software/jira/
--
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 21:37 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612012104.39897.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1002 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 09:04:37PM +0000, Andy Parkins wrote:
> > It may be possible to use two object stores and still do the common
> > object traversal but I do not think that gives you any benefits.
>
> There is one benefit - you can git-clone the submodule just as you
> would if it were not a submodule. In fact, from the submodule's point
> of view it knows nothing about the supermodule.
The submodule repository obviously has to able to reach all its objects.
This is easily doable with the shared object database.
So you can already clone the submodule standalone.
> I'm going to guess by reachability analysis, you mean that the
> submodule doesn't know that some of it's commits are referenced by the
> supermodule. As I suggested elsewhere in the thread, that's easily
> fixed by making a refs/supermodule/commitXXXX file for each
> supermodule commit that references as particular submodule commit.
I wouldn't call this "easily".
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-01 21:54 UTC (permalink / raw)
To: git
In-Reply-To: <20061201213722.GK18810@admingilde.org>
On Friday 2006, December 01 21:37, Martin Waitz wrote:
> > I'm going to guess by reachability analysis, you mean that the
> > submodule doesn't know that some of it's commits are referenced by the
> > supermodule. As I suggested elsewhere in the thread, that's easily
> > fixed by making a refs/supermodule/commitXXXX file for each
> > supermodule commit that references as particular submodule commit.
>
> I wouldn't call this "easily".
Of course it is; when you write a supermodule commit you have it's hash,
$SUPERMODULE_HASH, you have the commit-hash of the submodule commit you're
referencing, $SUBMODULE_HASH. It's not really hard to do
echo $SUBMODULE_HASH >
submodule/.git/refs/supermodules/commit$SUPERMODULE_HASH
Is it?
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Josef Weidendorfer @ 2006-12-01 22:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sf, git, Martin Waitz
In-Reply-To: <Pine.LNX.4.64.0612011134080.3695@woody.osdl.org>
On Friday 01 December 2006 21:13, Linus Torvalds wrote:
> > There seems to be some agreement to store the commit id of
> > the submodule instead of a plain tree id in the supermodules tree object, and
> > that all objects that are reachable from this commit are made part of the
> > supermodule repository (either fetched or via alternates). Do you agree?
>
> Well, I would actually argue that you may often want to have a supermodule
> and then at least have the _option_ to decide to not fetch all the
> submodules.
If you want to allow this, you have to be able to cut off fetching the
objects of the supermodule at borders to given submodules, the ones you
do not want to track. With "border" I mean the submodule commit in some
tree of the supermodule.
This looks a little bit like a shallow clone, where you introduce
graft points at the border to some of the submodule's object DAGs.
But I am not sure that this is scalable: for supermodules with
a large number of submodules you are not interested in,
your graft file would grow very fast, as there will be new borders
with every change in some submodule, which happens to be tracked
in the supermodule.
So IMHO, instead of a huge graft file, you want to have a fast way
to check at a submodule border which submodule this given border is
going into. Then, at fetch time, you easily can decide that you do
not want to fetch any object from the submodule.
Otherwise, you would have to ask the remote end at cloning time:
"Is this commit from some submodule I am locally not interested in?"
So I think we should introduce a submodule namespaces in supermodules.
And at every border from super- to submodules, the name of the
submodule we are going into should be specified.
Which actually means that we need to introduce a "submodule" object,
and trees of a supermodule can have such submodule objects as borders
into a submodule. In a submodule object, of course we have the
SHA1 of the commit into the submodule DAG, and there would be the global
unique name we have choosen for this submodule in this supermodule.
Something like
submodule: gcc
commit: 6287376...
Before cloning a supermodule, you should be able to list the names of
the submodules available, and select the submodules you want to have
cloned together with the supermodule.
> Ie, you very much should be able to to do
>
> git clone supermodule/that/one/submodule
> my-own-version-of-submodule
>
> to clone a submodule _without_ getting anything else (but still get all
> the work you did within he submodule - very much including your own
> private branch work).
So in the example, "that/one/submodule" is _not_ the path of the working
tree which happens to be the root of the submodule at current supermodule
HEAD, but the unique name from the submodule namespace.
This is important, as you should be able to move the root of a submodule
inside of your supermodule like moving any other file or directory.
I.e. for every supermodule commit, the path to the root directory of a
given submodule can change, making it useless as a name for a submodule
selection at clone time.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 22:08 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612012154.33834.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 09:54:32PM +0000, Andy Parkins wrote:
> On Friday 2006, December 01 21:37, Martin Waitz wrote:
>
> > > I'm going to guess by reachability analysis, you mean that the
> > > submodule doesn't know that some of it's commits are referenced by the
> > > supermodule. As I suggested elsewhere in the thread, that's easily
> > > fixed by making a refs/supermodule/commitXXXX file for each
> > > supermodule commit that references as particular submodule commit.
> >
> > I wouldn't call this "easily".
>
> Of course it is; when you write a supermodule commit you have it's hash,
> $SUPERMODULE_HASH, you have the commit-hash of the submodule commit you're
> referencing, $SUBMODULE_HASH. It's not really hard to do
>
> echo $SUBMODULE_HASH >
> submodule/.git/refs/supermodules/commit$SUPERMODULE_HASH
I guess you are aware that you have to scan _all_ trees inside _all_
supermodule commits for possible references.
So what do you do with deleted submodules?
You wouldn't want them to still sit around in your working directory,
but you still have to preserve them.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 22:12 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Linus Torvalds, sf, git
In-Reply-To: <200612012306.41410.Josef.Weidendorfer@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 757 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 11:06:40PM +0100, Josef Weidendorfer wrote:
> > Well, I would actually argue that you may often want to have a
> > supermodule and then at least have the _option_ to decide to not
> > fetch all the submodules.
>
> If you want to allow this, you have to be able to cut off fetching the
> objects of the supermodule at borders to given submodules, the ones you
> do not want to track. With "border" I mean the submodule commit in some
> tree of the supermodule.
I don't think this is something special to submodules. There has been
interest in checking out only a part of the tree even before talking
about submodules and I really think this feature should be independent
to submodules.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Handling of branches in stgit
From: Yann Dirson @ 2006-12-01 22:19 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <b0943d9e0612010442gf7bf2ccr8995967403788fe7@mail.gmail.com>
On Fri, Dec 01, 2006 at 12:42:19PM +0000, Catalin Marinas wrote:
> On 30/11/06, Yann Dirson <ydirson@altern.org> wrote:
> >I have started to work on recording parent information for stgit
> >branches, so we don't need to give the same info on every "git pull".
>
> Isn't this what the branch.<name>.remote configuration option is for?
> I think we should leave GIT handle this and StGIT only invoke "git
> pull" without any arguments.
This is one part of the problem (and I admit I have missed this config option),
the other one being having stgit pull the correct branch, unstead of
(implicitely) having git-pull using the 1st one in the remotes file.
> >I'm facing a problem, in that we have several kind of stgit branches:
> >
> >* those created against a cogito branch (eg. by "cg clone" and "stg
> > init"). They work pretty much intuitively (and it happens I mostly
> > used this flavour before those tests). All we need is the name of
> > the local branch, and "stg pull <branch>" relies on "git fetch" to
> > find the repository information in .git/branches/<branch>.
>
> But I think .git/branches got deprecated or it is a cogito-only feature.
.git/branches still seems to be the only type of branch created by
cogito. And in fact, when remotes started to appear, I wondered how the
cogito branch management (a quite intuitive and classical one) would be
made to work well with remotes-defining-several-branches, as well as
branches-potentially-defined-in-several-remotes (possible repo
inconsistency AFAICT, or maybe to specify different protocols to a
single repo ?) - and indeed I still don't have an answer, I guess cogito
would have to possibly change its user interface if it were to be able
to use multi-branch remotes.
In the meantime, we should support them in cogito. And indeed, I found
stgit to work perfectly with those.
> > In this case, it is easy to request pulling from any branch, but
> > usually only one of them is what you want, and the results of using
> > another one (or forgetting to specify the one you want) can be
> > annoying [ISSUE 1]. Hence this work of mine: being able to store
> > this info in .git/patches/<stack>/parent (my initial implementation)
> > was sufficient in theory.
>
> I would leave this to GIT and its configuration files. Do you see any
> problems with this approach?
I'd rather consider it a stgit issue: git itself does no have to know
which of the various heads descending from our stack base is to be
"prefered" by our stack. Where to store it is anothe issue (see below).
> I plan to merge the stgit config with the git one (and have a [stgit]
> section) so that it is more maintainable.
Sure, let's take advantage of git-repo-config !
My latest 1/3 patch could then be seen as a 1st step towards an
abstraction of stgit object configuration, which could ease the transition
from file storage to config items :)
Best regards,
--
Yann.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Josef Weidendorfer @ 2006-12-01 22:26 UTC (permalink / raw)
To: Martin Waitz; +Cc: Linus Torvalds, sf, git
In-Reply-To: <20061201221230.GM18810@admingilde.org>
On Friday 01 December 2006 23:12, Martin Waitz wrote:
> hoi :)
>
> On Fri, Dec 01, 2006 at 11:06:40PM +0100, Josef Weidendorfer wrote:
> > > Well, I would actually argue that you may often want to have a
> > > supermodule and then at least have the _option_ to decide to not
> > > fetch all the submodules.
> >
> > If you want to allow this, you have to be able to cut off fetching the
> > objects of the supermodule at borders to given submodules, the ones you
> > do not want to track. With "border" I mean the submodule commit in some
> > tree of the supermodule.
>
> I don't think this is something special to submodules. There has been
> interest in checking out only a part of the tree even before talking
> about submodules and I really think this feature should be independent
> to submodules.
It's not about checking out part of the tree, it's about fetching only
part of the objects: If you have a slow modem and want to clone a
supermodule, you are not interested in fetching all the objects from
some submodules.
So it is more like a shallow clone. But even here, submodules are special
as you have defined borders between supermodule and submodules. This gives
you the freedom the introduce a submodule namespace, and allows you to
point to a submodule: "I do not want you!".
With shallow clone, there you do not have this option, so there, you need
to use something like grafting.
BTW: In your submodule implementation, is the user allowed to change the
relative path of the root of some submodule, e.g. with "git-mv" ?
Josef
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Linus Torvalds @ 2006-12-01 22:26 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: sf, git, Martin Waitz
In-Reply-To: <200612012306.41410.Josef.Weidendorfer@gmx.de>
On Fri, 1 Dec 2006, Josef Weidendorfer wrote:
> >
> > Well, I would actually argue that you may often want to have a supermodule
> > and then at least have the _option_ to decide to not fetch all the
> > submodules.
>
> If you want to allow this, you have to be able to cut off fetching the
> objects of the supermodule at borders to given submodules, the ones you
> do not want to track. With "border" I mean the submodule commit in some
> tree of the supermodule.
>
> This looks a little bit like a shallow clone
No.
I would say that it looks more like a "partial checkout" than a shallow
clone.
A shallow clone limits the data in "time" - we have _some_ data, but we
don't have all of the history of that data.
In contrast, a submodule that we don't fetch is an all-or-nothing
situation: we simply don't have the data at all, and it's really a matter
of simply not recursing into that submodule at all - much more like not
checking out a particular part of the tree.
So if a shallow clone is a "limit in time", a lack of a module (or a lack
of a checkout for a subtree in general - you could certainly imagine doing
the same thing even _within_ a git repository, and indeed, we did discuss
exactly that at one point in time) is more of a "limit in space".
^ permalink raw reply
* Re: [PATCH] make 'git add' a first class user friendly interface to the index
From: Junio C Hamano @ 2006-12-01 22:31 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612011444310.9647@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> I personally think this is going to make the GIT experience lot more
> enjoyable for everybody. This brings the power of the index up front
> using a proper mental model without talking about the index at all. See
> for example how all the technical discussion has been evacuated from the
> git-add man page.
I like the direction this is taking us.
The documentation update is in the same spirit with the sample
rewrite of 'git diff' manpage. We might want to tweak the
wording to make this round of documentation updates consistent.
My preferences:
- You used the word "changeset"; I am not sure that is a good
wording. The recent explanation I saw on the list and liked
were "you _stage_ your changes to prepare for the next
commit (footnote: the staging area is called 'the index')".
My impression was that both extremes (Linus and Carl) are
also Ok with this wording.
- We keep the word "index", and not reword it to "stage" in the
names of commands and options. "to stage" is very good verb
to explain the _concept_, but there is no need to use
inconsistent wording Porcelain-ish and plumbing use to
describe the entity used for staging.
(1) New people need to learn the new concept anyway, and they
are intelligent enough to learn what that new concept has
been called for a long time in git-land at the same time.
"The index" is the receiver of new contents to be staged;
conversely, "to stage" is the act of registering contents
to the index.
(2) Majority of git old timers do not follow git mailing list
discussion closely. They already know the concept of
"registering thing in the index". We on the list are
just about to agree to give a good short name, "to
stage", for that action they have known about, in order
for us to make it easier to explain to new people. That
should not affect the terminology the old timers are
accustomed to and and trained their fingers with
("update-index", "diff --cached", "apply --index").
(3) I hope nobody proposes to rename "update-index" to
"update-stage" nor "diff-index" to "diff-stage"; that
would break countless number of existing third party
scripts old timers rely on and even new people would find
on the web and tempted to try out, so plumbing level
commands and options have to keep using the word 'index'.
The option to 'git diff --cached' may need a new synonym
to make things consistent, but the new synonym should be
--index, not --staged.
(4) New people will not stay newbies forever. Using a
consistent word for the entity used for staging for the
next commit across Porcelain and plumbing is important.
> maybe add a -f/--force argument to allow for adding ignored files
> instead of going through git-update-index.
Yup.
> maybe add --new-only and --known-only arguments if there is a real need
> to discriminate between new vs updated files. I would not suggest
> against it though, because if someone really has such fancy and uncommon
> requirements he might just use git-update-index directly at that point.
Borrow from "update-index --again", perhaps?
> +Contrary to other SCMs, with GIT you have to explicitly "add" all the
> +changed file content you want to commit together to form a changeset
> +with the 'add' command before using the 'commit' command.
... "before a new commit is made"; it is not an offence to leave
local changes outside the index. Staging such changes to all
files is done using the "-a" flag and that is done "before a new
commit is made", but not "before using the 'commit' command" --
it is done at the same time.
> +This is not only for adding new files. Even modified files must be
> +added to the set of changes about to be committed. This command can
> +be performed multiple times before a commit. The 'git status' command
> +will give you a summary of what is included for the next commit.
> +
> +Note: don't forget to 'add' a file again if you modified it after the
> +first 'add' and before 'commit'. Otherwise only the previous added
> +state of that file will be committed. This is because git tracks
> +content, so what you're really 'add'ing to the commit is the *content*
> +of the file in the state it is in when you 'add' it. Of course there are
> +legitimate usage cases for not updating an already added file content
> +in order to commit a previous file state, but in this case you better
> +know what you're doing.
May be we could hint the reader that a faster-to-type
alternative exists here. Perhaps...
Note: instead of doing 'git add' to stage the modified contents,
you can ask 'git commit' to take all the modified contents in
the working tree and stage them all before creating a commit
with 'git commit -a'.
> +GIt tracks content not files
s/I/i/
> +But here's a twist. If you do 'git commit <file1> <file2> ...' then only
> +the changes belonging to those explicitly specified files will be
> +committed, entirely bypassing the current "added" changes. Those "added"
> +changes will still remain available for a subsequent commit though.
> +
> +There is a twist about that twist: if you do 'git commit -i <file>...'
> +then the commit will consider changes to those specified files _including_
> +all "added" changes so far.
> +
I think there is another twist more deserving of mention than -i twist.
If you jump the index using --only, what is committed with that
commit becomes part of what is staged for the commit after that,
and in order to prevent data loss, we disallow this sequence:
$ git checkout
$ edit foo
$ git add foo ;# your new add to update the existing entry.
$ edit foo
$ git commit foo
If we did not have the second edit (the behaviour is the same if
we did not have "git add foo" there), this commit:
* commits the changes to 'foo' (not because you staged it
earlier with 'git add', but only because you said "commit
foo" to invoke the '--only' semantics), obviously;
* updates 'foo' in the index to what was committed.
So if we allowed the above sequence to succeed, we would commit
the result of the second edit, and after the commit, the index
would have the result of the second edit. We would lose the
state the user wanted to keep in the index while this commit
jumped the index, and that is why we disallow it.
> +But for instance it is best to only remember 'git add' + 'git commit'
> +and/or 'git commit -a'.
> +
> +No special command is required when removing a file; just remove it,
> +then tell `commit` about the file as usual.
I wonder if this sequence should do the same as "git rm -f foo":
$ /bin/rm foo
$ git add foo
That's one of the reasons I suggested 'checkin' instead of
'resolve', 'resolved', etc. You check-in the removal of the
content from that path to the staging area, to go as a part of
the next commit.
> diff --git a/builtin-add.c b/builtin-add.c
> index febb75e..b3f9206 100644
> --- a/builtin-add.c
> +++ b/builtin-add.c
> @@ -94,9 +94,6 @@ int cmd_add(int argc, const char **argv, const char *prefix)
>
> newfd = hold_lock_file_for_update(&lock_file, get_index_file(), 1);
>
> - if (read_cache() < 0)
> - die("index file corrupt");
> -
> for (i = 1; i < argc; i++) {
> const char *arg = argv[i];
>
> @@ -131,6 +128,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)
> return 0;
> }
>
> + if (read_cache() < 0)
> + die("index file corrupt");
> +
> for (i = 0; i < dir.nr; i++)
> add_file_to_index(dir.entries[i]->name, verbose);
>
Hmph. Fair enough.
> diff --git a/wt-status.c b/wt-status.c
> index de1be5b..4b8b570 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -163,7 +163,7 @@ static void wt_status_print_changed_cb(struct diff_queue_struct *q,
> int i;
> if (q->nr)
> wt_status_print_header("Changed but not updated",
> - "use git-update-index to mark for commit");
> + "use git-add on files to include for commit");
> for (i = 0; i < q->nr; i++)
> wt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);
> if (q->nr)
"use git-add to mark for commit, or use commit -a"?
I think the one source of confusion is "update-index" sounds as
if it is a command to "update the index" and as if you can leave
out "with what?" part to complete the order to the command.
We can use the word "add", thanks to your patch that enhances
the user level command, and I do not think the word "add" would
not induce that confusion. It is more obvious that you have to
say "what to add".
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: sf @ 2006-12-01 22:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Martin Waitz
In-Reply-To: <Pine.LNX.4.64.0612011134080.3695@woody.osdl.org>
Linus Torvalds wrote:
>
> On Fri, 1 Dec 2006, sf wrote:
>> Linus Torvalds wrote:
>> ...
>>> Think of it this way: one common use for submodules is really to just
>>> (occasionally) track somebody elses code. The submodule should be a
>>> totally pristine copy from somebody else (ie it might be the "intel driver
>>> for X.org" submodule, maintained within intel), and the supermodule just
>>> refers to it indirectly (ie the supermodule might be the "Fedora Core X
>>> group" which contains all the different drivers from different people).
>> Could you please be a little bit more specific about how you would store the
>> "pristine copy".
>
> Note that it's not necessarily "pristine", since the submodule clearly is
> a local git repository in its own right. So like _any_ git repository, you
> can (and may well end up) having your own local branches in the submodule,
> with your own local modifications.
>
> So I'm not claiming that a submodule must always match some external git
> tree 100%, and that it must be read-only or anything like that. I'm just
> saying that I suspect that quite often, one of the MOST IMPORTANT parts is
> that the submodule is really something that somebody else technically
> maintains, and that this is actually one of the _reasons_ why it is a
> submodule in the first place.
>
> For example, a lot of projects end up having some kind of "library
> component" as a submodule. Take something like a video player project,
> which would have something like ffmpeg as a submodule, not because you'd
> maintain ffmpeg yourself, but simply because (let's say) the library
> interface changes enough, or you need a specific version with some of your
> own fixes that haven't been released widely yet, so you want to carry all
> the libraries you need _with_ you, even though you don't really maintain
> that submodule. You at most have some small extensions of your own.
>
> Now, in this situation, it's relaly really _important_ that the submodule
> really is totally independent of the supermodule, for several reasons.
>
> For example, since you don't "really" own that project, carrying around
> your own fixes is really really painful. We know it happens all the time,
> and a lot of projects end up needing their own version, but the _last_
> thing you want is to be in merge hell all the time. So as a supermodule
> maintainer, the best possible thing for you is to be able to push back
> those local changes to the original project maintainer, so that you
> _don't_ have to maintain your own changes.
True. But if you need the changes to the submodule for your supermodule
to function, and upstream either does not want to merge your changes or
the merge will be available only after a long time, then what is the
alternative? You must be able to keep local changes, and you must be
able to keep pulling from upstream. Of course, what you describe is the
ideal case: You find a bug, push the fix upstream, and in no time at all
your fix is merged and you can just pull a new version into your
superproject, but that might be wishful thinking.
> But you need to realize that the real maintainer of the submodule is
> TOTALLY UNINTERESTED in your supermodule. He's not going to maintain it,
> and in fact, if you have anything in the submodule that ends up talking
> about your supermodule, that's just going to make it a lot less likely
> that the upstream maintainer will ever pull your changes. He might take a
> diff from you, but in a perfect world, you'd actually be able to tell him:
>
> "Hey, I've got a git repository with a few fixes to your ffmpeg git tree,
> please pull from git://myhost.com/submodule.git to get these fixes:
>
> ... explanation of fixes and commits that are relevant to
> ffmpeg, and have nothing to do with the supermodule, except
> that you need those bug-fixes because you _use_ ffmpeg ...
>
> Thanks"
>
> See?
No! All you need is a naming scheme to address the commit of the
subproject that should be pulled. The extreme case would be to just
address it with its id (well, currently you cannot do that with git
pull, but that is fixable). But I already proposed a syntax for naming
commits which are "hidden" in a superproject: Just name the path as
described in git-rev-parse and append double slashes (to indicate that
you mean the commit, not the tree it contains). So no manual work needs
be done by upstream.
[snipped: about independence of submodule branches]
>> There seems to be some agreement to store the commit id of
>> the submodule instead of a plain tree id in the supermodules tree object, and
>> that all objects that are reachable from this commit are made part of the
>> supermodule repository (either fetched or via alternates). Do you agree?
>
> Well, I would actually argue that you may often want to have a supermodule
> and then at least have the _option_ to decide to not fetch all the
> submodules.
[transmeta example snipped]
> So no, I don't think the supermodule should even _force_ people to always
> get all the submodules. It migth be the default case, but at the same
> time, it's just being polite to let users decide on their own whether they
> really want _all_ of the build infrastructure sources.
If you want to track some chosen submodules there are two easy solutions:
1. If you want to track their state as it appears from the supermodule's
view, pull from master:<submodule>//
2. If you want to track their state from their own development branches,
pull from <submodule>/master
Can you see the difference?
>> If I understand you correctly you cannot make any changes to the submodules
>> code _in the supermodule's repository_, no bugfixes, no extensions, no
>> adaptions, nothing. Do you mean that?
>
> Yes. I think you should make all changes _within_ the submodule, because
> the submodule should still be an independent git tree in its own right.
Every commit is a git tree in its own right, is it not?
[description of independent submodule development snipped]
> And the importance of keeping the submodule independent is partly just
> stability and sanity, but partly also scalability. For example, the
> "index" in a supermodule should NOT include the indexes of all the
> submodules. That's really important, because the index doesn't really
> scale. Things do slow down with large indexes.
>
> For example, git can handle tens of thousands of files easily. I suspect
> it scales well to hundreds of thousands of filenames. But with
> supermodules, you really can end up in the situation where you have _tens_
> of these submodules, maybe even hundreds. And if you try to maintain one
> unified index for the _whole_ thing, I guarantee you that you'll start
> feeling the pain. Indexing millions of files is just not going to be
> pretty.
I am not sure I understand what you say.
1. If you are working on a submodule, then the supermodule never enters
the picture. You are working independently. So far, so good.
2. If you are working on the supermodule, git will not be able to
function? How would you work without submodules, in which case you would
have simply one large project?
> So just from a git stability and scalability point, it's important to keep
> subprojects _separate_. There is obviously integration stuff, but they
> should still be seen as truly independent projects. Even the supermodule
> should have clearly its own life even _regardless_ of submodules, because
> (as I said) quite often you may want the supermodule, but you don't want
> to have _all_ of the submodules.
>
> But it's more than that stability and scalability thing too - keeping them
> separate is what allows you to do pulls and pushes on an individual
> subproject basis, and have people really work at that level. For example,
> if you're the compiler guy at a company, you really do want to work with
> other compiler people _outside_ the company, but you sure as hell may not
> be able to give them access to your supermodule. But you may want to work
> on _just_ the compiler parts (or at least share some branches in public),
> which means that the subproject really has to be able to work
> _independently_ of the supermodule.
I totally agree. When I try to explain why submodules work that only
exist as part of one or more supermodules, I do not mean to say that you
cannot or should not have independent branches or repositories for the
submodules' code.
> So "independent" here is really key, for several reasons. And that all
> means, for example, that here must NEVER be any "backpointers". A
> subproject really can _never_ have backpointers to the superproject,
> because that fundamentally means that the above kind of "compiler guy
> works on the compiler subproject in public" cannot work, if your
> supermodule isn't public.
I took that for granted: from a commit you only ever look backwards (in
time/history dimension) or downwards (in content dimension).
Regards
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 22:40 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Linus Torvalds, sf, git
In-Reply-To: <200612012326.22779.Josef.Weidendorfer@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 1218 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 11:26:22PM +0100, Josef Weidendorfer wrote:
> It's not about checking out part of the tree, it's about fetching only
> part of the objects: If you have a slow modem and want to clone a
> supermodule, you are not interested in fetching all the objects from
> some submodules.
So when you want to suppress one submodule, how is this not about only
checking out part of the tree?
Ok, you also want to avoid downloading the submodule, but you first have
to solve the partial checkout.
> BTW: In your submodule implementation, is the user allowed to change the
> relative path of the root of some submodule, e.g. with "git-mv" ?
In principle: yes.
However there are some links between both repositories that have to be
updated manually (for the shared object repository and for ignoring
submodule files in the supermodule).
But I expect that much of this configuration stuff will vanish when
submodules are better integrated in git.
Rename detection for submodules would be another interesting thing to
have. It should be much easier as for files because we can simply check
for common ancestors and do not have to guess based on the diff.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: sf @ 2006-12-01 22:41 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sf, git, Martin Waitz
In-Reply-To: <Pine.LNX.4.64.0612011423100.3695@woody.osdl.org>
Linus Torvalds wrote:
...
> In contrast, a submodule that we don't fetch is an all-or-nothing
> situation: we simply don't have the data at all, and it's really a matter
> of simply not recursing into that submodule at all - much more like not
> checking out a particular part of the tree.
If you do not want to fetch all of the supermodule then do not fetch the
supermodule. Instead fetch only the submodules you are interested in.
You do not have to fetch the whole repository.
Regards
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Josef Weidendorfer @ 2006-12-01 22:55 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sf, git, Martin Waitz
In-Reply-To: <Pine.LNX.4.64.0612011423100.3695@woody.osdl.org>
On Friday 01 December 2006 23:26, Linus Torvalds wrote:
>
> On Fri, 1 Dec 2006, Josef Weidendorfer wrote:
> > >
> > > Well, I would actually argue that you may often want to have a supermodule
> > > and then at least have the _option_ to decide to not fetch all the
> > > submodules.
> >
> > If you want to allow this, you have to be able to cut off fetching the
> > objects of the supermodule at borders to given submodules, the ones you
> > do not want to track. With "border" I mean the submodule commit in some
> > tree of the supermodule.
> >
> > This looks a little bit like a shallow clone
>
> No.
>
> I would say that it looks more like a "partial checkout" than a shallow
> clone.
>
> A shallow clone limits the data in "time" - we have _some_ data, but we
> don't have all of the history of that data.
>
> In contrast, a submodule that we don't fetch is an all-or-nothing
> situation: we simply don't have the data at all, and it's really a matter
> of simply not recursing into that submodule at all - much more like not
> checking out a particular part of the tree.
OK.
I still think it should be about "limit in space" regarding the
objects in the local repository.
For a project containing "gcc" as submodule, and I am not
interested in this submodule, there should be a way to not need
to fetch all the objects from the gcc submodule at clone time.
What about my other argument for a submodule namespace:
You want to be able to move the relative root path of a submodule
inside of your supermodule, but yet want to have a unique name
for the submodule:
- to be able to just clone a submodule without having to know
the current position in HEAD
- more practically, e.g. to be able to name a submodule
independent from any current commit you are on in the supermodule,
e.g. to be able to store some meta information about a submodule:
- "Where is the official upstream of this submodule?"
- "Should git allow to commit rewind actions of this submodule
in the supermodule?" (which, AFAICS, exactly has the same
problems as publishing a rewound branch: you will get into
merge hell when you want to pull upstream changes into the
supermodule)
- "Should this submodule be checked out?"
and so on.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Josef Weidendorfer @ 2006-12-01 23:03 UTC (permalink / raw)
To: sf-gmane; +Cc: Linus Torvalds, sf, git, Martin Waitz
In-Reply-To: <4570AF8F.1000801@stephan-feder.de>
On Friday 01 December 2006 23:41, sf wrote:
> Linus Torvalds wrote:
> ...
> > In contrast, a submodule that we don't fetch is an all-or-nothing
> > situation: we simply don't have the data at all, and it's really a matter
> > of simply not recursing into that submodule at all - much more like not
> > checking out a particular part of the tree.
>
> If you do not want to fetch all of the supermodule then do not fetch the
> supermodule. Instead fetch only the submodules you are interested in.
> You do not have to fetch the whole repository.
But what, when I *want* to fetch the supermodule because of the source
tree which is only available in the supermodule?
Of course, you can argue that the only objects in trees of a supermodule
should be submodule commits, but this is quite restricting the usage of
supermodules.
See further arguments for a submodule namespace in my other mail.
You probably want to specify policies about submodule handling. This
information has to be indexed by some name independent from a
supermodule commit.
Josef
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 23:07 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: Linus Torvalds, sf, git
In-Reply-To: <200612012355.03493.Josef.Weidendorfer@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 817 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 11:55:03PM +0100, Josef Weidendorfer wrote:
> What about my other argument for a submodule namespace:
> You want to be able to move the relative root path of a submodule
> inside of your supermodule, but yet want to have a unique name
> for the submodule:
> - to be able to just clone a submodule without having to know
> the current position in HEAD
> - more practically, e.g. to be able to name a submodule
> independent from any current commit you are on in the supermodule,
> e.g. to be able to store some meta information about a submodule:
> - "Where is the official upstream of this submodule?"
you can always have a bare repository for all used modules lying around
in some defined location. There is no need for a unique submodule-name.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Linus Torvalds @ 2006-12-01 23:09 UTC (permalink / raw)
To: sf; +Cc: sf, git, Martin Waitz
In-Reply-To: <4570AF8F.1000801@stephan-feder.de>
On Fri, 1 Dec 2006, sf wrote:
> Linus Torvalds wrote:
> ...
> > In contrast, a submodule that we don't fetch is an all-or-nothing
> > situation: we simply don't have the data at all, and it's really a matter
> > of simply not recursing into that submodule at all - much more like not
> > checking out a particular part of the tree.
>
> If you do not want to fetch all of the supermodule then do not fetch the
> supermodule.
So why do you want to limit it? There's absolutely no cost to saying "I
want to see all the common shared infrastructure, but I'm actually only
interested in this one submodule that I work with".
Also, anybody who works on just the build infrastructure simply may not
care about all the submodules. The submodules may add up to hundreds of
gigs of stuff. Not everybody wants them. But you may still want to get the
common build infrastructure.
In other words, your "all or nothing" approach is
(a) not friendly
and
(b) has no real advantages anyway, since modules have to be independent
enough that you _can_ split them off for other reasons anyway.
So forcing that "you have to take everything" mentality onyl has
negatives, and no positives. Why do it?
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Josef Weidendorfer @ 2006-12-01 23:17 UTC (permalink / raw)
To: Martin Waitz; +Cc: Linus Torvalds, sf, git
In-Reply-To: <20061201221230.GM18810@admingilde.org>
On Friday 01 December 2006 23:12, Martin Waitz wrote:
> hoi :)
>
> On Fri, Dec 01, 2006 at 11:06:40PM +0100, Josef Weidendorfer wrote:
> > > Well, I would actually argue that you may often want to have a
> > > supermodule and then at least have the _option_ to decide to not
> > > fetch all the submodules.
> >
> > If you want to allow this, you have to be able to cut off fetching the
> > objects of the supermodule at borders to given submodules, the ones you
> > do not want to track. With "border" I mean the submodule commit in some
> > tree of the supermodule.
>
> I don't think this is something special to submodules. There has been
> interest in checking out only a part of the tree even before talking
> about submodules and I really think this feature should be independent
> to submodules.
After some thinking, a submodule namespace even is important for checking
out only parts of a supermodule, exactly because the root of a submodule
potentially can change at every commit.
When checking out some arbitrary supermodule commit, how do you check that
at some submodule border, the user did not want to check out the submodule
at all? You need a way to check the DAG identity you are diving
into at this border: lets say by going to the root commit of this DAG (!).
And via this identity, you have to check whether the user had
specified that he wants the submodule to be check out.
Without any further meta information (indexed by a submodule name!), this
information is only available from the checkout the user switched from,
as there would be no file in the working tree from this submodule?
Quite a pain.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Alan Chandler @ 2006-12-01 23:23 UTC (permalink / raw)
To: git
In-Reply-To: <20061201203002.GJ18810@admingilde.org>
On Friday 01 December 2006 20:30, Martin Waitz wrote:
> hoi :)
>
> Linus, you are a lot better in describing all my thoughts than I myself.
> ;-)
Yes
Some of the clearest explanations described from a strategic point of view
come from posts such as these.
And he keeps saying he can't write documentation.
--
Alan Chandler
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Linus Torvalds @ 2006-12-01 23:30 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: sf, git, Martin Waitz
In-Reply-To: <200612012355.03493.Josef.Weidendorfer@gmx.de>
On Fri, 1 Dec 2006, Josef Weidendorfer wrote:
>
> What about my other argument for a submodule namespace:
> You want to be able to move the relative root path of a submodule
> inside of your supermodule, but yet want to have a unique name
> for the submodule:
> - to be able to just clone a submodule without having to know
> the current position in HEAD
Umm? I don't get the issue. A submodule is a git repo in its own right,
and you clone it exactly like you'd clone any other repo. It _does_ have a
HEAD. It has it's own branches. It has everything.
So when you clone a submodule, you always get all those branches. The
supermodule will not _point_ to them all (the branches are local to the
submodule, and _will_ depend on things like "which upstreams module am I
tracking"), but they'll have to be there, exactly _because_ the submodule
has an existence and is tracked on its own.
In the trivial case where the submodule doesn't even _have_ any external
existence at all (ie it's always maintained as _just_ a submodule, it
would probably tend to have just one branch, and a clone would get
whatever that branch is), but that's just a degenerate special case of the
much richer "this submodule actually has a life of its own" case.
> - more practically, e.g. to be able to name a submodule
> independent from any current commit you are on in the supermodule,
> e.g. to be able to store some meta information about a submodule:
The current commit within the supermodule would be _totally_ invisible to
the submodule.
Of course, if HEAD _differs_ from that commit within the supermodule, then
a "git diff" (when done from within the supermodule) should show that, but
again, that's actually only as seen from the _supermodule_.
> - "Where is the official upstream of this submodule?"
That's entirely a question for the submodule. You cannot ask that question
within the confines of the supermodule, because it's not even a relevant
question in that context. Two different supermodule repositories may well
decide to get their submodules from difference places, just because they
got cloned from different places (or even just for practical reasons like
"that other site is closer to me").
So the official upstream of a submodule must NOT be encoded inside the
supermodule (or at least not within its _objects_). Exactly because the
upstream location is not a "global" thing - it's per-repository, and thus
must not be encoded in the global data (ie the objects).
It should be be encoded in some _ephemeral_ place, eg in the ".git/config"
file or in a ".git/remotes/origin"-like file (either in the supermodule or
the submodule, and I would seriously suggest you do it within in the
submodule itself, because you'll want it exactly when you decide to work
on the submodule and upgrade _that_).
> - "Should git allow to commit rewind actions of this submodule
> in the supermodule?" (which, AFAICS, exactly has the same
> problems as publishing a rewound branch: you will get into
> merge hell when you want to pull upstream changes into the
> supermodule)
The only thing that a submodule must NOT be allowed to do on its own is
pruning (and it's distant cousin "git repack -d"). You must always prune
from the supermodule, because the submodule cannot really know on its own
what references point into it.
(There are alternatives. One alternative is to never allow rewinding - or
deletion - of branches in a submodule, and thus solve the problem that
way. That is the easier solution, because it also means that a "clone" of
a supermodule can just recursively clone the submodules independently
_without_ having to worry about reachability, but it's really _really_
draconian).
> - "Should this submodule be checked out?"
This, I think, requires too much configuration to say separately for every
possible submodule, so I would suggest that the way to make that decision
is:
- "git clone" by default will fetch and check out all submodules (and
obviously they have to be described some way outside of the object
database, just so that you don't have to parse the _whole_ history of
the _whole_ supermodule just to find all possible submodules. So the
supermodule _will_ need some "list of submodules and where to get them"
in a config file or other).
- add a flag (possibly just re-use the current "-n" flag) that disables
that recursive fetching of submodules entirely.
- have a way to fetch individual submodules one-by-one (that capacity
obviously has to be there anyway, since the "recursive" git clone has
to be able to do it, so this is likely just "git clone" again, with
just logic added to say "when you clone something and are _already_
within a superproject, the clonee becomes a subproject automatically"
I dunno. And I'd also like to point out that things don't have to all work
fully before we can do at least some cases of this. For example, if the
initial version just always clones everything, big deal. I'm not saying
that we have to have support for things like this on "Day 1", I'm just
saying that I think people will want to be able to not fetch and check out
everything, so the design should _allow_ for it.
(But I also think that as long as submodules are independent enough, the
"design" part should fall out on its own, and it just becomes a "small
matter of programming" to actually get it to work).
^ permalink raw reply
* Re: [PATCH 0/2] Making "git commit" to mean "git commit -a".
From: Alan Chandler @ 2006-12-01 23:33 UTC (permalink / raw)
To: git
In-Reply-To: <200612010834.22916.andyparkins@gmail.com>
On Friday 01 December 2006 08:34, Andy Parkins wrote:
> How about this:
...
>
> Hence,
>
> git-add becomes git-prepare and does
Why can't it stay as git-add
It means "add the current state of the content to the index"
It has the useful property that git-commit -a can be seen as a short cut for
add all the files in the working try and commit.
--
Alan Chandler
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: sf @ 2006-12-01 23:34 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20061201184801.GG18810@admingilde.org>
Martin Waitz wrote:
> On Fri, Dec 01, 2006 at 06:33:12PM +0100, Stephan Feder wrote:
>> We are in agreement about two fundamental parts of the implementation
>> and their meaning:
>>
>> 1. A submodule is stored as a commit id in a tree object.
>>
>> 2. Every object that is reachable from the submodule's commit are
>> reachable from the supermodule's repository.
>
> Correct.
Good. For me that is the main point. As I said before the user interface
is not so important because it can be changed anytime, but to change the
object database later is close to impossible.
...
> Let's see if I understand you correctly:
>
> You don't want to create an additional .git directory for the submodule
> and just handle everything with one toplevel .git repository for the
> whole project.
Yes.
> Without the .git directory, you of course do not have refs/heads inside
> the submodule.
Correct..
> So this is a different user-interface approach to submodules when
> compared to my approach. But the basis is the same and both could
> inter-operate.
Big YES.
> Now your submodule is no longer seen as an independent git repository
> and I think this would cause problems when you want to push/pull between
> the submodule and its upstream repository.
You can always pick a single commit or several commits out of a larger
repository and have a complete git repository.
And I already explained how to push and pull even from within superprojects.
> No technical problems, but UI-problems because now your submodule is
> handled completly different to a "normal" repository.
Yes and no. You can always have branches that are only concerned with
submodules' code, say, in refs/heads/submodules/<submodule>/.
"submodules" here is simply an example and has not deeper meaning. You
could call it foo or whatever you like. Or you could use
refs/heads/<submodule>/ if it suits you.
But if you mean the submodule as seen from the supermodule, then there
is a difference. Naturally, because the concept of submodules is new to git.
>>> Yes, but if it would have been integrated as a submodule it obviously
>>> would have been committed to the xdiff submodule inside the git
>>> repository.
>> No. The xdiff submodule would only exist as part of the git repository.
>
> But you could still call the "xdiff" part of the git repository a
> submodule. And then changes to the xdiff directory result in a new
> submodule commit, even when there is no direct reference to it.
> So you'd still "commit to the xdiff submodule".
Let's make certain that we understand each other. I see a clear
distinction between the submodule code in a supermodule branch (commits
in the supermodule's tree and nothing else) and submodule branches which
are independent of the superproject. Supermodule branches and submodule
branches do not interact, only if I want them to.
>
>> You could, f.e., access the xdiff commit in git HEAD as HEAD:xdiff//
>> (again my proposed syntax). HEAD:xdiff//~2:xemit.c would give you the
>> grandparent of xemit.c in the xdiff submodule.
>
> git-cat-file commit HEAD:xdiff already works out of the box (even
> cat-file tree to get the submodule tree). But up to now revision
> parsing follows the file name only once.
>
> What about just separating things with "/"?
>
> commit HEAD
> tree HEAD/
> blob HEAD/Makefile
> commit HEAD/xdiff
> tree HEAD/xdiff/
> blob HEAD/xdiff~2/xemit.c
>
> this may add some confusion when used with hierarchical branches, but
> it's still unique:
>
> refs/heads/master/xdiff/xemit.c
>
> Just use as many path components until a matching reference is found,
> then start peeling.
> Or just use / between super and submodule:
>
> refs/heads/master:xdiff/xemit.c
>
> I think this is easier to read then
>
> refs/heads/master:xdiff//:xemit.c
The double slashes is the only way I can think of that clearly indicates
that I do not mean the contents named by the path, but the commit that
you find there. Once you have named a commit in that way, you can
continue to apply other revision naming suffixes, paths, and so on.
Let's try. What does git cat-file -p
master:dir/sub//^^^:sub/dir/sub//^:dir/file mean?
Explanation: Take branch master and go to path dir/sub. There you will
find a commit. Take its grand-grandparent and go to path sub/dir/sub
(the first sub is a subproject as well but we do not care). There you
will, again, find a commit. Take its parent and go to path dir/file
which happens to be a blob the contents of which you want to cat.
In reality you will never see these kinds of complex paths. Have you
ever seen something like git cat-file -p
bd2c39f58f915af532b488c5bda753314f0db603~12^{commit}^2^5~8^2~308:README ?
>> If you mean the submodule repository created by init-module I
>> understand. But why create this "helper repository at all"?
>
> Because it helps "normal" git operations ;-)
Let's see. I still have to try.
Regards
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Josef Weidendorfer @ 2006-12-01 23:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: sf, git, Martin Waitz
In-Reply-To: <Pine.LNX.4.64.0612011505190.3695@woody.osdl.org>
On Saturday 02 December 2006 00:09, Linus Torvalds wrote:
>
> On Fri, 1 Dec 2006, sf wrote:
> > Linus Torvalds wrote:
> > ...
> > > In contrast, a submodule that we don't fetch is an all-or-nothing
> > > situation: we simply don't have the data at all, and it's really a matter
> > > of simply not recursing into that submodule at all - much more like not
> > > checking out a particular part of the tree.
> >
> > If you do not want to fetch all of the supermodule then do not fetch the
> > supermodule.
>
> So why do you want to limit it? There's absolutely no cost to saying "I
> want to see all the common shared infrastructure, but I'm actually only
> interested in this one submodule that I work with".
So you are for a global submodule namespace in supermodule repositories,
do I understand correctly?
Otherwise, how would you specify the submodules at clone time given the
ability that submodule roots can have relative path changed arbitrarily
between commits?
^ 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