* Re: [RFC] Third round of support for cloning submodules
From: Martin Waitz @ 2007-05-20 22:55 UTC (permalink / raw)
To: Alex Riesen; +Cc: skimo, Junio C Hamano, git
In-Reply-To: <20070520222410.GF25462@steel.home>
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
hoi :)
On Mon, May 21, 2007 at 12:24:10AM +0200, Alex Riesen wrote:
> But it is not a merge. It is a checkout. Being another operation it
> may even be disallow merges of subprojects. Just plainly tell user
> that this checkout is not possible because there are changes in
> subprojects and in the pointer to this subproject in the upper level
> superproject, and that the user should think about committing in
> subproject first.
If the user did commit and then you do a supermodule checkout -m you
will get a merge.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Martin Waitz @ 2007-05-20 22:52 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano
In-Reply-To: <11796842882917-git-send-email-skimo@liacs.nl>
[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]
hoi :)
On Sun, May 20, 2007 at 08:04:33PM +0200, skimo@liacs.nl wrote:
> This patch series implements a mechanism for cloning submodules.
> Each submodule is specified by a 'submodule.<submodule>.url'
> configuration option, e.g.,
>
> bash-3.00$ ./git-config --remote=http://www.liacs.nl/~sverdool/isa.git --get-regexp 'submodule\..*\.url'
> submodule.cloog.url /home/sverdool/public_html/cloog.git
> submodule.cloog.url http://www.liacs.nl/~sverdool/cloog.git
I really think we should try to find one standard method to
automatically find the right parent repository for a submodule,
based on the supermodules parent repository.
So e.g. that the submodule repository should stay in the same directory
or in some special subdirectory of the supermodule or even in the
same object store.
Then we can add a configuration layor on top, but there should always
be a sane default.
Things we have to think about:
* we have to cope with moving / disappearing repositories.
* we should support bare repositories even for superprojects.
This can be done either by including the submodule objects in
the bare repository directly or by linking them (e.g. with your
config implementation)
* we have to keep old submodules around forever,
at least when we want to be able to recover old versions.
Of course this is not required for all working copies as people
only want to have a subset of needed modules.
But for central synchronization repositories (probably the bare ones)
this is really important.
* If you remove the whole working directory I don't want to loose any
data which is already committed, including submodules.
That leads to submodules which store their objects within the
supermodule .git directory, which would automatically obsolete the
need to specify explicit submodule URLs. But I'm not quite sure
on how to really do this, despite having experimented a bit with it
(my module3 branch should still contain some brainstorming and code).
So back to your code: I don't like absolute URLs in the cloneable part
of the repository. We should try to stay with relative ones which
can stay the same everywhere.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 2/3] t9400: Add some more cvs update tests
From: Frank Lichtenheld @ 2007-05-20 22:31 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Martin Langhoff, Frank Lichtenheld
In-Reply-To: <11797003182642-git-send-email-frank@lichtenheld.de>
Add some cvs update tests that include various merge
situations. Also add a basic test for update -C
since it fits so well in there.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
t/t9400-git-cvsserver-server.sh | 69 +++++++++++++++++++++++++++++++++++++++
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index 1b63435..e42943e 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -192,4 +192,73 @@ test_expect_success 'cvs update (re-add deleted file)' \
test "$(echo $(grep testfile1 CVS/Entries|cut -d/ -f2,3,5))" = "testfile1/1.4/" &&
diff -q testfile1 ../testfile1'
+cd "$WORKDIR"
+test_expect_success 'cvs update (merge)' \
+ 'echo Line 0 >expected &&
+ for i in 1 2 3 4 5 6 7
+ do
+ echo Line $i >>merge
+ echo Line $i >>expected
+ done &&
+ echo Line 8 >>expected &&
+ git add merge &&
+ git commit -q -m "Merge test (pre-merge)" &&
+ git push gitcvs.git >/dev/null &&
+ cd cvswork &&
+ GIT_CONFIG="$git_config" cvs -Q update &&
+ test "$(echo $(grep merge CVS/Entries|cut -d/ -f2,3,5))" = "merge/1.1/" &&
+ diff -q merge ../merge &&
+ ( echo Line 0; cat merge ) >merge.tmp &&
+ mv merge.tmp merge &&
+ cd "$WORKDIR" &&
+ echo Line 8 >>merge &&
+ git add merge &&
+ git commit -q -m "Merge test (merge)" &&
+ git push gitcvs.git >/dev/null &&
+ cd cvswork &&
+ GIT_CONFIG="$git_config" cvs -Q update &&
+ diff -q merge ../expected'
+
+cd "$WORKDIR"
+
+cat >expected.C <<EOF
+<<<<<<< merge.mine
+Line 0
+=======
+LINE 0
+>>>>>>> merge.3
+EOF
+
+for i in 1 2 3 4 5 6 7 8
+do
+ echo Line $i >>expected.C
+done
+
+test_expect_success 'cvs update (conflict merge)' \
+ '( echo LINE 0; cat merge ) >merge.tmp &&
+ mv merge.tmp merge &&
+ git add merge &&
+ git commit -q -m "Merge test (conflict)" &&
+ git push gitcvs.git >/dev/null &&
+ cd cvswork &&
+ GIT_CONFIG="$git_config" cvs -Q update &&
+ diff -q merge ../expected.C'
+
+cd "$WORKDIR"
+test_expect_success 'cvs update (-C)' \
+ 'cd cvswork &&
+ GIT_CONFIG="$git_config" cvs -Q update -C &&
+ diff -q merge ../merge'
+
+cd "$WORKDIR"
+test_expect_success 'cvs update (merge no-op)' \
+ 'echo Line 9 >>merge &&
+ cp merge cvswork/merge &&
+ git add merge &&
+ git commit -q -m "Merge test (no-op)" &&
+ git push gitcvs.git >/dev/null &&
+ cd cvswork &&
+ GIT_CONFIG="$git_config" cvs -Q update &&
+ diff -q merge ../merge'
+
test_done
--
1.5.2-rc3.GIT
^ permalink raw reply related
* [PATCH 3/3] t9400: Add some basic pserver tests
From: Frank Lichtenheld @ 2007-05-20 22:31 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Martin Langhoff, Frank Lichtenheld
In-Reply-To: <11797003191512-git-send-email-frank@lichtenheld.de>
While we can easily test the cvs <-> git-cvsserver
communication with :fork: and git-cvsserver server
there are some pserver specifics we should test, too.
Currently this are two tests of the pserver authentication.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
t/t9400-git-cvsserver-server.sh | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index e42943e..7f9c6e2 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -47,6 +47,40 @@ test_expect_success 'basic checkout' \
'GIT_CONFIG="$git_config" cvs -Q co -d cvswork master &&
test "$(echo $(grep -v ^D cvswork/CVS/Entries|cut -d/ -f2,3,5))" = "empty/1.1/"'
+#------------------------
+# PSERVER AUTHENTICATION
+#------------------------
+
+cat >request-anonymous <<EOF
+BEGIN AUTH REQUEST
+$SERVERDIR
+anonymous
+
+END AUTH REQUEST
+EOF
+
+cat >request-git <<EOF
+BEGIN AUTH REQUEST
+$SERVERDIR
+git
+
+END AUTH REQUEST
+EOF
+
+test_expect_success 'pserver authentication' \
+ 'cat request-anonymous | git-cvsserver pserver >log 2>&1 &&
+ tail -n1 log | grep -q "^I LOVE YOU$"'
+
+test_expect_success 'pserver authentication failure (non-anonymous user)' \
+ 'if cat request-git | git-cvsserver pserver >log 2>&1
+ then
+ false
+ else
+ true
+ fi &&
+ tail -n1 log | grep -q "^I HATE YOU$"'
+
+
#--------------
# CONFIG TESTS
#--------------
--
1.5.2-rc3.GIT
^ permalink raw reply related
* [PATCH 1/3] t9400: Add test cases for config file handling
From: Frank Lichtenheld @ 2007-05-20 22:31 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Martin Langhoff, Frank Lichtenheld
Add a few test cases for the config file parsing
done by git-cvsserver.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
t/t9400-git-cvsserver-server.sh | 69 +++++++++++++++++++++++++++++++++++++++
1 files changed, 69 insertions(+), 0 deletions(-)
Note that this currently has one failing test. This will need
to be fixed in git-cvsserver though.
diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
index d406a88..1b63435 100755
--- a/t/t9400-git-cvsserver-server.sh
+++ b/t/t9400-git-cvsserver-server.sh
@@ -47,6 +47,75 @@ test_expect_success 'basic checkout' \
'GIT_CONFIG="$git_config" cvs -Q co -d cvswork master &&
test "$(echo $(grep -v ^D cvswork/CVS/Entries|cut -d/ -f2,3,5))" = "empty/1.1/"'
+#--------------
+# CONFIG TESTS
+#--------------
+
+test_expect_success 'gitcvs.enabled = false' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled false &&
+ if GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1
+ then
+ echo unexpected cvs success
+ false
+ else
+ true
+ fi &&
+ cat cvs.log | grep -q "GITCVS emulation disabled" &&
+ test ! -d cvswork2'
+
+rm -fr cvswork2
+test_expect_success 'gitcvs.ext.enabled = true' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled false &&
+ GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
+ diff -q cvswork cvswork2'
+
+rm -fr cvswork2
+test_expect_success 'gitcvs.ext.enabled = false' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled false &&
+ GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
+ if GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1
+ then
+ echo unexpected cvs success
+ false
+ else
+ true
+ fi &&
+ cat cvs.log | grep -q "GITCVS emulation disabled" &&
+ test ! -d cvswork2'
+
+rm -fr cvswork2
+test_expect_success 'gitcvs.dbname' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
+ GIT_DIR="$SERVERDIR" git config gitcvs.dbname %Ggitcvs.%a.%m.sqlite &&
+ GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
+ diff -q cvswork cvswork2 &&
+ test -f "$SERVERDIR/gitcvs.ext.master.sqlite" &&
+ cmp "$SERVERDIR/gitcvs.master.sqlite" "$SERVERDIR/gitcvs.ext.master.sqlite"'
+
+rm -fr cvswork2
+test_expect_success 'gitcvs.ext.dbname' \
+ 'GIT_DIR="$SERVERDIR" git config --bool gitcvs.ext.enabled true &&
+ GIT_DIR="$SERVERDIR" git config gitcvs.ext.dbname %Ggitcvs1.%a.%m.sqlite &&
+ GIT_DIR="$SERVERDIR" git config gitcvs.dbname %Ggitcvs2.%a.%m.sqlite &&
+ GIT_CONFIG="$git_config" cvs -Q co -d cvswork2 master >cvs.log 2>&1 &&
+ diff -q cvswork cvswork2 &&
+ test -f "$SERVERDIR/gitcvs1.ext.master.sqlite" &&
+ test ! -f "$SERVERDIR/gitcvs2.ext.master.sqlite" &&
+ cmp "$SERVERDIR/gitcvs.master.sqlite" "$SERVERDIR/gitcvs1.ext.master.sqlite"'
+
+
+#------------
+# CVS UPDATE
+#------------
+
+rm -fr "$SERVERDIR"
+cd "$WORKDIR" &&
+git clone -q --local --bare "$WORKDIR/.git" "$SERVERDIR" >/dev/null 2>&1 &&
+GIT_DIR="$SERVERDIR" git config --bool gitcvs.enabled true &&
+GIT_DIR="$SERVERDIR" git config --bool gitcvs.logfile "$SERVERDIR/gitcvs.log" ||
+exit 1
+
test_expect_success 'cvs update (create new file)' \
'echo testfile1 >testfile1 &&
git add testfile1 &&
--
1.5.2-rc3.GIT
^ permalink raw reply related
* Re: [RFC] Third round of support for cloning submodules
From: Alex Riesen @ 2007-05-20 22:26 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git
In-Reply-To: <20070520214732.GC942MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege, Sun, May 20, 2007 23:47:32 +0200:
>
> How would _you_ specify which subprojects to checkout ?
>
Aren't the ones which already have .git in them are kind of specified?
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Alex Riesen @ 2007-05-20 22:24 UTC (permalink / raw)
To: Martin Waitz; +Cc: skimo, Junio C Hamano, git
In-Reply-To: <20070520214026.GL5412@admingilde.org>
Martin Waitz, Sun, May 20, 2007 23:40:26 +0200:
> > > > - What would we do when the subproject working tree is not
> > > > clean?
> > >
> > > I was planning on adding a --dry-run to git-checkout.
> > > The superproject would run this in each subproject before
> > > doing the actual checkout of the superproject.
> >
> > Why not do exactly what we do now? Pass "-m" down to it, if it was
> > given to the top-level git-checkout.
>
> sounds good.
> With submodules we have to consider one extra level of merging.
> -m in the supermodule also means that an automatic merge of the
> dirlink entry should be done. Which would execute git-merge in the
> submodule. And merging in a dirty tree is a challenge of its own.
But it is not a merge. It is a checkout. Being another operation it
may even be disallow merges of subprojects. Just plainly tell user
that this checkout is not possible because there are changes in
subprojects and in the pointer to this subproject in the upper level
superproject, and that the user should think about committing in
subproject first.
> So if local changes conflict with the checkout we should just error out.
On account of it being too complex. Always a good reason.
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Martin Waitz @ 2007-05-20 22:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: skimo, git
In-Reply-To: <7vhcq7l3ar.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]
hoi :)
On Sun, May 20, 2007 at 12:10:04PM -0700, Junio C Hamano wrote:
> The more important issue I think is at what point in the
> superproject operation does a recursive checkout in a subproject
> should happen, and how we should do the checkout.
we should really move from our big clone thing to a simple
fetch+checkout wrapper.
And then integrate all the submodule logic into the actual checkout
step where it belongs.
We might also want to expand fetch to also fetch newly reachable
submodule commits (of a configurable subset of modules).
> Issues I can think of offhand are (no way exhaustive):
>
> - Do we checkout a branch? if so which one?
At least no off-the-shelf branch from the upstream repository of
the submodule.
To use some special branch allows to use normal git methods in
the submodule, too -- but I haven't been able to convince everybody
yet... So let's get it to a state where people can play with it
in real projects and let's see.
> - Do we detach HEAD if the commit named by the superproject
> tree is not at the tip of the current branch of subproject?
> do we detach always even if the commit is at the tip?
We must not mess with random upstream branches of the submodule
just because they happen to reference the same tip.
That would be too confusing.
Either use one special branch or detach.
> - What would we do when the subproject working tree is not
> clean?
The same as with normal files:
error out if something is changed which conflicts with the requested
update.
When we have a special managed-by-supermodule branch and the submodule
has another branch currently checked out we can entirely ignore this
issue.
This really allows the user to deliberately keep one module in an
unclean state.
> - How can a user decide which subproject to descend into and
> which subproject to ignore, and how does git remember the
> earlier decision made by the user without asking the same
> again, and how does a user express "now I want to also track
> that subproject I've ignored so far" and "now I am not
> interested in following that subproject anymore"?
I'd simply use explicit checkout of a submodule and removal of
the submodule to be a fine way to express the user's wish.
Of course we also need some way to say: populate everything
below "src/target" or similar. But that is independent from
the rest.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git-config: Correct asciidoc documentation for --int/--bool
From: Frank Lichtenheld @ 2007-05-20 22:12 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Frank Lichtenheld
In-Reply-To: <11796991783280-git-send-email-frank@lichtenheld.de>
The asciidoc documentation seemed to indicate that type specifiers
are honoured on writing operations which they aren't. Make this
more clear.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
Documentation/git-config.txt | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 280ef20..827a499 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -9,15 +9,15 @@ git-config - Get and set repository or global options
SYNOPSIS
--------
[verse]
-'git-config' [--system | --global] [type] name [value [value_regex]]
-'git-config' [--system | --global] [type] --add name value
-'git-config' [--system | --global] [type] --replace-all name [value [value_regex]]
+'git-config' [--system | --global] name [value [value_regex]]
+'git-config' [--system | --global] --add name value
+'git-config' [--system | --global] --replace-all name [value [value_regex]]
'git-config' [--system | --global] [type] --get name [value_regex]
'git-config' [--system | --global] [type] --get-all name [value_regex]
-'git-config' [--system | --global] [type] --unset name [value_regex]
-'git-config' [--system | --global] [type] --unset-all name [value_regex]
-'git-config' [--system | --global] [type] --rename-section old_name new_name
-'git-config' [--system | --global] [type] --remove-section name
+'git-config' [--system | --global] --unset name [value_regex]
+'git-config' [--system | --global] --unset-all name [value_regex]
+'git-config' [--system | --global] --rename-section old_name new_name
+'git-config' [--system | --global] --remove-section name
'git-config' [--system | --global] -l | --list
DESCRIPTION
@@ -36,7 +36,8 @@ prepend a single exclamation mark in front (see EXAMPLES).
The type specifier can be either '--int' or '--bool', which will make
'git-config' ensure that the variable(s) are of the given type and
convert the value to the canonical form (simple decimal number for int,
-a "true" or "false" string for bool). If no type specifier is passed,
+a "true" or "false" string for bool). Type specifiers currently only
+take effect for reading operations. If no type specifier is passed,
no checks or transformations are performed on the value.
This command will fail if:
--
1.5.2-rc3.GIT
^ permalink raw reply related
* [PATCH] t1300: Add tests for git-config --bool --get
From: Frank Lichtenheld @ 2007-05-20 22:12 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Frank Lichtenheld
Noticed that there were only tests for --int, but not
for --bool. Add some.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
t/t1300-repo-config.sh | 34 ++++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index a1d777c..3f3fd2d 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -436,6 +436,40 @@ test_expect_success numbers '
test z1048576 = "z$m"
'
+cat > expect << EOF
+true
+false
+true
+false
+true
+false
+true
+false
+EOF
+
+test_expect_success bool '
+
+ git-config bool.true1 01 &&
+ git-config bool.true2 -1 &&
+ git-config bool.true3 YeS &&
+ git-config bool.true4 true &&
+ git-config bool.false1 000 &&
+ git-config bool.false2 "" &&
+ git-config bool.false3 nO &&
+ git-config bool.false4 FALSE &&
+ rm -f result &&
+ for i in 1 2 3 4
+ do
+ git-config --bool --get bool.true$i >>result
+ git-config --bool --get bool.false$i >>result
+ done &&
+ cmp expect result'
+
+test_expect_failure 'invalid bool' '
+
+ git-config bool.nobool foobar &&
+ git-config --bool --get bool.nobool'
+
rm .git/config
git-config quote.leading " test"
--
1.5.2-rc3.GIT
^ permalink raw reply related
* Re: RFC: submodule terminology
From: Johan Herland @ 2007-05-20 22:06 UTC (permalink / raw)
To: git; +Cc: Martin Waitz
In-Reply-To: <20070520214417.GM5412@admingilde.org>
On Sunday 20 May 2007, Martin Waitz wrote:
> hoi :)
>
> I think we should agree to one name for what currently is named
> submodule / subproject / dirlink / gitlink.
>
> Or use one name for the low-level plumbing (have a tree entry
> which points to another commit): dirlink or gitlink and another
> one for the high-level UI think: submodule or subproject.
> But then we should use those names consequently.
>
> Oppinions?
For the high-level concept, "subproject" seems to me the best
alternative. I think it is much better than "submodule" at
describing that the subproject is a stand-alone project/repo in
itself.
As for the low-level concept, I personally prefer "gitlink", but
I don't have any strong feelings. The fact that "gitlink" seems
to already be used in the code (as in resolve_gitlink_ref() etc.),
coupled with "dirlink" being somewhat ambiguous (i.e. may also be
interpreted as "(sym)link to directory") makes the case for me.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH 02/15] git-config: add --remote option for reading config from remote repo
From: Frank Lichtenheld @ 2007-05-20 22:03 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano
In-Reply-To: <20070520194448.GW942MdfPADPa@greensroom.kotnet.org>
On Sun, May 20, 2007 at 09:44:48PM +0200, Sven Verdoolaege wrote:
> On Sun, May 20, 2007 at 08:11:55PM +0200, Frank Lichtenheld wrote:
> > On Sun, May 20, 2007 at 08:04:35PM +0200, skimo@liacs.nl wrote:
> > > From: Sven Verdoolaege <skimo@kotnet.org>
> > >
> > > Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
> > > ---
> > > Documentation/git-config.txt | 33 +++++++++++++++++++++---------
> >
> > All my old suggestions and corrections for the documentation
> > part still apply... should I repeat them?
>
> I did the [scope] thing, but it seems I inadvertedly threw it out.
> I guess I'll have to do it again.
>
> Was there anything else?
You list --remote for all variants while it is not really supported for
them. Although this problem probably implicetly goes away if you use
scope and later explain what that means.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH 09/15] entry.c: optionally checkout submodules
From: Sven Verdoolaege @ 2007-05-20 21:51 UTC (permalink / raw)
To: Martin Waitz; +Cc: git, Junio C Hamano
In-Reply-To: <20070520211850.GJ5412@admingilde.org>
On Sun, May 20, 2007 at 11:18:50PM +0200, Martin Waitz wrote:
> hoi :)
>
> have you seen my patch to checkout submodules?
Not yet. I'll look for it in the morning.
skimo
^ permalink raw reply
* Re: [PATCH 06/15] git-read-tree: take --submodules option
From: Sven Verdoolaege @ 2007-05-20 21:50 UTC (permalink / raw)
To: Martin Waitz; +Cc: git, Junio C Hamano
In-Reply-To: <20070520212404.GK5412@admingilde.org>
On Sun, May 20, 2007 at 11:24:04PM +0200, Martin Waitz wrote:
> hoi :)
>
> what really is the motivation to suppress submodule checkout at this
> level? I can see that we need some per-submodule option for checkout,
> but this should influence the actual checkout process and not
> read-tree.
It's only used with update is set.
> At least we really want to always update the index correctly and a
> read-tree --no-submodules which updates the index for submodules but
> doesn't go into existing submodules just feels wrong.
It doesn't do that.
skimo
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-20 21:47 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20070520212432.GE25462@steel.home>
On Sun, May 20, 2007 at 11:24:32PM +0200, Alex Riesen wrote:
> Sven Verdoolaege, Sun, May 20, 2007 23:09:54 +0200:
> > On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
> > > Sven Verdoolaege, Sun, May 20, 2007 21:59:30 +0200:
> > > > > I am very worried about this big red switch that says "all
> > > > > subprojects to be cloned and checked out, or nothing". I think
> > > > > this would not work well with projects that truly need
> > > > > superproject support (i.e. very large ones, where most people
> > > > > would not want to clone and check out every single subproject).
> > > >
> > > > It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
> > > > Since the subcloning only happens at checkout, you could set these
> > > > before doing a checkout.
> > >
> > > And set them back after doing the checkout?
> >
> > What do you mean? Why would you set them back?
>
> Why should I set them before doing a checkout?
>
> > I guess I'm missing something.
>
> "checkout" is an operation which is done often. It never had to be
> configured before.
There is going to have to be *some* way of selecting which
subprojects you want to check out. A config option that you
have to set only once (or not at all if you are happy with
the default) seems to be the easiest way. You can have git-gui
set them for you if you want.
How would _you_ specify which subprojects to checkout ?
> > Well... the subproject as a whole is independent of the superproject,
> > but the checkout in the superproject is not entirely independent.
> >
>
> Junio was talking about branch in subproject, wasn't he?
That's a local thing.
skimo
^ permalink raw reply
* RFC: submodule terminology
From: Martin Waitz @ 2007-05-20 21:44 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 394 bytes --]
hoi :)
I think we should agree to one name for what currently is named
submodule / subproject / dirlink / gitlink.
Or use one name for the low-level plumbing (have a tree entry
which points to another commit): dirlink or gitlink and another
one for the high-level UI think: submodule or subproject.
But then we should use those names consequently.
Oppinions?
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Third round of support for cloning submodules
From: Martin Waitz @ 2007-05-20 21:40 UTC (permalink / raw)
To: Alex Riesen; +Cc: skimo, Junio C Hamano, git
In-Reply-To: <20070520205444.GC25462@steel.home>
[-- Attachment #1: Type: text/plain, Size: 1399 bytes --]
hoi :)
On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
> Me too. I actually believe it is the only way to do it. How can you
> checkout a subproject to something else (to what a branch may point)
> and to what the tree of superproject has? On the other side (in
> subproject) - why are you, the superproject, allowed to screw the
> references of the subproject?! It is independent, isn't it?!
right. except when you have some managed-by-superproject branch
which is known to be special ;-)
After all the submodule checkout is independent from its parent
repository, too -- so you don't screw anything *g*.
> > > - What would we do when the subproject working tree is not
> > > clean?
> >
> > I was planning on adding a --dry-run to git-checkout.
> > The superproject would run this in each subproject before
> > doing the actual checkout of the superproject.
>
> Why not do exactly what we do now? Pass "-m" down to it, if it was
> given to the top-level git-checkout.
sounds good.
With submodules we have to consider one extra level of merging.
-m in the supermodule also means that an automatic merge of the
dirlink entry should be done. Which would execute git-merge in the
submodule. And merging in a dirty tree is a challenge of its own.
So if local changes conflict with the checkout we should just error out.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] Remove whitespace breakage from *.c files
From: Junio C Hamano @ 2007-05-20 21:36 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <4650222D.4070707@gmail.com>
Your MUA seem to have munged all your patches in this series;
and the breakage seems also to be in the "let apply eat the new
trailing blank lines" patch.
^ permalink raw reply
* [PATCH 2/2] Don't use / as separatar since it is common i branch names
From: Robin Rosenberg @ 2007-05-20 21:24 UTC (permalink / raw)
To: catalin.marinas; +Cc: ydirson, git
In-Reply-To: <20070520204627.GR19253@nan92-1-81-57-214-146.fbx.proxad.net>
Don't use / as separatar since it is common i branch names
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh
index f4817a1..5927e67 100755
--- a/contrib/stgbashprompt.sh
+++ b/contrib/stgbashprompt.sh
@@ -9,8 +9,8 @@ if [ "$PS1" ]; then
ref=$(git-symbolic-ref HEAD 2> /dev/null) || return
br=${ref#refs/heads/}
top=$(tail -n 1 $git_dir/patches/$br/applied 2>/dev/null) \
- && top="/$top";
- echo "[$br$top]"
+ top=${top:-(none)}
+ echo "[$top@$br]"
}
PS1='\u@\h:$(__prompt_git)\W\$ '
fi
^ permalink raw reply related
* Re: [RFC] Third round of support for cloning submodules
From: Alex Riesen @ 2007-05-20 21:24 UTC (permalink / raw)
To: skimo; +Cc: Junio C Hamano, git
In-Reply-To: <20070520210954.GB942MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege, Sun, May 20, 2007 23:09:54 +0200:
> On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
> > Sven Verdoolaege, Sun, May 20, 2007 21:59:30 +0200:
> > > > I am very worried about this big red switch that says "all
> > > > subprojects to be cloned and checked out, or nothing". I think
> > > > this would not work well with projects that truly need
> > > > superproject support (i.e. very large ones, where most people
> > > > would not want to clone and check out every single subproject).
> > >
> > > It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
> > > Since the subcloning only happens at checkout, you could set these
> > > before doing a checkout.
> >
> > And set them back after doing the checkout?
>
> What do you mean? Why would you set them back?
Why should I set them before doing a checkout?
> I guess I'm missing something.
"checkout" is an operation which is done often. It never had to be
configured before.
> > Me too. I actually believe it is the only way to do it. How can you
> > checkout a subproject to something else (to what a branch may point)
> > and to what the tree of superproject has? On the other side (in
> > subproject) - why are you, the superproject, allowed to screw the
> > references of the subproject?! It is independent, isn't it?!
>
> Well... the subproject as a whole is independent of the superproject,
> but the checkout in the superproject is not entirely independent.
>
Junio was talking about branch in subproject, wasn't he?
> > > > - What would we do when the subproject working tree is not
> > > > clean?
> > >
> > > I was planning on adding a --dry-run to git-checkout.
> > > The superproject would run this in each subproject before
> > > doing the actual checkout of the superproject.
> >
> > Why not do exactly what we do now? Pass "-m" down to it, if it was
> > given to the top-level git-checkout.
>
> We want to be sure that all (selected) subprojects can be updated before
> updating any, no?
>
I guess passing "-m" to git-checkout _is_ an explicit permission from
the operator to perform a merge. Besides, it's visible: merge prints
something, user sees the "-m" in command history (or in script code).
Calling git-checkout twice even if we don't have to... it is kind of
ugly. Still need some dry-run this for normal case (checkout can be
modified to do this by default, I think).
^ permalink raw reply
* Re: [PATCH 06/15] git-read-tree: take --submodules option
From: Martin Waitz @ 2007-05-20 21:24 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano
In-Reply-To: <11796842893584-git-send-email-skimo@liacs.nl>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
hoi :)
what really is the motivation to suppress submodule checkout at this
level? I can see that we need some per-submodule option for checkout,
but this should influence the actual checkout process and not
read-tree.
At least we really want to always update the index correctly and a
read-tree --no-submodules which updates the index for submodules but
doesn't go into existing submodules just feels wrong.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 1/2] Update the bash prompt from 'applied' instead of the obsolete 'current'
From: Robin Rosenberg @ 2007-05-20 21:22 UTC (permalink / raw)
To: catalin.marinas; +Cc: ydirson, git
In-Reply-To: <20070520204627.GR19253@nan92-1-81-57-214-146.fbx.proxad.net>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 1520 bytes --]
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
söndag 20 maj 2007 skrev Yann Dirson:
> Note that "tail -1" gives a warning with newer versions, "tail -n 1"
> should be the proper call.
My man page doesn't mention -N being deprecated, but ok since -n 1 seems
to work here too.
> Also I'm not sure it is a good way to look at "applied" file, since
> Karl IIRC has plans to change this. Better call "stg top" and not
> touch that again :)
Calling stg is too slow to be be used here. I that command in my first draft
for this function and people complained (see the thread named "Bash snippet
to show branch and patch in bash prompt"). It takes ~ 0.15s on here which is
very noticable, barely below my pain threshold.
We'll update the prompt when and if Karl breaks this.
It'd probably drain my battery too :/
-- robin
contrib/stgbashprompt.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/stgbashprompt.sh b/contrib/stgbashprompt.sh
index 16bb39b..f4817a1 100755
--- a/contrib/stgbashprompt.sh
+++ b/contrib/stgbashprompt.sh
@@ -8,8 +8,8 @@ if [ "$PS1" ]; then
git_dir=$(git-rev-parse --git-dir 2> /dev/null) || return
ref=$(git-symbolic-ref HEAD 2> /dev/null) || return
br=${ref#refs/heads/}
- top=$(cat $git_dir/patches/$br/current 2>/dev/null) \
- && top="/$top"
+ top=$(tail -n 1 $git_dir/patches/$br/applied 2>/dev/null) \
+ && top="/$top";
echo "[$br$top]"
}
PS1='\u@\h:$(__prompt_git)\W\$ '
^ permalink raw reply related
* Re: [PATCH 09/15] entry.c: optionally checkout submodules
From: Martin Waitz @ 2007-05-20 21:18 UTC (permalink / raw)
To: skimo; +Cc: git, Junio C Hamano
In-Reply-To: <11796842892490-git-send-email-skimo@liacs.nl>
[-- Attachment #1: Type: text/plain, Size: 284 bytes --]
hoi :)
have you seen my patch to checkout submodules?
The submodule checkout should really check that the requested commit
is really available and have some other path for creating submodules
which are not currently checked out / able to be checked out.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] git-pack-objects: cache small deltas between big objects
From: Martin Koegler @ 2007-05-20 21:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Koegler
Creating deltas between big blobs is a CPU and memory intensive task.
In the writing phase, all (not reused) deltas are redone.
This patch adds support for caching deltas from the deltifing phase, so
that that the writing phase is faster.
The caching is limited to small deltas to avoid increasing memory usage very much.
The implemented limit is (memory needed to create the delta)/1024.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
---
builtin-pack-objects.c | 35 +++++++++++++++++++++++++----------
1 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index d165f10..13429d0 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -35,6 +35,7 @@ struct object_entry {
struct object_entry *delta_sibling; /* other deltified objects who
* uses the same base as me
*/
+ void *delta_data; /* cached delta (uncompressed) */
unsigned long delta_size; /* delta data size (uncompressed) */
enum object_type type;
enum object_type in_pack_type; /* could be delta */
@@ -380,17 +381,24 @@ static unsigned long write_object(struct sha1file *f,
*/
if (!to_reuse) {
- buf = read_sha1_file(entry->sha1, &type, &size);
- if (!buf)
- die("unable to read %s", sha1_to_hex(entry->sha1));
- if (size != entry->size)
- die("object %s size inconsistency (%lu vs %lu)",
- sha1_to_hex(entry->sha1), size, entry->size);
- if (entry->delta) {
- buf = delta_against(buf, size, entry);
+ if (entry->delta_data) {
+ buf = entry->delta_data;
size = entry->delta_size;
obj_type = (allow_ofs_delta && entry->delta->offset) ?
- OBJ_OFS_DELTA : OBJ_REF_DELTA;
+ OBJ_OFS_DELTA : OBJ_REF_DELTA;
+ } else {
+ buf = read_sha1_file(entry->sha1, &type, &size);
+ if (!buf)
+ die("unable to read %s", sha1_to_hex(entry->sha1));
+ if (size != entry->size)
+ die("object %s size inconsistency (%lu vs %lu)",
+ sha1_to_hex(entry->sha1), size, entry->size);
+ if (entry->delta) {
+ buf = delta_against(buf, size, entry);
+ size = entry->delta_size;
+ obj_type = (allow_ofs_delta && entry->delta->offset) ?
+ OBJ_OFS_DELTA : OBJ_REF_DELTA;
+ }
}
/*
* The object header is a byte of 'type' followed by zero or
@@ -1294,10 +1302,17 @@ static int try_delta(struct unpacked *trg, struct unpacked *src,
if (!delta_buf)
return 0;
+ if (trg_entry->delta_data)
+ free (trg_entry->delta_data);
+ trg_entry->delta_data = 0;
trg_entry->delta = src_entry;
trg_entry->delta_size = delta_size;
trg_entry->depth = src_entry->depth + 1;
- free(delta_buf);
+ /* cache delta, if objects are large enough compared to delta size */
+ if ((src_size >> 20) + (trg_size >> 21) > (delta_size >> 10))
+ trg_entry->delta_data = delta_buf;
+ else
+ free(delta_buf);
return 1;
}
--
1.5.2.rc3.802.g4b4b7
^ permalink raw reply related
* Re: [RFC] Third round of support for cloning submodules
From: Sven Verdoolaege @ 2007-05-20 21:09 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git
In-Reply-To: <20070520205444.GC25462@steel.home>
On Sun, May 20, 2007 at 10:54:44PM +0200, Alex Riesen wrote:
> Sven Verdoolaege, Sun, May 20, 2007 21:59:30 +0200:
> > > I am very worried about this big red switch that says "all
> > > subprojects to be cloned and checked out, or nothing". I think
> > > this would not work well with projects that truly need
> > > superproject support (i.e. very large ones, where most people
> > > would not want to clone and check out every single subproject).
> >
> > It's pretty easy to add a "submodule.*.skip" or "submodule.*.ignore".
> > Since the subcloning only happens at checkout, you could set these
> > before doing a checkout.
>
> And set them back after doing the checkout?
What do you mean? Why would you set them back?
I guess I'm missing something.
> Me too. I actually believe it is the only way to do it. How can you
> checkout a subproject to something else (to what a branch may point)
> and to what the tree of superproject has? On the other side (in
> subproject) - why are you, the superproject, allowed to screw the
> references of the subproject?! It is independent, isn't it?!
Well... the subproject as a whole is independent of the superproject,
but the checkout in the superproject is not entirely independent.
> > > - What would we do when the subproject working tree is not
> > > clean?
> >
> > I was planning on adding a --dry-run to git-checkout.
> > The superproject would run this in each subproject before
> > doing the actual checkout of the superproject.
>
> Why not do exactly what we do now? Pass "-m" down to it, if it was
> given to the top-level git-checkout.
We want to be sure that all (selected) subprojects can be updated before
updating any, no?
skimo
^ 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