* Re: [PATCH 5/5] Add gitmodules(5)
From: Josef Weidendorfer @ 2007-06-12 13:50 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Lars Hjemli, Frank Lichtenheld, Junio C Hamano, skimo, git
In-Reply-To: <200706121540.52753.Josef.Weidendorfer@gmx.de>
On Tuesday 12 June 2007, Josef Weidendorfer wrote:
> IMHO sharing of the admin submodule repository should even be possible
> if I have a clone of kdelibs and kdebase independent of the big
> KDE superproject.
>
> It would be nice to allow submodule.<name>.repopath configs globally
> in ~/.gitconfig, and cloning kdelibs should automatically do the
> right thing, ie. use the already available admin repo for the kdelibs
> clone.
I just realize that this should be already possible now by setting
submodule.<name>.url in ~/.gitconfig. It could automatically
use "git-clone -l -s -n ..." if the URL is local.
Josef
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Josef Weidendorfer @ 2007-06-12 13:40 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Lars Hjemli, Frank Lichtenheld, Junio C Hamano, skimo, git
In-Reply-To: <466E9469.5D6BD391@eudaptics.com>
On Tuesday 12 June 2007, Johannes Sixt wrote:
> Josef Weidendorfer wrote:
> > However, to not have a lot of copies of the admin submodule
> > in
> >
> > .git/submodule/admin
> > .git/submodule/kdelibs/.git/submodule/admin
> > .git/submodule/kdebase/.git/submodule/admin
> > .git/submodule/kdenetwork/.git/submodule/admin
> >
> > the just suggested submodule.<name>.repopath to specify a repository
> > outside of .git/submodule to be shared by kdelibs,kdebase,... would
> > be fine.
>
> This clearly shows that having the repositories of submodules in
> .git/submodule does not buy you enough to avoid duplication.
The .git/submodule space for sure is not flexible enough for all
possible use cases of submodules (as with KDE repo).
However, as default it seems fine to me.
IMHO sharing of the admin submodule repository should even be possible
if I have a clone of kdelibs and kdebase independent of the big
KDE superproject.
It would be nice to allow submodule.<name>.repopath configs globally
in ~/.gitconfig, and cloning kdelibs should automatically do the
right thing, ie. use the already available admin repo for the kdelibs
clone.
> (I don't see enough reason to place a repo for submodule X in project Y
> outside its "natural" checked-out directory in project Y. But then, I
> haven't followed the discussion.
To easily share the objects, branches and local modifications?
Currently a clone of a superproject always does a full copy of
any submodule databases because it is independent from any other
local git repository; in the KDE case you would get >4 admin copiess
if recursive cloning of submodules inside of submodules does that.
Josef
^ permalink raw reply
* Re: git-fetch, was Re: [PATCH] Port git-tag.sh to C.
From: Julian Phillips @ 2007-06-12 13:29 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Daniel Barkalow, Carlos Rica, =?X-UNKNOWN?Q?Kristian_H=F8gsberg?=,
git
In-Reply-To: <Pine.LNX.4.64.0706121341250.4059@racer.site>
On Tue, 12 Jun 2007, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 11 Jun 2007, Daniel Barkalow wrote:
>
>> On Sat, 9 Jun 2007, Carlos Rica wrote:
>>
>>> Feel free to choose the script which you need to get replaced first,
>>> or, depending on your urgency, you could ask me for one of them and I
>>> would try to concentrate my efforts on it. Why do you started with
>>> git-tag? For me, it was enough easy to begin with, perhaps you could
>>> have other reasons.
>>
>> Incidentally, I have been working on fetch, based on Julian Phillips's
>> version. I'm trying to split out the "how do I communicate with remote
>> repositories" code, and use it for pushing and ls-remote as well as
>> fetch. I've got a bunch of not-for-official-history development that you
>> should look at if you try any of the remote-repository-access scripts.
>
> How about pushing them onto repo.or.cz as a fork of git.git?
I'd quite like to see these changes too - since I haven't finished the
fetch work yet, and I don't want to duplicate effort ;)
(It seems that the closer I get to a working fetch the less time I spend
on it ... :$)
--
Julian
---
Old robot: I choose to believe what I was programmed to believe.
^ permalink raw reply
* git-fetch, was Re: [PATCH] Port git-tag.sh to C.
From: Johannes Schindelin @ 2007-06-12 12:41 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Carlos Rica, =?X-UNKNOWN?Q?Kristian_H=F8gsberg?=, git,
Julian Phillips
In-Reply-To: <Pine.LNX.4.64.0706112314300.5848@iabervon.org>
Hi,
On Mon, 11 Jun 2007, Daniel Barkalow wrote:
> On Sat, 9 Jun 2007, Carlos Rica wrote:
>
> > Feel free to choose the script which you need to get replaced first,
> > or, depending on your urgency, you could ask me for one of them and I
> > would try to concentrate my efforts on it. Why do you started with
> > git-tag? For me, it was enough easy to begin with, perhaps you could
> > have other reasons.
>
> Incidentally, I have been working on fetch, based on Julian Phillips's
> version. I'm trying to split out the "how do I communicate with remote
> repositories" code, and use it for pushing and ls-remote as well as
> fetch. I've got a bunch of not-for-official-history development that you
> should look at if you try any of the remote-repository-access scripts.
How about pushing them onto repo.or.cz as a fork of git.git?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Johannes Sixt @ 2007-06-12 12:41 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Lars Hjemli, Frank Lichtenheld, Junio C Hamano, skimo, git
In-Reply-To: <200706121423.02127.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
> However, to not have a lot of copies of the admin submodule
> in
>
> .git/submodule/admin
> .git/submodule/kdelibs/.git/submodule/admin
> .git/submodule/kdebase/.git/submodule/admin
> .git/submodule/kdenetwork/.git/submodule/admin
>
> the just suggested submodule.<name>.repopath to specify a repository
> outside of .git/submodule to be shared by kdelibs,kdebase,... would
> be fine.
This clearly shows that having the repositories of submodules in
.git/submodule does not buy you enough to avoid duplication.
(I don't see enough reason to place a repo for submodule X in project Y
outside its "natural" checked-out directory in project Y. But then, I
haven't followed the discussion. Please ignore me if above layout choice
is for more than just avoiding duplication.)
-- Hannes
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Lars Hjemli @ 2007-06-12 12:37 UTC (permalink / raw)
To: Josef Weidendorfer
Cc: Johannes Sixt, Frank Lichtenheld, Junio C Hamano, skimo, git
In-Reply-To: <200706121423.02127.Josef.Weidendorfer@gmx.de>
On 6/12/07, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Tuesday 12 June 2007, Lars Hjemli wrote:
> > I
> > would not expect the KDE 'supersuperproject' to know about admin at
> > all, neither in its index nor .gitmodules.
>
> The admin submodule contains KDE specific things. So of course it
> also would be a submodule in the grand whole KDE superduper module.
Aha! But as you say:
> But that does not really matter.
Exactly.
>
> However, to not have a lot of copies of the admin submodule
> in
>
> .git/submodule/admin
> .git/submodule/kdelibs/.git/submodule/admin
> .git/submodule/kdebase/.git/submodule/admin
> .git/submodule/kdenetwork/.git/submodule/admin
>
> the just suggested submodule.<name>.repopath to specify a repository
> outside of .git/submodule to be shared by kdelibs,kdebase,... would
> be fine.
Yes, repopath would work out nice for KDE (which btw seems to be a
great test-case for git-submodule)
--
larsh
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Josef Weidendorfer @ 2007-06-12 12:23 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Sixt, Frank Lichtenheld, Junio C Hamano, skimo, git
In-Reply-To: <8c5c35580706120412o516ec39p71332d23823d7389@mail.gmail.com>
On Tuesday 12 June 2007, Lars Hjemli wrote:
> On 6/12/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> > > > KDE (superproject)
> > > > +- kdelibs (subproject)
> > > > | +- admin (subproject)
> > > > | +- subdir1
> > > > | +- ...
> > > > +- kdebase (subproject)
> > > > | +- admin (subproject)
> > > > | +- subdir2
> > > > | +- ...
> > > > +- kdenetwork (subproject)
> > > > | +- admin (subproject)
> > > > | +- subdir3
> > > > | +- ...
> > > > ...
>
> In this case, I would assume that e.g. kdelibs contain a submodule
> entry for path admin in its index, accompanied by a .gitmodules file
> saying that the path admin is mapped to this or that submodule.
Exactly. That's just the "submodule" in "submodule" case we should
support, too.
> I
> would not expect the KDE 'supersuperproject' to know about admin at
> all, neither in its index nor .gitmodules.
The admin submodule contains KDE specific things. So of course it
also would be a submodule in the grand whole KDE superduper module.
But that does not really matter.
However, to not have a lot of copies of the admin submodule
in
.git/submodule/admin
.git/submodule/kdelibs/.git/submodule/admin
.git/submodule/kdebase/.git/submodule/admin
.git/submodule/kdenetwork/.git/submodule/admin
the just suggested submodule.<name>.repopath to specify a repository
outside of .git/submodule to be shared by kdelibs,kdebase,... would
be fine.
Josef
^ permalink raw reply
* Re: git-svn set-tree bug
From: Steven Grimm @ 2007-06-12 12:15 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, Joakim Tjernlund, git
In-Reply-To: <20070612083910.GA28369@muzzle>
Eric Wong wrote:
> Yes, "mainline" meaning the history that would be committed to SVN if
> history were linear.
>
I think the first parent is always the right one to follow. The only
time you won't hit a git-svn revision is if the user is trying to commit
a branch that is not originally derived from a git-svn branch, and IMO
that's something that git-svn is perfectly justified in refusing to do.
Also, the default "git log" output will follow the first parent; users
who run that are going to have a natural expectation that the subsequent
commits will be merged into the most recent git-svn revision as shown by
that tool.
> This only works if a merge is the first commit to be committed
> in a chain of commits.
>
As for the more complex case of a chain of commits with a merge in the
middle, IMO walking along the chain of first parents until you hit a
git-svn revision, then proceeding forward in time from there rewriting
parents as you've described, is always going to be the right thing to
do. Or at least, all the use cases I can think of seem to be correctly
covered by that approach. Can someone come up with counterexamples?
This is great -- I'm looking forward to ditching my hackish merge script!
At the risk of getting ahead of myself, here's one more thought: in the
case where a merge's parents are all git-svn revisions -- that is, where
the user is using git to merge svn branches -- I wonder if it makes
sense to optionally record that merge somehow in the commit comment on
the svn side. I think that could be made relatively human-readable so as
not to be too obnoxious for people browsing the svn history. That way
someone pulling down a fresh git-svn clone of the svn repo could get a
nice clean history with the merges represented properly in the git
revision history.
That's justifiable in another way too: the autogenerated comments on git
merge commits won't really make much sense over on the svn side, where
merges are thought of in terms of revision ranges. So replacing the
git-specific merge message with an svn-specific one doesn't seem
unreasonable to me. (Again, optionally.) And in cases where the user has
supplied his own merge comment on the git side, annotating it with the
additional git-svn metadata seems reasonable to me. We are already fine
with the git-side comments having a line of git-svn metadata, after all.
Most of the svn-side merge comments in my company's repo look like
either "svn merge -r12345:67890 mybranch" (where the developer wants to
make the merge's inputs very explicit to avoid any confusion) or "Merge
revisions 12345 through 67890 from mybranch", occasionally surrounded by
some explanatory text. If git-svn replaced the canned git merge message
with a canned message like one of those, people wouldn't be able to tell
I'd used git-svn instead of svn to do the merge.
-Steve
^ permalink raw reply
* Re: [PATCH 1/3] refactor dir_add_name
From: Jeff King @ 2007-06-12 12:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonas Fonseca, git
In-Reply-To: <7v7iq9lk76.fsf@assigned-by-dhcp.pobox.com>
On Tue, Jun 12, 2007 at 12:13:01AM -0700, Junio C Hamano wrote:
> That looks ugly and also I am curious what the generated
> assembly would look like. Hopefully the compiler is clever
> enough to generate the same code, but I dunno.
I was curious, too...the assembly generated by gcc -O2 is identical for
both versions.
> Unless somebody else more versed with C preprocessor tricks
> comes along and offers a better advice, I would go with the
> earlier simpler one with a big fat warning. I however would
> prefer all caps name for a magic macro like this, whose sole
> point is a huge side effect.
Agreed on the all-caps (in either case) because of the side effects.
The more I think about it, I think the inline'd version is better.
Multiple evaluation pre-processor bugs are _nasty_ to find, and while
the implementation is ugly, it's better to contain the ugliness to one
spot than to introduce a dangerous interface that will be used all over.
I'm a bit rusty on my preprocessor tricks, but ISTR that there really
isn't a good way to portably avoid the problems. gcc has typeof, which
we could use to make temporary copies (which gcc would presumably
optimize out), but I imagine we don't want to be gcc-specific. We could
conditionally use that construct, but maybe at that point we're getting
as ugly as the inline).
-Peff
^ permalink raw reply
* [PATCH] Edit user manual for grammer.
From: Steve Hoelzer @ 2007-06-12 12:18 UTC (permalink / raw)
To: git
Signed-off-by: Steve Hoelzer <shoelzer@gmail.com>
---
Documentation/user-manual.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 0bfa21b..68bf4e2 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1529,7 +1529,7 @@ dangling tree b24c2473f1fd3d91352a624795be026d64c8841f
Dangling objects are not a problem. At worst they may take up a little
extra disk space. They can sometimes provide a last-resort method of
-recovery lost work--see <<dangling-objects>> for details. However, if
+recovering lost work--see <<dangling-objects>> for details. However, if
you want, you may remove them with gitlink:git-prune[1] or the --prune
option to gitlink:git-gc[1]:
--
1.5.2.73.g18bece
^ permalink raw reply related
* Re: [PATCH 5/5] Add gitmodules(5)
From: Josef Weidendorfer @ 2007-06-12 12:05 UTC (permalink / raw)
To: Lars Hjemli; +Cc: skimo, Frank Lichtenheld, Junio C Hamano, git
In-Reply-To: <8c5c35580706120323t52b0d095v6ab6013ee2c8fdea@mail.gmail.com>
On Tuesday 12 June 2007, Lars Hjemli wrote:
> If you're thinking about the detached HEAD: yeah, that's a problem. My
> initial plan (with later modifications) was something like this:
>
> ...
>
> $ git-submodule update
> git-clone --bare git://example.com/lib.git .git/submodules/lib.git
> git-clone -l -s -n .git/submodules/lib.git lib1
> (cd lib1 && git-checkout $sha1)
> git-clone -l -s -n .git/submodules/lib.git lib2
> (cd lib2 && git-checkout $sha2)
> ...
That looks fine to me.
> git-submodule push:
> (cd lib1 && git-push origin $branch1)
> (cd lib2 && git-push origin $branch2)
This could be problematic. You are only storing changes on the
given branch. Ah, you wanted to avoid this problem with the symlink?
Perhaps we need better support for "push all reachable objects
which are not on the remote side together with any branch tip changes".
Or is this somehow already available with git-push?
Or ...
> I thought I could avoid 'git-submodule push' by using symlinks, but
> you're right. It will not work. Back to the drawing board (again...)
... we revive the "lightweight checkout" idea: share everything
but index and HEAD with a given repository. Similar to
"contrib/workdir/git-new-workdir" but witt support in git-core
to avoid the need for symlinks.
> > A workaround for problem (1) would be to create multiple checkouts of the
> > same submodule if modified, e.g. in .git/submodule/$name/$sha1 .
>
> And the $sha1 would be the sha1 found in the index? I don't think this
> would work either. If two branches in the superproject checkout the
> same submodule sha1, you could possibly want to keep different changes
> in the submodule depending on which branch of the superproject is
> checked out.
OK, does not work.
> > Allowing people to work like that is nice, but it should not be forced.
> > It would also be nice to allow the user to specify another place where
> > submodule checkouts are to be stored, e.g. when multiple supermodules
> > share the same submodule.
>
> True. Maybe submodule.<name>.repopath in .git/config? (If not
> specified, default to .git/submodules/<name>.git)
Sounds good. However, can be done later.
Josef
>
> --
> larsh
>
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Marco Costalba @ 2007-06-12 11:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Shawn O. Pearce, Git Mailing List
In-Reply-To: <e5bfff550706120427g7ad9d38bpc34d9ea284ace693@mail.gmail.com>
On 6/12/07, Marco Costalba <mcostalba@gmail.com> wrote:
>
> So the complexity of annotating *all* the files revisions grows only
> linearly with the revision list size.
>
Going from newest to oldest, after having elaborated all the diffs
between revisions you have the newest file correctly annotated.
Going from oldest to newest, after having elaborated *in the same way
as above* all the diffs between revisions, you have _all_ the files
correctly annotated.
^ permalink raw reply
* Re: That improved git-gui blame viewer..
From: Marco Costalba @ 2007-06-12 11:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Shawn O. Pearce, Git Mailing List
In-Reply-To: <7vbqflll55.fsf@assigned-by-dhcp.pobox.com>
On 6/12/07, Junio C Hamano <gitster@pobox.com> wrote:
>
> > Annotate algorithm of qgit is little different in that it starts from
> > the oldest revision that modified a file and goes to the latest. In
> > this way we can have the whole file history annotated in one pass and
> > very fast.
>
> I am not sure about two things in this description.
>
> (1) Are you emulating CVS-like "a file has an identity, and we
> follow its changes" model? How does it handle file split,
> merge, and code movement in general?
>
It uses 'git rev-list HEAD -- <path>' to get the list of revisions
that modified a path,
I really would like to keep it like that because it is the way 'git'
works, and I would feel uncomfortable in filtering out git results, it
seems quite fragile to me.
This means that file splits, merges, renames etc.. are handled as much
as they are handled in git. IOW *if* 'git rev-list HEAD -- <path>'
returns a list of revisions taking in account all of the above, so it
will, automatically, do qgit.
BTW _currentlly_ git-rev-list does not do that.
> (2) It is unclear why going from old to new has the advantage
> of being "one pass", implication of which is that the
> opposite direction needs to be done as more than one pass.
> Care to enlighten?
>
Going from oldest to newest has this advantage:
1 - start from a known good first (empty) annotation, i.e. the first
revision in history has an empty annotation (this is a choice to get
consistent results when dealing with git repository started after the
begining of the project, Linux tree started from 2.6.12 is an
example).
2 - Given a good annotation (ann1) at a given time in history you can
calculate the next annotation (ann2), the annotation corresponding to
the next (newer) revision in history that modified the file using just
the diff between the two. If you don't discards ann1 you end up having
both ann1 and ann2.
3 - So at the end of applying all the diff chain you get all the
annotations for all the file revisions, each annotation requires only
the previous one and the corresponding diff.
4 - You don't need to touch anymore an already calculated file, nor
applying the corresponding diff more then one time.
So the complexity of annotating *all* the files revisions grows only
linearly with the revision list size.
Marco
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Lars Hjemli @ 2007-06-12 11:12 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Frank Lichtenheld, Junio C Hamano, skimo, git
In-Reply-To: <466E7D7E.7BAB2FD@eudaptics.com>
On 6/12/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Lars Hjemli wrote:
> >
> > (readded the gitlist)
> >
> > On 6/12/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> > > Lars Hjemli wrote:
> > > > Multiple checkout paths for a single submodule will bring havoc on
> > > > this plan, so I need to ask: what is the use-case for multiple
> > > > checkout paths?
> > >
> > > A use-case is the admin directory in the KDE repository. It has:
> > >
> > > KDE (superproject)
> > > +- kdelibs (subproject)
> > > | +- admin (subproject)
> > > | +- subdir1
> > > | +- ...
> > > +- kdebase (subproject)
> > > | +- admin (subproject)
> > > | +- subdir2
> > > | +- ...
> > > +- kdenetwork (subproject)
> > > | +- admin (subproject)
> > > | +- subdir3
> > > | +- ...
> > > ...
> >
> > But in this case, 'admin' isn't a submodule/subproject contained by
> > KDE, right? It's contained in three different submodules/subprojects:
> > kdelibs, kdebase and kdenetwork.
>
> Notice how kdelibs, kdebase and kdenetwork are both submodule and
> supermodule: They host the submodule admin and are hosted by KDE.
>
Exactly my point ;-)
> (If I missed the point, then it's because I didn't follow the
> discussion; I jumped in because I noticed the symlink proposal by
> chance.)
In this case, I would assume that e.g. kdelibs contain a submodule
entry for path admin in its index, accompanied by a .gitmodules file
saying that the path admin is mapped to this or that submodule. I
would not expect the KDE 'supersuperproject' to know about admin at
all, neither in its index nor .gitmodules.
--
larsh
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Johannes Sixt @ 2007-06-12 11:03 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Frank Lichtenheld, Junio C Hamano, skimo, git
In-Reply-To: <8c5c35580706120352y24e53a10sf339147b22f1286e@mail.gmail.com>
Lars Hjemli wrote:
>
> (readded the gitlist)
>
> On 6/12/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> > Lars Hjemli wrote:
> > > Multiple checkout paths for a single submodule will bring havoc on
> > > this plan, so I need to ask: what is the use-case for multiple
> > > checkout paths?
> >
> > A use-case is the admin directory in the KDE repository. It has:
> >
> > KDE (superproject)
> > +- kdelibs (subproject)
> > | +- admin (subproject)
> > | +- subdir1
> > | +- ...
> > +- kdebase (subproject)
> > | +- admin (subproject)
> > | +- subdir2
> > | +- ...
> > +- kdenetwork (subproject)
> > | +- admin (subproject)
> > | +- subdir3
> > | +- ...
> > ...
>
> But in this case, 'admin' isn't a submodule/subproject contained by
> KDE, right? It's contained in three different submodules/subprojects:
> kdelibs, kdebase and kdenetwork.
Notice how kdelibs, kdebase and kdenetwork are both submodule and
supermodule: They host the submodule admin and are hosted by KDE.
(If I missed the point, then it's because I didn't follow the
discussion; I jumped in because I noticed the symlink proposal by
chance.)
-- Hannes
^ permalink raw reply
* [PATCH 5/5] Add gitmodules(5)
From: Lars Hjemli @ 2007-06-12 10:54 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <8c5c35580706120352y24e53a10sf339147b22f1286e@mail.gmail.com>
(readded the gitlist)
On 6/12/07, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Lars Hjemli wrote:
> > Multiple checkout paths for a single submodule will bring havoc on
> > this plan, so I need to ask: what is the use-case for multiple
> > checkout paths?
>
> A use-case is the admin directory in the KDE repository. It has:
>
> KDE (superproject)
> +- kdelibs (subproject)
> | +- admin (subproject)
> | +- subdir1
> | +- ...
> +- kdebase (subproject)
> | +- admin (subproject)
> | +- subdir2
> | +- ...
> +- kdenetwork (subproject)
> | +- admin (subproject)
> | +- subdir3
> | +- ...
> ...
But in this case, 'admin' isn't a submodule/subproject contained by
KDE, right? It's contained in three different submodules/subprojects:
kdelibs, kdebase and kdenetwork.
--
larsh
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Johannes Sixt @ 2007-06-12 10:48 UTC (permalink / raw)
To: git; +Cc: Frank Lichtenheld, Junio C Hamano, skimo
In-Reply-To: <8c5c35580706120127p649227d8gc706cb8b364d02b9@mail.gmail.com>
Lars Hjemli wrote:
> Multiple checkout paths for a single submodule will bring havoc on
> this plan, so I need to ask: what is the use-case for multiple
> checkout paths?
A use-case is the admin directory in the KDE repository. It has:
KDE (superproject)
+- kdelibs (subproject)
| +- admin (subproject)
| +- subdir1
| +- ...
+- kdebase (subproject)
| +- admin (subproject)
| +- subdir2
| +- ...
+- kdenetwork (subproject)
| +- admin (subproject)
| +- subdir3
| +- ...
...
-- Hannes
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Johannes Sixt @ 2007-06-12 10:34 UTC (permalink / raw)
To: git
In-Reply-To: <8c5c35580706120127p649227d8gc706cb8b364d02b9@mail.gmail.com>
Lars Hjemli wrote:
>
> On 6/12/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> > On Tue, Jun 12, 2007 at 09:05:21AM +0200, Lars Hjemli wrote:
> > > +submodule.<name>.path::
> > > + Defines the path, relative to the top-level directory of the git
> >
> > Your previous patch had "_a_ path" instead of "_the_ path".
> > I prefer the former since it allows a module to be checkoud out
> > at multiple locations.
>
> This is somewhat intentional. I want to move the submodule repos into
> .git/submodules/$name/ (with working dir) and symlink this directory
> when 'checking out' the submodule. This would be a simple solution for
> the following problems:
> -keeping submodule modifications between checkouts
> -having submodules within submodules
It has already been said in the past that symlinks are *bad*. The don't
exist on Windows (MinGW). Please do not use symlinks for such central
concepts.
-- Hannes
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Lars Hjemli @ 2007-06-12 10:28 UTC (permalink / raw)
To: skimo; +Cc: Frank Lichtenheld, Junio C Hamano, git
In-Reply-To: <20070612094931.GR955MdfPADPa@greensroom.kotnet.org>
On 6/12/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Tue, Jun 12, 2007 at 10:27:00AM +0200, Lars Hjemli wrote:
> > On 6/12/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> > >Your previous patch had "_a_ path" instead of "_the_ path".
> > >I prefer the former since it allows a module to be checkoud out
> > >at multiple locations.
> >
> > This is somewhat intentional. I want to move the submodule repos into
> > .git/submodules/$name/ (with working dir) and symlink this directory
>
> I had that in my patch series, but I got a complaint that symlinks
> don't work on Windows.
Yeah, I didn't consider windows.
>
> > Multiple checkout paths for a single submodule will bring havoc on
> > this plan, so I need to ask: what is the use-case for multiple
> > checkout paths?
>
> The case where you need two different versions of the same
> submodule in one (presumably big) project.
Let me rephrase: why would anyone need to checkout two different
versions of the same submodule simultaneously inside a single
superproject?
--
larsh
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Lars Hjemli @ 2007-06-12 10:23 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: skimo, Frank Lichtenheld, Junio C Hamano, git
In-Reply-To: <200706121145.22699.Josef.Weidendorfer@gmx.de>
On 6/12/07, Josef Weidendorfer <Josef.Weidendorfer@gmx.de> wrote:
> On Tuesday 12 June 2007, Lars Hjemli wrote:
> > This is somewhat intentional. I want to move the submodule repos into
> > .git/submodules/$name/ (with working dir) and symlink this directory
> > when 'checking out' the submodule. This would be a simple solution for
> > the following problems:
> > -keeping submodule modifications between checkouts
> > -having submodules within submodules
>
> Interesting idea.
>
> How does this work
> (1) if the submodule checkout changes with the supermodule checkout?
> You still would have to store the modifications somewhere.
If you're thinking about the detached HEAD: yeah, that's a problem. My
initial plan (with later modifications) was something like this:
[path "lib1"]
submodule=lib
branch=stable
[path "lib2"]
submodule=lib
branch=bleeding
[submodule "lib"]
url=git://example.com/lib.git
$ git-submodule init
git-config submodule.lib.url git://example.com/lib.git
$ git-submodule update
git-clone --bare git://example.com/lib.git .git/submodules/lib.git
git-clone -l -s -n .git/submodules/lib.git lib1
(cd lib1 && git-checkout $sha1)
git-clone -l -s -n .git/submodules/lib.git lib2
(cd lib2 && git-checkout $sha2)
git-submodule push:
(cd lib1 && git-push origin $branch1)
(cd lib2 && git-push origin $branch2)
I thought I could avoid 'git-submodule push' by using symlinks, but
you're right. It will not work. Back to the drawing board (again...)
> (2) on platforms which do not allow symlinks
Ok, bad idea.
>
> A workaround for problem (1) would be to create multiple checkouts of the
> same submodule if modified, e.g. in .git/submodule/$name/$sha1 .
And the $sha1 would be the sha1 found in the index? I don't think this
would work either. If two branches in the superproject checkout the
same submodule sha1, you could possibly want to keep different changes
in the submodule depending on which branch of the superproject is
checked out.
I guess the user will have to both commit and push submodule changes
before switching branches etc. But that might not be too bad, at least
for the initial submodule support.
>
> Allowing people to work like that is nice, but it should not be forced.
> It would also be nice to allow the user to specify another place where
> submodule checkouts are to be stored, e.g. when multiple supermodules
> share the same submodule.
True. Maybe submodule.<name>.repopath in .git/config? (If not
specified, default to .git/submodules/<name>.git)
--
larsh
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Sven Verdoolaege @ 2007-06-12 9:49 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Frank Lichtenheld, Junio C Hamano, git
In-Reply-To: <8c5c35580706120127p649227d8gc706cb8b364d02b9@mail.gmail.com>
On Tue, Jun 12, 2007 at 10:27:00AM +0200, Lars Hjemli wrote:
> On 6/12/07, Sven Verdoolaege <skimo@kotnet.org> wrote:
> >Your previous patch had "_a_ path" instead of "_the_ path".
> >I prefer the former since it allows a module to be checkoud out
> >at multiple locations.
>
> This is somewhat intentional. I want to move the submodule repos into
> .git/submodules/$name/ (with working dir) and symlink this directory
I had that in my patch series, but I got a complaint that symlinks
don't work on Windows.
> Multiple checkout paths for a single submodule will bring havoc on
> this plan, so I need to ask: what is the use-case for multiple
> checkout paths?
The case where you need two different versions of the same
submodule in one (presumably big) project.
(Not that I need that just now.)
skimo
^ permalink raw reply
* Re: [PATCH 5/5] Add gitmodules(5)
From: Josef Weidendorfer @ 2007-06-12 9:45 UTC (permalink / raw)
To: Lars Hjemli; +Cc: skimo, Frank Lichtenheld, Junio C Hamano, git
In-Reply-To: <8c5c35580706120127p649227d8gc706cb8b364d02b9@mail.gmail.com>
On Tuesday 12 June 2007, Lars Hjemli wrote:
> This is somewhat intentional. I want to move the submodule repos into
> .git/submodules/$name/ (with working dir) and symlink this directory
> when 'checking out' the submodule. This would be a simple solution for
> the following problems:
> -keeping submodule modifications between checkouts
> -having submodules within submodules
Interesting idea.
How does this work
(1) if the submodule checkout changes with the supermodule checkout?
You still would have to store the modifications somewhere.
(2) on platforms which do not allow symlinks
A workaround for problem (1) would be to create multiple checkouts of the
same submodule if modified, e.g. in .git/submodule/$name/$sha1 .
Allowing people to work like that is nice, but it should not be forced.
It would also be nice to allow the user to specify another place where
submodule checkouts are to be stored, e.g. when multiple supermodules
share the same submodule.
Josef
>
> Multiple checkout paths for a single submodule will bring havoc on
> this plan, so I need to ask: what is the use-case for multiple
> checkout paths?
>
^ permalink raw reply
* Re: git-svn set-tree bug
From: Joakim Tjernlund @ 2007-06-12 9:21 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, Steven Grimm, git
In-Reply-To: <20070612083910.GA28369@muzzle>
On Tue, 2007-06-12 at 01:39 -0700, Eric Wong wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > Eric Wong <normalperson@yhbt.net> writes:
> >
> > > If dcommit detects a merge commit when doing rev-list When looking at
> > > commit objects, is it safe to assume that the first parent is always the
> > > "mainline" and that parents after it are the ones to merge from?
> > >
> > > So if I saw:
> > >
> > > commit $X
> > > parent $A
> > > parent $B
> > >
> > > I'd basically do:
> > > reset --hard $A
> > > merge --squash $B
> > >
> > > And resulting in $C which would have the same tree as $X,
> > > then, when dcommit-ting, $D would be created with two parents:
> > > $D~1 (svn), $B (git), but not $A
> >
> > I am not sure what you mean by "mainline", but I assume that you
> > mean "SVN is the main and we are tracking it while taking
> > advantage of more efficient and merge-capable git in guerrilla
> > fashion". Because the tip of the current branch is what the
> > user is pushing back to SVN via dcommit, I would say it is safe
> > to assume that the first parent of such a merge is the line that
> > corresponds to the SVN branch you are keeping track.
>
> Yes, "mainline" meaning the history that would be committed to SVN if
> history were linear.
>
> I've gotten the following patch working for Joakim's second test script
> (with dcommit before merge). However, without the dcommit before merge
> in the first test script, git-svn has trouble figuring out which history
> to follow. It'll take more work to figure out what to do in this
> situation, and how to deal with more complex history...
>
> Subject: git-svn: Allow dcommit to handle certain single-parent merge commits
>
> This only works if a merge is the first commit to be committed
> in a chain of commits.
[SNIP patch]
Nice!, now I get to keep the merge between the "svn" and the "merge" branch. The parents are swapped though:
before last dcommit:
Parent: b31cef1d3c6655441854ea8649359f0fc27f3e87 (friend)
Parent: ed95b698c2e3336d387fed3763b213b3b90ebf4e (add some stuff)
Branch: svn
Follows:
Precedes:
Merge branch 'merge' into svn
after dcommit:
Parent: ed95b698c2e3336d387fed3763b213b3b90ebf4e (add some stuff)
Parent: b31cef1d3c6655441854ea8649359f0fc27f3e87 (friend)
Branches: svn, remotes/trunk
Follows:
Precedes:
Merge branch 'merge' into svn
git-svn-id: file:////usr/local/src/tst-git-svn/mysvnrepo/trunk@3 1585b9b0-b13 ....
Will this also work for merging stuff from latest u-boot?
I am doing dev. on my own u-boot branch and from time to time I want
to merge in the latest from WD tree, then dcommit that merge. Later
I want repeat that cycle.
I have a SVN repo with my changes in it and I have grafted the beginning of
that tree into a clone of WDs tree.
Jocke
^ permalink raw reply
* Re: Problem with a push
From: Andy Parkins @ 2007-06-12 9:07 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, plexq
In-Reply-To: <alpine.LFD.0.98.0706111556160.14121@woody.linux-foundation.org>
On Tuesday 2007 June 12, Linus Torvalds wrote:
> Ok, pushing out remote branches is a bit odd in the first place. As in
> "you probably shouldn't do that". The "remote" branches are really local
> to each repo, and updating them by pushing is really quite suspect.
I agree its odd, but is it really true that one (I) shouldn't be doing it?
Can I tell you what I'm doing, and check that it's not crazy...
I have my laptop and my desktop computer; I use both for development. I've
set them so that they are symmetric...
laptop:.git/config
[remote "desktop"]
url = ssh://blah blah blah
fetch = refs/heads/*:refs/remotes/desktop/*
push = refs/heads/*:refs/remotes/laptop/*
desktop:.git/config
[remote "laptop"]
url = ssh://blah blah blah
fetch = refs/heads/*:refs/remotes/laptop/*
push = refs/heads/*:refs/remotes/desktop/*
This is very handy, as git-push on one does the same as git-fetch on the
other. Have I made a glaring mistake by pushing to a remote ref?
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [RFC] git integrated bugtracking
From: Guilhem Bonnefille @ 2007-06-12 8:54 UTC (permalink / raw)
To: Git List
In-Reply-To: <1181587892.3380.37.camel@ld0161-tx32>
Hi,
This subject is quite interesting. I read that one of the main
expected goal of integrating SCM and BT is to help release manager in
its task.
In my point of view, we have to keep in mind that it's not because a
commit solved a problem, that all the following commits will always
solve the problem. Development ALWAYS suffers regression. The really
way to avoid this is to have an organisation of code that allows
automatic tests. So it needs something greater than the SCM: you have
to be organized for this.
One interesting project to have a look for is aegis (
http://aegis.sourceforge.net/ ).
It proposes a sort of SCM, that integrates process to ensure quality
of code. One of them is that the /SCM/ will control the non regression
before commiting.
I hope these informations will help defining how we can design a
system that integrates SCM and BT in a distributed manner.
--
Guilhem BONNEFILLE
-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com
-=- mailto:guilhem.bonnefille@gmail.com
-=- http://nathguil.free.fr/
^ 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