* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-01 11:02 UTC (permalink / raw)
To: git
In-Reply-To: <20061201104256.GQ12463MdfPADPa@greensroom.kotnet.org>
On Friday 2006 December 01 10:42, Sven Verdoolaege wrote:
> He showed it to you in the example. The "submodule object" is the COMMIT
> of the submodule itself.
That's no different from mine. I need more detail than that.
Is that commit in the submodule or the supermodule? If it's in the submodule
then we're talking about the same thing, as that's all I want. If it's in
the supermodule then I want to know what the tree object that that commit
points to contains. I also want to know how we tell the difference between a
commit-in-supermodule and a
commit-in-supermodule-which-is-actually-in-submodule.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* [PATCH] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Andy Parkins @ 2006-12-01 11:06 UTC (permalink / raw)
To: git
Raimund Bauer offered this suggestion (paraphrased):
"Maybe we could do git-commit -a _only_ if the index matches HEAD, and
otherwise keep current behavior? So people who don't care about the
index won't get tripped up, and when you do have a dirty index, you get
told about it?"
Johannes Schindelin pointed out that this isn't the right thing to do for
an --amend, so that is checked for. Additionally, it's probably not the
right thing to do if any files are specified with "--only" or
"--include", so they turn this behaviour off as well.
Nguyen Thai Ngoc Duy asked that git-commit let you know it's done this
by adding an extra comment to the commit message.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
This time we also inhibit if "all" mode is already set; if the user
has specified "-a" we don't need to tell them that we've switched "-a"
mode on.
git-commit.sh | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 81c3a0c..4552727 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -265,6 +265,16 @@ $1"
done
case "$edit_flag" in t) no_edit= ;; esac
+# Clever commit - if this commit would do nothing, then make it an "all"
+# commit
+if [ -z "$(git-diff-index --cached --name-only HEAD)" \
+ -a -z "$amend" -a -z "$only" -a -z "$also" -a -z "$all" ]; then
+ echo "# There was nothing to commit but changes were detected in the" > $GIT_DIR/SQUASH_MSG
+ echo "# working tree. 'git commit -a' mode activated." >> $GIT_DIR/SQUASH_MSG
+ echo "#" >> $GIT_DIR/SQUASH_MSG
+ all=t
+fi
+
################################################################
# Sanity check options
--
1.4.4.1.g3ece-dirty
^ permalink raw reply related
* Re: [RFC] Submodules in GIT
From: Sven Verdoolaege @ 2006-12-01 11:10 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612011102.17079.andyparkins@gmail.com>
On Fri, Dec 01, 2006 at 11:02:15AM +0000, Andy Parkins wrote:
> On Friday 2006 December 01 10:42, Sven Verdoolaege wrote:
>
> > He showed it to you in the example. The "submodule object" is the COMMIT
> > of the submodule itself.
>
> That's no different from mine. I need more detail than that.
You were proposing to create an extra object containing some random value
that is disconnected from the repo.
> Is that commit in the submodule or the supermodule?
It's in BOTH. That's why it's a *sub*module.
Someone else can try to expain it you.
^ permalink raw reply
* Re: [PATCH] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Junio C Hamano @ 2006-12-01 11:15 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612011106.42272.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> Raimund Bauer offered this suggestion (paraphrased):
>
> "Maybe we could do git-commit -a _only_ if the index matches HEAD, and
> otherwise keep current behavior? So people who don't care about the
> index won't get tripped up, and when you do have a dirty index, you get
> told about it?"
>
> Johannes Schindelin pointed out that this isn't the right thing to do for
> an --amend, so that is checked for. Additionally, it's probably not the
> right thing to do if any files are specified with "--only" or
> "--include", so they turn this behaviour off as well.
>
> Nguyen Thai Ngoc Duy asked that git-commit let you know it's done this
> by adding an extra comment to the commit message.
I think another exception should be needed. If the index does
not match the working tree, it should not default to "-a".
Otherwise,
I want to fix another thing in pickaxe.
$ edit builtin-blame.c
My wife calls me. Away from desk for 20 minutes. Later I come
back.
$ git update-index builtin-pickaxe.c
I am so used to that name and did not realize that typo, and I
was not paying too much attention. My wife calls me again.
Away from desk and back in 20 minutes.
$ git commit -m 'git-blame: Another fix.'
Oops.
So, please turn this "cleverness" off when the index does not
match the working tree.
^ permalink raw reply
* selective git-update-index per diff(1) chunks
From: Alexey Dobriyan @ 2006-12-01 11:23 UTC (permalink / raw)
To: git
Pretty often I end up with a file with two simple orthogonal fixes in it.
git-diff shows me both, that's OK.
Now I want to commit them as two separate commits. So far, it's
* getting full diff
* cp(1)
* hand-edit both diffs
* commit first
* commit second
Has anyone thought about aggregating this into git-update-index or
somewhere?
git-update-index -C1,3 #chunks 1, 3
git commit
git-update-index -C1,3 # chunks 2,5 in original numbering
git commit
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 11:31 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612011029.28059.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3963 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 10:29:26AM +0000, Andy Parkins wrote:
> On Friday 2006 December 01 09:57, Martin Waitz wrote:
>
> > So why do you need the url hint committed to the supermodule?
> > We don't store remote information in the object database, too.
>
> That's why it was a hint, probably configured when you first create the
> submodule connection.
>
> In truth, the clone will be perfectly able to get the submodule
> objects from the upstream supermodule, maintaining the distributed
> nature easily.
that's exactly the reason why the hint is not needed.
Althogh you need to have one common project object database, storing the
objects of all modules.
> > > I say:
> > > submodulecommithash points at a commit /in the submodule/
> >
> > But unluckily, this does not work.
>
> Eh? "Not work", we're talking about code that doesn't even exist, of
> course it doesn't "work". Do you mean "doesn't work if we're using
> my implementation of submodules"? Well that hardly seems like a fair
> attack.
Well, at first I started exactly as you described: only store the
submodule commit sha1 in the parent somewhere, but don't traverse it.
So this is a fair attack: your implementation already exists in
http://git.admingilde.org/tali/git.git/module ;-)
(ok, yes, it really is different to what you described as I stored the
sha1 differently, but I really learned that it is important to be able
to traverse the entire commit chain, from the root of the project to the
deepest submodule.)
> > You really have to be able to traverse the entire commit chain
> > from the supermodule into all submodules.
>
> You can: when you hit a submodule tree object you set GIT_DIR to that
> submodule and continue. If you don't do it like that then you have
> stored submodule trees in the supermodule and it's no longer a
> separate repository.
Well, a submodule repository _is_ special in some ways:
fsck and prune have to take the references from the supermodule into
account. In this sense it is _not_ separate from the supermodule.
I think that is important for the submodule repository to be independent
in other ways than its object database: you should be able to exchange
commits with other repositories (be they stand-alone or a submodule in
another supermodule). You should be able to use log/diff/blame/whatever
inside the submodule.
All this does not need an object database of its own.
So I chose to do it the easy way and use one object database for the
entire project - and disallow git-prune in a submodule.
There may be other/better ways to do this, but you have to be able
to access all objects which belong the project inside the toplevel
project repository.
> Why you'd want to - I have no idea. What
> purpose would you have for traversing the commit chain into the
> submodules? The commit in the submodule is just a note of where that
> submodule was during the supermodule commit in question.
Things get much simpler if you have one big graph of objects.
clone and especially fetch/pull naturally work at once.
You can ask for all objects inside the whole project which are needed to
be transferred between project version A and B, including all submodules.
You can even have one bare repository for the whole project.
> I notice though that you avoided my question: what does YOUR submodule
> object contain? I really do want to know, as there is obviously a
> fundamental difference in what I think a submodule does and what you
> (and maybe everybody else) thinks a submodule does.
It really only stores the commit of the submodule directly.
So there is no new submodule object type. The parent has a direct link
to the submodule commit in his tree object and in its index. In order
to separate them from normal files or normal subdirectories, they get a
special mode: they are represented as socket.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Junio C Hamano @ 2006-12-01 11:32 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <7vd573amuy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I think another exception should be needed. If the index does
> not match the working tree, it should not default to "-a".
>
> Otherwise,
I think there needs a bit of explanation and additional step
that happened here. This by the way is not a made-up example.
Everything, including the 20-minute away, were what happened
when I did the latest blame fix you saw a few days ago.
* I am still futzing with blame from time to time, and have
this change almost permanently in my working tree.
$ cat P.diff
diff --git a/builtin-blame.c b/builtin-blame.c
index dc3ffea..46ce45c 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -38,7 +38,7 @@ static int max_digits;
static int max_score_digits;
#ifndef DEBUG
-#define DEBUG 0
+#define DEBUG 1
#endif
* I also have the GIT-VERSION-GEN change in my working tree.
> I want to fix another thing in pickaxe.
>
> $ edit builtin-blame.c
>
* Of course I did tests here.
> My wife calls me. Away from desk for 20 minutes. Later I come
> back.
* And then reverted the DEBUG back to 0 in preparation for
"checking into the index"
$ edit builtin-blame.c
> $ git update-index builtin-pickaxe.c
* And then I reverted it back for later futing.
$ git apply P.diff ;# that is a permanent-temporary file.
>
> I am so used to that name and did not realize that typo, and I
> was not paying too much attention. My wife calls me again.
> Away from desk and back in 20 minutes.
>
> $ git commit -m 'git-blame: Another fix.'
>
> Oops.
* Oops here is not just that builtin-blame.c would have been
committed; I'd almost never do "commit -a" in this repository,
because it would take that "DEBUG 1" change _and_
GIT-VERSION-GEN change into the commit.
> So, please turn this "cleverness" off when the index does not
> match the working tree.
^ permalink raw reply
* Re: selective git-update-index per diff(1) chunks
From: Peter Baumann @ 2006-12-01 11:33 UTC (permalink / raw)
To: git
In-Reply-To: <b6fcc0a0612010323x7554e47m5e6bdafe85fc8224@mail.gmail.com>
On 2006-12-01, Alexey Dobriyan <adobriyan@gmail.com> wrote:
> Pretty often I end up with a file with two simple orthogonal fixes in it.
> git-diff shows me both, that's OK.
>
> Now I want to commit them as two separate commits. So far, it's
> * getting full diff
> * cp(1)
> * hand-edit both diffs
> * commit first
> * commit second
>
> Has anyone thought about aggregating this into git-update-index or
> somewhere?
>
> git-update-index -C1,3 #chunks 1, 3
> git commit
> git-update-index -C1,3 # chunks 2,5 in original numbering
> git commit
>
> Relying on diff(1) definition of chunks is sorta hacky, though... I admit it.
I don't think it belongs in the plumbing, the git-update-index but I
think something like this would be very usefull.
AFAIR darcs has this functionality. It selectively ask for each hunk if
it should be commited. This would be awfull to have in git.
-Peter
^ permalink raw reply
* Re: selective git-update-index per diff(1) chunks
From: Junio C Hamano @ 2006-12-01 11:38 UTC (permalink / raw)
To: Peter Baumann; +Cc: git, Alexey Dobriyan
In-Reply-To: <slrnen04os.a5.Peter.B.Baumann@xp.machine.xx>
Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de>
writes:
> I don't think it belongs in the plumbing, the git-update-index but I
> think something like this would be very usefull.
>
> AFAIR darcs has this functionality. It selectively ask for each hunk if
> it should be commited. This would be awfull to have in git.
I concur, on both counts. My own now-defunct Porcelain had the
darcs style interactive hunk selection because it felt so
useful (and sometimes it was).
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 11:46 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612011102.17079.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 851 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 11:02:15AM +0000, Andy Parkins wrote:
> On Friday 2006 December 01 10:42, Sven Verdoolaege wrote:
>
> > He showed it to you in the example. The "submodule object" is the COMMIT
> > of the submodule itself.
>
> That's no different from mine.
Well, there simply is no proxy object inbetween.
> Is that commit in the submodule or the supermodule?
Well, logically that commit belongs to the submodule and is referenced
by the tree in the supermodule.
Phyisically it is stored in the projects object database which is
shared between the supermodule and all submodules (at least in my
implementation).
> I also want to know how we tell the difference between a
> commit-in-supermodule and a
> commit-in-supermodule-which-is-actually-in-submodule.
There is no difference.
--
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 11:45 UTC (permalink / raw)
To: git
In-Reply-To: <20061201111027.GR12463MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege wrote:
> On Fri, Dec 01, 2006 at 11:02:15AM +0000, Andy Parkins wrote:
>> On Friday 2006 December 01 10:42, Sven Verdoolaege wrote:
>>
>> > He showed it to you in the example. The "submodule object" is the COMMIT
>> > of the submodule itself.
>>
>> That's no different from mine. I need more detail than that.
>
> You were proposing to create an extra object containing some random value
> that is disconnected from the repo.
>
>> Is that commit in the submodule or the supermodule?
>
> It's in BOTH. That's why it's a *sub*module.
I would say it is only in the supermodule because that is the branch you
are working on. If you are working on the submodule in an independent
branch then you can pull from the submodule commit. But you do not want
to pull the supermodule commit itself but only the commit in path libxcb
(see my proposed syntax).
Regards
Stephan
^ permalink raw reply
* Re: [PATCH] (experimental) per-topic shortlog.
From: Jeff King @ 2006-12-01 11:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlklranrt.fsf@assigned-by-dhcp.cox.net>
On Fri, Dec 01, 2006 at 02:55:34AM -0800, Junio C Hamano wrote:
> [PATCH] git-blame: mark lines blamed on boundary commits.
Excellent. This is exactly what I had in mind, and it seems to produce
sensible results out of the box:
git-diff --raw -r --diff-filter=AM $1 | cut -f2 |
while read f; do
git-blame -l $1 -- $f | grep -v ^- | cut -d' ' -f1
done |
sort | uniq -c | sort -rn |
while read count hash; do
echo "$count `git-rev-list --max-count=1 --pretty=oneline $hash`"
done
Thanks!
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: sf @ 2006-12-01 12:03 UTC (permalink / raw)
To: git
In-Reply-To: <456F29A2.1050205@op5.se>
Andreas Ericsson wrote:
...
> The only problem I'm seeing atm is that the supermodule somehow has to
> mark whatever commits it's using from the submodule inside the submodule
> repo so that they effectively become un-prunable, otherwise the
> supermodule may some day find itself with a history that it can't restore.
That has nothing to do with submodules. What you state here is the
problem of alternate repositories.
There are two solutions:
1. Do not use alternates.
2. Do not prune a repository that is used as an alternate repository by
other repositories.
For the submodule discussion that would mean:
1. Only fetch and work on branches of submodules you are interested in.
It does not matter that the origin repository contains (probably orders
of magnitude) more data. You will never touch that.
2. You can never prune the main (the supermodule's) repository, at least
not with what git provides today.
That is why the sanest approach to subprojects is to put commits into
tree objects, define a way to name these commits and make git understand
these new commit names. Done. Works.
Regards
Stephan
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: sf @ 2006-12-01 12:09 UTC (permalink / raw)
To: git
In-Reply-To: <20061201110032.GL18810@admingilde.org>
Martin Waitz wrote:
...
> So you not only store your submodule HEAD commit in the supermodule when you
> do commit to the supermodule, it also means that your submodule HEAD
> will be updated when you update your supermodule.
Why the magic? The typical workflow in git is
1. You work on a branch, i.e. edit and commit and so on.
2. At some point, you decide to share the work you did on that branch
(e-mail a patch, merge into another branch, push upstream or let it by
pulled by upstream)
I fail to understand why these two steps have to be mixed up. Someone
care to explain?
Regards
Stephan
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 12:11 UTC (permalink / raw)
To: sf; +Cc: git
In-Reply-To: <45701A24.5060500@b-i-t.de>
[-- Attachment #1: Type: text/plain, Size: 537 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 01:03:48PM +0100, sf wrote:
> Andreas Ericsson wrote:
> 2. You can never prune the main (the supermodule's) repository, at least
> not with what git provides today.
It even already works (well, not with what git provides today, but with
my implementation). git-prune simply walks all the submodules, too, when
doing it's reachability analysis.
What does not work is a prune inside the submodule, because it does not
know about all the commits used by the supermodule.
--
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 12:12 UTC (permalink / raw)
To: sf; +Cc: git
In-Reply-To: <45701B8D.1030508@b-i-t.de>
[-- Attachment #1: Type: text/plain, Size: 662 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 01:09:49PM +0100, sf wrote:
> Martin Waitz wrote:
> ...
> >So you not only store your submodule HEAD commit in the supermodule when
> >you
> >do commit to the supermodule, it also means that your submodule HEAD
> >will be updated when you update your supermodule.
>
> Why the magic? The typical workflow in git is
>
> 1. You work on a branch, i.e. edit and commit and so on.
> 2. At some point, you decide to share the work you did on that branch
> (e-mail a patch, merge into another branch, push upstream or let it by
> pulled by upstream)
3. Other people want to use your new work.
--
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 12:12 UTC (permalink / raw)
To: git
In-Reply-To: <20061201111027.GR12463MdfPADPa@greensroom.kotnet.org>
On Friday 2006 December 01 11:10, Sven Verdoolaege wrote:
> You were proposing to create an extra object containing some random value
> that is disconnected from the repo.
Right, I think I've finally understood what Martin (and you) are proposing.
You want every commit in the submodule to be propagated up to the supermodule
as well. Okay.
I don't think it's right, but at least I understand.
It seems wrong because it's making commits in the supermodule that aren't
commits to do with that project. In my libxcb example; why should every
project use libxcb in have to store the entire history of libxcb? When
examining the supermodule history, I won't care about how libxcb got to the
state its in, and it's just noise in the supermodule history. What if I use
10 submodules, the supermodule history won't show you anything useful - it's
just unrelated submodule commits.
It gets worse, this is why I was asking for more detail: this commit that
you're storing in the supermodule. It's the same commit as is in the
submodule? What would the parent commit of that commit be? It has to be the
same in both, because the commit-hash forces it to be.
The only possibility would be that it's NOT the same hash in both, because the
parents in the supermodule are inapplicable to the submodule, and the parent
in the submodule is independent from the supermodule. That means you have to
store two commits: one for the submodule commit and one for the supermodule
commit. So what are you going to write in the supermodule commit? Answer: a
submodule commit hash - exactly as I said.
> > Is that commit in the submodule or the supermodule?
>
> It's in BOTH. That's why it's a *sub*module.
If it's in BOTH then the supermodule is a normal git repository. You aren't
tracking the submodule, you're just including it en masse. Using semantics
to justify a position isn't a very strong argument, calling it a "sub" module
is just an easy bit of naming for us to hang the discussion on, it isn't
necessarily a mathematical subset and superset.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-01 12:16 UTC (permalink / raw)
To: git; +Cc: Martin Waitz
In-Reply-To: <20061201114607.GN18810@admingilde.org>
On Friday 2006 December 01 11:46, Martin Waitz wrote:
> > That's no different from mine.
>
> Well, there simply is no proxy object inbetween.
That's fine, I was only using the proxy object to allow additional information
into the submodule object. Actually, I think it would always be better to
use a proxy object otherwise you have an error in the tree object, because it
will refer to an object that does not exist. The proxy object is allowed to
refer to objects that don't exist because it's not a tree object.
> > Is that commit in the submodule or the supermodule?
>
> Well, logically that commit belongs to the submodule and is referenced
> by the tree in the supermodule.
> Phyisically it is stored in the projects object database which is
> shared between the supermodule and all submodules (at least in my
> implementation).
Hmmm, "shared"? It must still be in the submodule physically though, and
presumably the supermodule uses alternatives to get access to it? Otherwise
the submodule will be impossible to separate from the supermodule.
> > I also want to know how we tell the difference between a
> > commit-in-supermodule and a
> > commit-in-supermodule-which-is-actually-in-submodule.
>
> There is no difference.
Okay. I think I'm still a bit lost then. I suppose I'll wait for your
patches to understand.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-01 12:20 UTC (permalink / raw)
To: git
In-Reply-To: <20061201113103.GM18810@admingilde.org>
On Friday 2006 December 01 11:31, Martin Waitz wrote:
> It really only stores the commit of the submodule directly.
> So there is no new submodule object type. The parent has a direct link
> to the submodule commit in his tree object and in its index. In order
> to separate them from normal files or normal subdirectories, they get a
> special mode: they are represented as socket.
Okay. I think I've got it now. I'm not convinced that the way you've chosen
is the correct way, primarily because the separation between supermodule and
submodule is not strong. Regardless, as you're doing it, you get to pick :-)
Is there a public repository I can look at to see what you've done? I'm
interested in the sort of plumbing changes needed to make something like this
work.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 12:28 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612011212.35656.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3340 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 12:12:34PM +0000, Andy Parkins wrote:
> On Friday 2006 December 01 11:10, Sven Verdoolaege wrote:
>
> > You were proposing to create an extra object containing some random value
> > that is disconnected from the repo.
>
> Right, I think I've finally understood what Martin (and you) are
> proposing. You want every commit in the submodule to be propagated up
> to the supermodule as well. Okay.
>
> I don't think it's right, but at least I understand.
Please note that the submodule commits are not part of the supermodule
commit chain, they are part of the supermodule _tree_.
> It seems wrong because it's making commits in the supermodule that aren't
> commits to do with that project.
Of course they are part of your project, just like all the tree and blob
objects, too.
> In my libxcb example; why should every project use libxcb in have to
> store the entire history of libxcb?
Because you want to be able to use the submodule as a repository of its
own, too. Be able to look at its history if you want to.
Be able to merge with new versions of the submodule.
This is what distiguishes a submodule from a pure file-based import of
another project.
> When examining the supermodule history, I won't care about how libxcb
> got to the state its in, and it's just noise in the supermodule
> history. What if I use 10 submodules, the supermodule history won't
> show you anything useful - it's just unrelated submodule commits.
Again: the submodules are part of your supermodule _tree_, not it's
commit chain. So you won't see the submodule commits when you invoke
git-log in the supermodule.
> It gets worse, this is why I was asking for more detail: this commit
> that you're storing in the supermodule. It's the same commit as is in
> the submodule?
It is _the_ commit from the submodule, yes.
> What would the parent commit of that commit be? It has to be the same
> in both, because the commit-hash forces it to be.
It is the commit of the submodule, so its parents point to the submodule
history.
> > > Is that commit in the submodule or the supermodule?
> >
> > It's in BOTH. That's why it's a *sub*module.
>
> If it's in BOTH then the supermodule is a normal git repository. You aren't
> tracking the submodule, you're just including it en masse.
The submodule is part of the entire project, so yes, it is included.
And the supermodule tracks submodule development by storing references
to the submodule history that was used at that time.
Lets try to paint a little diagram:
belongint to:
/--------- supermodule -------\ /---- submodule -------\
commit -> tree +-> blob
| +-> tree -> ...
| +-----------------> commit -> tree -> ...
v |
commit -> tree +-> ... v
| +-----------------> commit -> ...
| |
| v
| commit -> ...
v |
commit -> tree +-> ... v
+-----------------> commit
Both have their independent history, but they are linked as some
submodule versions are part of the supermodule tree.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Andy Parkins @ 2006-12-01 12:33 UTC (permalink / raw)
To: git
In-Reply-To: <7vd573amuy.fsf@assigned-by-dhcp.cox.net>
On Friday 2006 December 01 11:15, Junio C Hamano wrote:
> I think another exception should be needed. If the index does
> not match the working tree, it should not default to "-a".
No problem: just don't apply the patch :-) What you've asked for leaves it as
a no-op.
This patch activates "-a" when the index equals HEAD. i.e. git-commit would
do nothing in this situation. If it is disabled when the index doesn't match
the working tree, then we're back to "do nothing". i.e. HEAD==index==working
tree.
> So, please turn this "cleverness" off when the index does not
> match the working tree.
How does that help you? You've updated the index manually, so the
automatic "-a" is already disabled. Without this patch you would still have
committed the wrong thing.
$ edit builtin-blame.c
$ git update-index builtin-pickaxe.c
$ git commit
What is that you would like to have happened at this point?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 12:34 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612011216.04555.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1585 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 12:16:00PM +0000, Andy Parkins wrote:
> That's fine, I was only using the proxy object to allow additional
> information into the submodule object. Actually, I think it would
> always be better to use a proxy object otherwise you have an error in
> the tree object, because it will refer to an object that does not
> exist. The proxy object is allowed to refer to objects that don't
> exist because it's not a tree object.
It is exactly the aim of my implementation to not have any reference to
something that is not accessible in the supermodule repository.
> > > Is that commit in the submodule or the supermodule?
> >
> > Well, logically that commit belongs to the submodule and is referenced
> > by the tree in the supermodule.
> > Phyisically it is stored in the projects object database which is
> > shared between the supermodule and all submodules (at least in my
> > implementation).
>
> Hmmm, "shared"? It must still be in the submodule physically though,
> and presumably the supermodule uses alternatives to get access to it?
> Otherwise the submodule will be impossible to separate from the
> supermodule.
Yes, you can't separate it my just moving it out of the supermodule,
but you can always clone the submodule alone.
> Okay. I think I'm still a bit lost then. I suppose I'll wait for your
> patches to understand.
have a look at http://git.admingilde.org/tali/git.git/module2.
If you want to try it out, have a look at t/t7500-submodule.sh on how to
create submodules.
--
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 12:37 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612011220.43813.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 312 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 12:20:42PM +0000, Andy Parkins wrote:
> Is there a public repository I can look at to see what you've done?
> I'm interested in the sort of plumbing changes needed to make
> something like this work.
link is in the mail that started this thread ;-).
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Handling of branches in stgit
From: Catalin Marinas @ 2006-12-01 12:42 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20061130000038.GA13324@nan92-1-81-57-214-146.fbx.proxad.net>
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.
> 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.
> 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 plan to merge the stgit config with the git one (and have a [stgit]
section) so that it is more maintainable.
--
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: sf @ 2006-12-01 13:05 UTC (permalink / raw)
To: git
In-Reply-To: <20061201121234.GQ18810@admingilde.org>
Martin Waitz wrote:
> hoi :)
>
> On Fri, Dec 01, 2006 at 01:09:49PM +0100, sf wrote:
>> Martin Waitz wrote:
>> ...
>> >So you not only store your submodule HEAD commit in the supermodule when
>> >you
>> >do commit to the supermodule, it also means that your submodule HEAD
>> >will be updated when you update your supermodule.
>>
>> Why the magic? The typical workflow in git is
>>
>> 1. You work on a branch, i.e. edit and commit and so on.
>> 2. At some point, you decide to share the work you did on that branch
>> (e-mail a patch, merge into another branch, push upstream or let it by
>> pulled by upstream)
>
> 3. Other people want to use your new work.
Sorry, if that was not obvious: You actually procceed with one of the
options I listed in Step 2. What I wanted to state is that with git you
do not mix up committing (which is local to your repository and your
branch) and publishing.
Regards
Stephan
^ 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