* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 16:15 UTC (permalink / raw)
To: Stephan Feder; +Cc: git
In-Reply-To: <45705283.5080900@b-i-t.de>
[-- Attachment #1: Type: text/plain, Size: 643 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 05:04:19PM +0100, Stephan Feder wrote:
> I was looking into git-init-module.sh (branch module2). There you set up
> a separate git repository for the submodule and store references to it
> into the supermodules's repository.
yes.
This is to be able to call git-fsck-objects and git-prune in the
toplevel supermodule. When traversing the object tree, it already knows
about all submodule, but only about those versions that are really part
of their supermodule.
So I have to teach git about separate submodule branches which may be
used, in order not to prune them away.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: selective git-update-index per diff(1) chunks
From: Linus Torvalds @ 2006-12-01 16:06 UTC (permalink / raw)
To: Alexey Dobriyan; +Cc: git
In-Reply-To: <b6fcc0a0612010323x7554e47m5e6bdafe85fc8224@mail.gmail.com>
On Fri, 1 Dec 2006, Alexey Dobriyan wrote:
>
> Has anyone thought about aggregating this into git-update-index or
> somewhere?
>
> git-update-index -C1,3 #chunks 1, 3
> git commit
You can already do it, but it's called something else.
Instead of updating a certain hunk (which is fundamentally wrong, since it
depends on "diff" even working on that file), you can tell
git-update-index to update a certain _state_ for an arbitrary number of
files. Namely:
git-update-index [--cacheinfo <mode> <object> <file>]*
However, that obviously is very much a _plumbing_ command, and you need to
have some higher-level GUI on top of it to actually pick out the chunks
(if that is what you want) and generate the object(s) associated with the
file(s) with only those chunks and then do the above "install this state
into the index/staging area/whatever".
In other words, git already supports this on a _technical_ level, but does
not have the high-level interfaces for it, and quite frankly
"git-update-index" _shouldn't_ have the high-level interfaces for it. It's
designed to be the low-level technology, not the actual interface.
I think it's more appropriate for a GUI front-end, frankly, but you could
script it fairly easily with whatever your favourite patch editing tool:
(a) Generate the "result" file you want in /tmp or something, using patch
editing tools to extract a partial patch and apply it to the original
file.
(b) Use "git-hash-object" to create the backing store object, and get the
SHA1 for that file.
(c) Use "git-update-index --cacheinfo <mode> <sha1> <filename>" to
populate that new entry of yours into the index.
(d) Do (a)-(c) as many times as you like to handle all the files you
want to commit, and then just call "git commit"
iow, it's not hard, but no, git on its own is _not_ a patch-based system,
and doesn't do things hunk-for-hunk. You need that "hunk selector"
interface on top of it.
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Stephan Feder @ 2006-12-01 16:04 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20061201150746.GA18810@admingilde.org>
Martin Waitz wrote:
> hoi :)
>
> On Fri, Dec 01, 2006 at 03:23:07PM +0100, Stephan Feder wrote:
>> And what is already there is a lot of meta information (see above). You
>> do not need that.
>
> What information are you refering to?
> Perhaps you have looked into my old branch?
> The current implementation is in "module2".
I was looking into git-init-module.sh (branch module2). There you set up
a separate git repository for the submodule and store references to it
into the supermodules's repository.
>
>> For example, in the index, if it is a commit (i.e. a subproject), store
>> the commit id (not the commit's tree id ).
>
> This is exactly what I have done.
>
>> Especially, extend update-index to be able to store a commit
>> instead of the tree.
>
> Done, except that update-index never stores trees ;-)
Yes, I forgot.
>> Or else, do not change what is recorded in the index. Then, at commit
>> time, you not only commit the superproject but also all subprojects.
>
> But then submodules would be handled differently to files which I wanted
> to avoid.
On the other hand, it feels more naturally to only commit at the end of
your work. So both alternatives have their merits.
>
>> To push and pull you have to extend the tools as well. That is the next
>> step.
>
> Also done.
I hope I have time to give your solution a try.
Regards
Stephan
--
b.i.t.
beratungsgesellschaft für informations-technologie mbh
Stephan Feder
elisabethenstr. 62 fon: +49(0)6151/827575
64283 darmstadt fax: +49(0)6151/827576
mailto:sf@b-i-t.de www: http://www.b-i-t.de
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Stephan Feder @ 2006-12-01 15:47 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20061201145817.GY18810@admingilde.org>
Martin Waitz wrote:
> hoi :)
>
> On Fri, Dec 01, 2006 at 02:51:49PM +0100, Stephan Feder wrote:
>> If you work in the supermodule, even if it is in the code of the
>> submodule, you only commit to the supermodule. The submodule does not
>> "know" about these changes after step 1.
>
> I think we are using totally different definitions of "submodule".
No so different. The way I see it is that "I" (meaning with submodules
implemented as I proposed) could pull regularly from "your" repositories
(implemented as you proposed) and work with the result (including
submodules). Could you do the same?
> For me a submodule is responsible for everything in or below a certain
> directory. So by definition when you change something in this
> directory, you have to change it in the submodule.
But you do not consider the case where you cannot change the submodule
because you do not own it.
For example, git has the subproject xdiff. If git had been able to work
with subprojects as I envision, and if xdiff had been published as a git
repository (not necessarily subproject enabled), it could have been
pulled in git's subdirectory xdiff as a subproject. There would not have
been a separate branch or even repository for xdiff in the git repository.
All changes to xdiff in git could have been committed to the git
repository only. Independently, they could have been published to
upstream and be put into the xdiff repository by its author. But the
last part is what only the owner of the xdiff repository is able to decide.
(Ok, ok... the example sucks badly because xdiff has been massively
changed for its usage in git so the changes would not be integrated by
upstream. But you can imagine where you use a library essentially as is,
only if you discover bugs you fix them immediately in your repository
and keep those fixes in your version of the library, even on upgrade,
until the bugs have been fixed by upstream.)
> You can't change the submodule contents in the supermodule without also
> changing the submodule.
> This is just like you can't commit a change to a file without also
> changing the file.
There is a difference. I would say: If you commit a change to a file in
one branch, it need not be changed in all branches.
> Then the supermodule just records the current content of the entire
> tree. The only new thing is that instead of simple files there are now
> submodules and that are also recorded.
Yes, and that is all you need. If the changes are to be part of a branch
of the submodule, they have to be pulled. That is an independent operation.
>> Why do you mix up supermodule and submodule? The way I see your proposal
>> you cannot change submodule and supermodule independently. That is a
>> huge drawback.
>
> No, this is the benefit you get by introducing submodules.
> Why would you want to introduce a submodule when it is not linked to the
> supermodule?
Because the submodule must be independent of the supermodule.
I see where you are coming from. You have one project that is divided
into subprojects but the subprojects themselves are not independent.
What I would like to solve is the followng: You have a project X, an
this project is made part of two other projects Y and Z (as a submodule
or subproject or whatever you want to call it). The project X need not,
must not or cannot care that it was made a subproject. But in projects Y
and Z, you must be able to bugfix or extend or modify the code of
projectX, and you must be able to push and pull changes between all
three projects (of course we are only talking about the code part of
project X).
Do you see where your solution makes that impossible, and that with more
changes to the repository layout?
Regards
Stephan
^ permalink raw reply
* Re: Diffs from CVS keyword expansion
From: Jon Smirl @ 2006-12-01 15:33 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Juergen Ruehle, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0611302340030.3695@woody.osdl.org>
On 12/1/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Fri, 1 Dec 2006, Juergen Ruehle wrote:
>
> > Jon Smirl writes:
> > > Anyone have a nice script for suppressing diffs caused by CVS keyword
> > > expansion when someone checked the kernel sources into CVS?
> >
> > I usually just say (with GNU diff)
> >
> > diff -I $$ ...
> >
> > which is crude, but should be enough to get rid of the hunks listed by
> > you.
> >
> > You might also want -x CVS if you have the metadata files.
I don't have the original CVS, just a tarball snapshot with the
keywords expanded.
I'm working with the Freescale iMX21 and the Linux port for it has
never be added to the mainline kernel. I am extracting bits and pieces
of it from various vendor tarballs.
>
> Also, if you are actually _using_ CVS to check it out, use
>
> cvs co -ko
>
> I think, to not check out with keyword expansion at all.
>
> (Also usable with "cvs diff -ko", I think)
>
> Linus
>
> PS. Clueless user alert: I have happily not used CVS in years and years,
> and I might remember that all wrong.
>
--
Jon Smirl
^ permalink raw reply
* Re: [PATCH/RFC] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Andy Parkins @ 2006-12-01 15:17 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0612010507r5e6ee226t3a1e61113bf15d43@mail.gmail.com>
On Friday 2006 December 01 13:07, Alex Riesen wrote:
> Of course it is. It's just that the problem is not solved yet,
> and if -a becomes git-commit's default a simple git-commit
> will be a real annoying thing.
There was talk of making git-commit -a; bear in mind that this patch was to
completely sidestep making that default. This patch has no effect on
existing behaviour save for one special case: when commit would otherwise
have done nothing, it now does "git-commit -a".
If you have a problem with git-commit -a, then presumably you are already
using git-update-index for all your commit needs; in which case this patch
has zero impact on you.
> > Wasn't the whole point of this to avoid needing another config option?
>
> was it it the point of breaking existing setups?
Of course it isn't; I have no intention of breaking yours or anybody else's
setup. However, as your complaint is that this patch highlights another bug,
I would think the solution is fix the other bug, instead of botch around it
in this patch.
Perhaps I was a little terse; what I should have said was - I don't really
want to solve this executable bit problem with a config option; as that's
papering over the cracks. If executable bits are a problem, well why not
detect when that's the case automatically. I don't have a cygwin environment
so I have no way to test what you ask for.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 15:12 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612011411.20113.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 02:11:19PM +0000, Andy Parkins wrote:
> If I've understood; while the objects themselves are stored in the
> supermodule ODB, they are still independent. In fact, they're only in
> the supermodule tree because it's most convenient to keep them there;
> it sounds like it's very easy to strip them out again.
Yes.
> Again, if I'm understanding, it's a bit like when you have an
> additional root in a normal git repository, for example:
>
> * -- * -- * -- * (project1)
> \
> * -- * -- * (project1/stable)
>
> * -- * -- * -- * (project2)
>
> Then to make project2 a submodule of project1, one of the project1
> trees simply refers to a commit in project2.
Exactly.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 3/3] Group common commands into for groups for easier navigation
From: pclouds @ 2006-12-01 15:08 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <11649857203869-git-send-email-pclouds@gmail.com>
Repository/Branch level commands are grouped into group Repository
File manipulation commands are in group Manipulation
Other status commands are in group Status
The rest is in group Other
Signed-off-by: Nguyá»…n Thái Ngá»c Duy <pclouds@gmail.com>
---
This is a suggestion. Someone may have better layout than me.
generate-cmdlist.sh | 35 +++++++++++++++++++++--------------
1 files changed, 21 insertions(+), 14 deletions(-)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index b45495d..f385854 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -10,33 +10,40 @@ struct cmdname_help
struct cmdname_help common_cmds[] = {"
cat <<\EOF |
-add
-apply
-archive
-bisect
+G:Repository
+init-db
branch
-checkout
-cherry-pick
clone
-commit
-diff
fetch
-grep
-init-db
-log
merge
-mv
prune
pull
push
-rebase
reset
+tag
+
+G:Manipulation
+add
+apply
+checkout
+commit
+mv
revert
rm
+
+G:Status
+diff
+log
show
show-branch
status
-tag
+
+G:Other
+archive
+bisect
+cherry-pick
+grep
+rebase
verify-tag
EOF
while read cmd
--
1.4.4.rc1.g9124
^ permalink raw reply related
* [PATCH 2/3] Prepare for grouped common command list generation
From: pclouds @ 2006-12-01 15:08 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1164985711791-git-send-email-pclouds@gmail.com>
Signed-off-by: Nguyá»…n Thái Ngá»c Duy <pclouds@gmail.com>
---
generate-cmdlist.sh | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 5450918..b45495d 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -9,7 +9,7 @@ struct cmdname_help
struct cmdname_help common_cmds[] = {"
-sort <<\EOF |
+cat <<\EOF |
add
apply
archive
@@ -41,6 +41,11 @@ verify-tag
EOF
while read cmd
do
+ [ -z "$cmd" ] && continue
+ if echo $cmd|grep -q '^G:'; then
+ echo ' {"'$(echo -n $cmd|sed 's/^G://')'",""},'
+ continue
+ fi
sed -n '
/NAME/,/git-'"$cmd"'/H
${
--
1.4.4.rc1.g9124
^ permalink raw reply related
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 15:07 UTC (permalink / raw)
To: Stephan Feder; +Cc: git
In-Reply-To: <45703ACB.6050007@b-i-t.de>
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 03:23:07PM +0100, Stephan Feder wrote:
> And what is already there is a lot of meta information (see above). You
> do not need that.
What information are you refering to?
Perhaps you have looked into my old branch?
The current implementation is in "module2".
> For example, in the index, if it is a commit (i.e. a subproject), store
> the commit id (not the commit's tree id ).
This is exactly what I have done.
> Especially, extend update-index to be able to store a commit
> instead of the tree.
Done, except that update-index never stores trees ;-)
> Or else, do not change what is recorded in the index. Then, at commit
> time, you not only commit the superproject but also all subprojects.
But then submodules would be handled differently to files which I wanted
to avoid.
> To push and pull you have to extend the tools as well. That is the next
> step.
Also done.
--
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 15:00 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: sf, git
In-Reply-To: <457041AD.4010601@op5.se>
[-- Attachment #1: Type: text/plain, Size: 565 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 03:52:29PM +0100, Andreas Ericsson wrote:
> >Remember: if you git-pull in the supermodule, you want to update the
> >whole thing, including all submodules.
> >
>
> Only if the new commits I pull into the supermodule DAG has commits
> which includes a new shapshot of the submodule, otherwise it wouldn't be
> necessary.
Of course.
But if the supermodule contains changes to the submodule, you still
have to change the submodule. And this implies changing the submodule
HEAD or some branch.
--
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 14:58 UTC (permalink / raw)
To: Stephan Feder; +Cc: git
In-Reply-To: <45703375.4050500@b-i-t.de>
[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 02:51:49PM +0100, Stephan Feder wrote:
> If you work in the supermodule, even if it is in the code of the
> submodule, you only commit to the supermodule. The submodule does not
> "know" about these changes after step 1.
I think we are using totally different definitions of "submodule".
For me a submodule is responsible for everything in or below a certain
directory. So by definition when you change something in this
directory, you have to change it in the submodule.
You can't change the submodule contents in the supermodule without also
changing the submodule.
This is just like you can't commit a change to a file without also
changing the file.
Then the supermodule just records the current content of the entire
tree. The only new thing is that instead of simple files there are now
submodules and that are also recorded.
> Why do you mix up supermodule and submodule? The way I see your proposal
> you cannot change submodule and supermodule independently. That is a
> huge drawback.
No, this is the benefit you get by introducing submodules.
Why would you want to introduce a submodule when it is not linked to the
supermodule?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andreas Ericsson @ 2006-12-01 14:52 UTC (permalink / raw)
To: Martin Waitz; +Cc: sf, git
In-Reply-To: <20061201134610.GW18810@admingilde.org>
Martin Waitz wrote:
> hoi :)
>
> On Fri, Dec 01, 2006 at 02:43:16PM +0100, Andreas Ericsson wrote:
>> So a commit in the supermodule turns into a commit in the submodule?
>
> no.
>
>> If it doesn't, why would the submodule HEAD have to change?
>
> So how do you update your submodule?
>
By committing to it separately, or by getting changes from the upstream
project (openssl, libcurl, ...).
> Remember: if you git-pull in the supermodule, you want to update the
> whole thing, including all submodules.
>
Only if the new commits I pull into the supermodule DAG has commits
which includes a new shapshot of the submodule, otherwise it wouldn't be
necessary.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Stephan Feder @ 2006-12-01 14:23 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20061201134311.GV18810@admingilde.org>
Martin Waitz wrote:
> hoi :)
>
> On Fri, Dec 01, 2006 at 02:21:20PM +0100, sf wrote:
>> I just had a short (really short) look at your work. My impression is
>> that your repository setup is much too complicated.
>
> Well, I'm not really satisfied with the UI part.
> What exactly do you find complicated?
I am not talking about the UI. On the contrary, I am talking about the
repository, i.e. the directories and files on your disk and their
contents. You add a lot of additional information to the repository that
is not needed at all.
>> As I proposed elsewhere: For submodules to work you only need to allow
>> commits in tree objects (that is what your implementation requires as
>> well). Everything else is in the tools. Much simpler.
>
> I do not quite get your point.
> The core of my work allows to put commits into tree objects.
That is fine.
> Then there is some more (but not quite finished) work to make the tools
> work together with submodules. So no, not everything is there yet.
And what is already there is a lot of meta information (see above). You
do not need that.
For example, in the index, if it is a commit (i.e. a subproject), store
the commit id (not the commit's tree id ). Make the tools handle this
case (as yet, all code expects only trees and blobs when they parse
trees). Especially, extend update-index to be able to store a commit
instead of the tree.
Or else, do not change what is recorded in the index. Then, at commit
time, you not only commit the superproject but also all subprojects.
Or allow both.
Anyway, you can create commits in tree objects. See, you did not need to
store any additional information in the repository.
To push and pull you have to extend the tools as well. That is the next
step.
Regards
Stephan
--
b.i.t.
beratungsgesellschaft für informations-technologie mbh
Stephan Feder
elisabethenstr. 62 fon: +49(0)6151/827575
64283 darmstadt fax: +49(0)6151/827576
mailto:sf@b-i-t.de www: http://www.b-i-t.de
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andy Parkins @ 2006-12-01 14:11 UTC (permalink / raw)
To: git
In-Reply-To: <20061201122854.GR18810@admingilde.org>
On Friday 2006 December 01 12:28, Martin Waitz wrote:
> > 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.
I wouldn't go as far as that; just because I use libxcb doesn't mean I want
it's history merged with mine. However, I think my worries are unfounded,
your comment about being able to independently clone the libxcb tree helped
me there. If I've understood; while the objects themselves are stored in the
supermodule ODB, they are still independent. In fact, they're only in the
supermodule tree because it's most convenient to keep them there; it sounds
like it's very easy to strip them out again.
> It is the commit of the submodule, so its parents point to the submodule
> history.
Again, if I'm understanding, it's a bit like when you have an additional root
in a normal git repository, for example:
* -- * -- * -- * (project1)
\
* -- * -- * (project1/stable)
* -- * -- * -- * (project2)
Then to make project2 a submodule of project1, one of the project1 trees
simply refers to a commit in project2.
I think my original idea for how this works was correct with one minor flaw,
and from that flaw all the other concerns flowed. I imagined that there were
two object databases - one for the supermodule and one for the submodule.
The fault was that there aren't two ODBs there are two roots. Which of
course is a far easier way to blend to repositories. Apart from that, I
think I'm entirely in sync, and it was merely my wanting to put each of these
roots in their own repository that caused all the confusion.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 14:07 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612011400.00262.andyparkins@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 01:59:58PM +0000, Andy Parkins wrote:
> My apologies for bothering you so much with all these questions.
You were not bothering me.
Those were really interesting and valid questions.
In fact, it was a long way for me to come to the implementation I have
now. And I really did ask many of those questions to me, too.
I should really write a nice paper about all of that, I think.
> I just got a bit interested in it all :-)
Good :-)
--
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 13:59 UTC (permalink / raw)
To: git
In-Reply-To: <20061201123447.GS18810@admingilde.org>
On Friday 2006 December 01 12:34, Martin Waitz wrote:
> It is exactly the aim of my implementation to not have any reference to
> something that is not accessible in the supermodule repository.
Okay - I think you've put me right in another reply on this point - the
submodule commit is in the supermodule; that was the part I hadn't got.
> Yes, you can't separate it my just moving it out of the supermodule,
> but you can always clone the submodule alone.
Ah - now that clarifies things a lot. The fact that you can't separate it by
moving it implies lots of things that take away many of my earlier worries.
> 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.
Thanks. I will look hard at this :-) My apologies for bothering you so much
with all these questions. I just got a bit interested in it all :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Stephan Feder @ 2006-12-01 13:51 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20061201133558.GU18810@admingilde.org>
Martin Waitz wrote:
> hoi :)
>
> On Fri, Dec 01, 2006 at 02:05:33PM +0100, sf wrote:
>> >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.
>
> I guess you are refering to not mix up committing to the submodule and
> updating the supermodule index.
The opposite: If you work in the supermodule, even if it is in the code
of the submodule, you only commit to the supermodule. The submodule does
not "know" about these changes after step 1.
> These are really two separate steps, I just combined them above because I
> wanted to put emphasis on the other part: it is not a one-way flow, it
> is bidirectional, so your HEAD would have to changed if the supermodule
> gets updated.
Why do you mix up supermodule and submodule? The way I see your proposal
you cannot change submodule and supermodule independently. That is a
huge drawback.
Regards
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 13:46 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: sf, git
In-Reply-To: <45703174.8000609@op5.se>
[-- Attachment #1: Type: text/plain, Size: 395 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 02:43:16PM +0100, Andreas Ericsson wrote:
> So a commit in the supermodule turns into a commit in the submodule?
no.
> If it doesn't, why would the submodule HEAD have to change?
So how do you update your submodule?
Remember: if you git-pull in the supermodule, you want to update the
whole thing, including all submodules.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Andreas Ericsson @ 2006-12-01 13:43 UTC (permalink / raw)
To: Martin Waitz; +Cc: sf, git
In-Reply-To: <20061201133558.GU18810@admingilde.org>
Martin Waitz wrote:
> hoi :)
>
> On Fri, Dec 01, 2006 at 02:05:33PM +0100, sf wrote:
>>> 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.
>
> I guess you are refering to not mix up committing to the submodule and
> updating the supermodule index.
> These are really two separate steps, I just combined them above because I
> wanted to put emphasis on the other part: it is not a one-way flow, it
> is bidirectional, so your HEAD would have to changed if the supermodule
> gets updated.
> And I consider changing HEAD, without looking at the branch it points
> to, to be a bad thing.
>
So a commit in the supermodule turns into a commit in the submodule?
That's just plain wrong. If it doesn't, why would the submodule HEAD
have to change?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: [RFC] Submodules in GIT
From: Martin Waitz @ 2006-12-01 13:43 UTC (permalink / raw)
To: sf; +Cc: git
In-Reply-To: <45702C50.9050307@b-i-t.de>
[-- Attachment #1: Type: text/plain, Size: 750 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 02:21:20PM +0100, sf wrote:
> I just had a short (really short) look at your work. My impression is
> that your repository setup is much too complicated.
Well, I'm not really satisfied with the UI part.
What exactly do you find complicated?
> As I proposed elsewhere: For submodules to work you only need to allow
> commits in tree objects (that is what your implementation requires as
> well). Everything else is in the tools. Much simpler.
I do not quite get your point.
The core of my work allows to put commits into tree objects.
Then there is some more (but not quite finished) work to make the tools
work together with submodules. So no, not everything is there yet.
--
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 13:35 UTC (permalink / raw)
To: sf; +Cc: git
In-Reply-To: <4570289D.9050802@b-i-t.de>
[-- Attachment #1: Type: text/plain, Size: 1425 bytes --]
hoi :)
On Fri, Dec 01, 2006 at 02:05:33PM +0100, sf wrote:
> >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.
I guess you are refering to not mix up committing to the submodule and
updating the supermodule index.
These are really two separate steps, I just combined them above because I
wanted to put emphasis on the other part: it is not a one-way flow, it
is bidirectional, so your HEAD would have to changed if the supermodule
gets updated.
And I consider changing HEAD, without looking at the branch it points
to, to be a bad thing.
--
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 13:21 UTC (permalink / raw)
To: git
In-Reply-To: <20061201121110.GP18810@admingilde.org>
Martin Waitz wrote:
> 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.
I just had a short (really short) look at your work. My impression is
that your repository setup is much too complicated.
As I proposed elsewhere: For submodules to work you only need to allow
commits in tree objects (that is what your implementation requires as
well). Everything else is in the tools. Much simpler.
Regards
Stephan
^ permalink raw reply
* Re: [PATCH/RFC] Make git-commit cleverer - have it figure out whether it needs -a automatically
From: Alex Riesen @ 2006-12-01 13:07 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612011052.48784.andyparkins@gmail.com>
On 12/1/06, Andy Parkins <andyparkins@gmail.com> wrote:
>
> > The is dangerous on filesystems which lie to the programs about file
> > metadata. The "virtual filesystem" of cygwin is one of this kind: exec-bit
> > of the files depend
> > on its contents. Just calling git-commit -a will commit executability
> > at this particular
> > moment. For whatever reason, disabling handling of the exec-mode in gits
> > config does not work.
>
> Surely this is a separate fault?
>
Of course it is. It's just that the problem is not solved yet,
and if -a becomes git-commit's default a simple git-commit
will be a real annoying thing.
> > If you about to change the behavior, provide at least a config option
> > to go back
> > to the old git-commit, which didn't do any magic.
>
> Wasn't the whole point of this to avoid needing another config option?
>
^ 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