* [PATCH] Fix minor grammatical typos in the git-gc man page
From: Theodore Ts'o @ 2007-05-31 23:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Theodore Ts'o
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
---
Documentation/git-gc.txt | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-gc.txt b/Documentation/git-gc.txt
index 4ac839f..c7742ca 100644
--- a/Documentation/git-gc.txt
+++ b/Documentation/git-gc.txt
@@ -37,10 +37,10 @@ OPTIONS
--aggressive::
Usually 'git-gc' runs very quickly while providing good disk
- space utilization and performance. This option will cause
- git-gc to more aggressive optimize the repository at the expense
+ space utilization and performance. This option will cause
+ git-gc to more aggressively optimize the repository at the expense
of taking much more time. The effects of this optimization are
- persistent, so this option only needs to be sporadically; every
+ persistent, so this option only needs to be used occasionally; every
few hundred changesets or so.
Configuration
--
1.5.2.136.g322bc
^ permalink raw reply related
* Re: [PATCH] Let .git/config specify the url for submodules
From: Junio C Hamano @ 2007-05-31 23:43 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <8c5c35580705301717h4e9b127fr21ee19764f8ec288@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> On 5/28/07, Lars Hjemli <hjemli@gmail.com> wrote:
>> This changes git-submodule in a few ways:
>
> Please don't apply the "Let .git/config specify the url for
> submodules" patch, I'm having second thoughts ;-)
>
> Your design outline in
> http://article.gmane.org/gmane.comp.version-control.git/48287 is
> obviously superior, and I'd like to take a stab at it with something
> like this:
>
> 1. 'git-submodule init' saves submodule name and suggested url from
> .gitmodules into .git/config (submodule.$name.url)
>
> 2. 'git-submodule update' keeps the work tree updated for submodules
> with five separate (and optional) operations:
> a) git-clone --bare $url .git/submodules/$name.git
> b) git-clone -l -s .git/submodules/$name.git $path
> c) cd .git/submodules/$name.git && git-fetch
> d) cd $path && git-fetch
> e) cd $path && git-checkout $sha1
>
> 3) 'git-submodule push' runs something like 'cd $path && git push
> origin $branch', where $branch is found in .gitmodules
> (path.$path.branch).
>
> A remaining issue is how to detect if step 2b is necessary if a
> submodule is already checked out at the submodule path, but I guess
> remote.origin.url in the checked out submodule would be the thing to
> peek into.
>
> Also, step 2c/2d should obviously only be performed if the requested
> sha1 isn't available, which should be trivial to detect with
> 'git-cat-file -e'.
>
> Could this turn out to be an acceptable solution?
Sounds sane to me, although I have to admit that I cannot really
claim that I have thought things through in that strawman you
quoted.
^ permalink raw reply
* Re: [PATCH] Introduce git version --list-features for porcelain use
From: Junio C Hamano @ 2007-05-31 23:46 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Alex Riesen, Johannes Schindelin
In-Reply-To: <20070531002030.GA15714@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> As a porcelain author I'm finding it difficult to keep track of
> what features I can use in git-gui. Newer versions of Git have
> newer capabilities but they don't always immediately get newer
> version numbers that I can easily test for.
>
> This is a simple plumbing option that lets a porcelain ask the
> plumbing for its capabilities, at which point the porcelain can
> work around anything missing, or recommend to the user that they
> upgrade their plumbing layer.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
>
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > On Wed, 30 May 2007, Alex Riesen wrote:
> >
> > > git-version --features?
> >
> > Melikes.
>
> Good?
Hmmm. I am not sure if you want list-features in the features
list -- how are you going to test for it?
Also I still do not understand why you want redirect-stderr.
Are you writing for a shell-less environment?
^ permalink raw reply
* Re: git-p4import.py robustness changes
From: Junio C Hamano @ 2007-05-31 23:53 UTC (permalink / raw)
To: Scott Lamb; +Cc: git
In-Reply-To: <4ACE2ABC-8D73-4097-87AC-F3B27EDA97DE@slamb.org>
Scott Lamb <slamb@slamb.org> writes:
> There's a logfile option, but that's a poor excuse for no error
> handling. I'd like to fix it. A couple questions, though:
Good to have somebody who has access to p4.
> First, is it acceptable to switch from os.popen to the subprocess
> module? I ask because the latter was only introduced with Python 2.4
> on. The subprocess module does work with earlier versions of Python
> (definitely 2.3) and is GPL-compatible, so maybe it could be thrown
> into the distribution if desired.
We actually did ship with our own copy after clearing the
licensing situation with Python people, although we removed it
when it lost the last script that used it. I do not think
resurrecting it is a problem.
> Second, this crowd seems to want sequences of tiny patches. How does
> this sound?
>
> * patch 1 - use subprocess to make git_command.git() and p4_command.p4
> () throw properly-typed exceptions on error, fix caller exception
> handling to match.
>
> * patch 2 - remove the use of the shell and pipelines (fix some
> escaping problems).
>
> * patch 3 - use lists instead of space separation for the commandline
> arguments (fix more escaping problems).
>
> * patch 4 - allow grabbing partial history (make my error go away).
Actually, my preference is to have a "patch 0" before all of the
above, that demotes git-p4import to contrib/ hierarchy. Having
no access to p4 managed repositories (nor much inclination to
get one), I can never test nor maintain it myself, so it is just
crazy for me to be the maintainer for it.
But I do read Python and speak it passably -- the above 4 step
outline sounds sane to me.
^ permalink raw reply
* Re: [PATCH] fix repack with --max-pack-size
From: Dana How @ 2007-06-01 0:01 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, danahow
In-Reply-To: <alpine.LFD.0.99.0705302114430.11491@xanadu.home>
On 5/30/07, Nicolas Pitre <nico@cam.org> wrote:
> Two issues here:
>
> 1) git-repack -a --max-pack-size=10 on the GIT repo dies pretty quick.
> There is a lot of confusion about deltas that were suposed to be
> reused from another pack but that get stored undeltified due to pack
> limit and object size doesn't match entry->size anymore. This test
> is not really worth the complexity for determining when it is valid
> so get rid of it.
This is very real. A smaller fix would have been the hunk
@@ -408,7 +407,7 @@ static unsigned long write_object(struct sha1file *f,
> buf = read_sha1_file(entry->sha1, &type, &size);
> if (!buf)
> die("unable to read %s", sha1_to_hex(entry->sha1));
>- if (size != entry->size)
>+ if (size != entry->size && type == obj_type)
> die("object %s size inconsistency (%lu vs %lu)",
> sha1_to_hex(entry->sha1), size, entry->size);
> if (usable_delta) {
from the max-blob-size patch that hasn't converged yet.
Both pack splitting and blob-size limiting could cause a delta base
not to appear in the pack containing a delta using the base.
Then you get the size mismatch Nicolas discussed
when the real object must be used and its size doesn't match
the delta sized stored in the size field.
I first saw this with max-blob-size, but only realized recently
that it also applied to max-pack-size. Sorry I didn't post a patch;
we are swamped at the moment.
ACK [but I didn't review (2)].
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* Re: [PATCH] Make the installation targets a little less chatty
From: Junio C Hamano @ 2007-06-01 0:12 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070531222313.GA12204@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> by default. V=1 works as usual.
>
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
>
> Now it quite quiet. I tried top show every installed file, but it
> wasn't an improvement at all so I decided to just show what's being
> done.
I agree that the long single line that installs the commands to $(bindir)
may be somewhat annoying.
Cleaning up compilation step is one thing; by tidying up the
output it makes compiler warnings stand out.
But I do not like playing games like this in general in
installation rule. An excerpt from your patch:
> + @echo installing programs
> + $(QUIET)$(foreach p,$(BUILT_INS), rm -f ...
This would not even let you see what got installed. At least,
less verbose compilation step we have these days lets you see
what is being built. I certainly would not object if the output
would look like this, though:
CC builtin-cat-file.o
...
GEN git-add--interactive
...
LINK git-http-push
...
BUILTIN git-add
...
MKDIR -p /usr/local/bin
INSTALL git-foo
INSTALL git-bar
...
INSTALL templates/description
INSTALL templates/hooks/post-update
...
^ permalink raw reply
* Re: Fetch from remote A, push to remote B
From: Martin Langhoff @ 2007-06-01 0:37 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <46a038f90705310028y6f180214s9018f8af5e71d0ed@mail.gmail.com>
On 5/31/07, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> # on cron do
> GIT_DIR=bla-transfer.git git-fetch git+ssh://host-a/bla.git
> GIT_DIR=bla-transfer.git git-push --all git+ssh://host-b/bla.git
Actually -- this doesn't quite work - the fetch grabs the new objects
properly but doesn't update the local heads on a bare repo.
cheers,
m
^ permalink raw reply
* Re: [ANNOUNCE] tig 0.7
From: Greg KH @ 2007-06-01 1:29 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Steven Grimm, git
In-Reply-To: <20070531215508.GB9260@diku.dk>
On Thu, May 31, 2007 at 11:55:08PM +0200, Jonas Fonseca wrote:
> Steven Grimm <koreth@midwinter.com> wrote Thu, May 31, 2007:
> > This doesn't build on OS X out of the box, FYI. It needs the following
> > tweaks (which break the build on Linux, so I'm not suggesting you apply
> > this -- looks like you might need a configure script or at least some
> > conditionals in the Makefile.) The change to tig.c cleans up a compiler
> > warning, but it does build fine without that change.
>
> I am aware of this and your suggestion is already in the TODO file.
> However, for 0.7 I ended up needing the new status view feature more
> than working on fixing that.
Which is fricken nice to have, thank you very much for adding this, I'm
already using it.
greg "welded to the command line" k-h
^ permalink raw reply
* Re: Fetch from remote A, push to remote B
From: Martin Langhoff @ 2007-06-01 1:52 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <46a038f90705311737u7e9a118v9b9865f63a4c6951@mail.gmail.com>
On 6/1/07, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 5/31/07, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> > # on cron do
> > GIT_DIR=bla-transfer.git git-fetch git+ssh://host-a/bla.git
> > GIT_DIR=bla-transfer.git git-push --all git+ssh://host-b/bla.git
>
> Actually -- this doesn't quite work - the fetch grabs the new objects
> properly but doesn't update the local heads on a bare repo.
Should this work?
GIT_DIR=bla-transfer.git git-fetch git+ssh://host-a/bla.git
+refs/heads/*:refs/heads/*
Earlier discussions about mirroring tools (and Pasky's git-mirror)
finished with this being the recommended technique. Only - it does on
me with
* refusing to create funny ref 'heads/*' locally
cheers,
martin
^ permalink raw reply
* Re: [PATCH] Make the installation target of git-gui a little less chatty
From: Shawn O. Pearce @ 2007-06-01 3:02 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <20070531222527.GB12204@steel.home>
Alex Riesen <raa.lkml@gmail.com> wrote:
> Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
> ---
I have the exact same reaction as Junio had to the same change in
git.git... I'll apply it if you resend according to his guidelines.
> The patch is hand-tuned to start in git-gui, so that it can be applied
> in git-gui repo.
Hand-tuning the patch isn't necessary, just making the change its
own patch is all that is required. Git has these nifty flags for
git-am like -p2 and -3 that make editing filenames in the patch
completely unnecessary. ;-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Introduce git version --list-features for porcelain use
From: Shawn O. Pearce @ 2007-06-01 3:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alex Riesen, Johannes Schindelin
In-Reply-To: <7vk5uo1rpr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > As a porcelain author I'm finding it difficult to keep track of
> > what features I can use in git-gui. Newer versions of Git have
> > newer capabilities but they don't always immediately get newer
> > version numbers that I can easily test for.
> >
> > This is a simple plumbing option that lets a porcelain ask the
> > plumbing for its capabilities, at which point the porcelain can
> > work around anything missing, or recommend to the user that they
> > upgrade their plumbing layer.
> >
> > Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> > ---
> >
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >
> > > On Wed, 30 May 2007, Alex Riesen wrote:
> > >
> > > > git-version --features?
> > >
> > > Melikes.
> >
> > Good?
>
> Hmmm. I am not sure if you want list-features in the features
> list -- how are you going to test for it?
Yes, its a recursive definition. But its also a feature that won't
ever be removed; if list-features is here then the list-features
feature is also here. Makes the test in t0000 a lot easier, and
its not a huge deal to say "yes, the feature that i implement is
here too". ;-)
> Also I still do not understand why you want redirect-stderr.
> Are you writing for a shell-less environment?
The redirect-stderr thing grew out of the MinGW port camp.
Apparently they cannot use (or its hard to use) an important little
tool called `cat` over there.
Why cat? Tcl is so horribly broken that to get data for both stdout
and stderr through a pipe I have to do something sick like:
git fetch 2>&1 | cat
because in Tcl its actually:
set rdr [open "| git fetch |& cat" r]
The |& means 2>&1| in normal shell. But that means I have to have
a process after it to receive the data. Normally that's cat.
But MinGW doesn't have cat. (Nor do they have dog, but neither
does Linux...). So I need a way to redirect output.
Dscho's patch to git.c to give me `git --redirect-stderr` is quite
simple, and makes my life in git-gui easier. I can just require
that to use git-gui on MinGW you must have the 'redirect-stderr'
feature supported in your plumbing layer. On non-MinGW systems I
can fallback to "&| cat" if its not supported.
--
Shawn.
^ permalink raw reply
* Re: Fetch from remote A, push to remote B
From: Martin Langhoff @ 2007-06-01 3:51 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <46a038f90705311852n136a2bfbwa943a65a43257a6e@mail.gmail.com>
To finish off the soliloquy... effective mirroring with git
git-clone --bare git://host/repo.git mirror.git
git --git-dir=mirror.git config remote.origin.url git://host/repo.git
git --git-dir=mirror.git config remote.origin.fetch
'+refs/heads/*:refs/heads/*'
and now, on cron...
git --git-dir=mirror.git fetch -u
git --git-dir=mirror.git remote prune origin
(Thanks to Shawn Pearce for helping me figure out why it wasn't working for me!)
cheers
martin
^ permalink raw reply
* Re: [PATCH] Add basic test-script for git-submodule
From: Junio C Hamano @ 2007-06-01 3:54 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <8c5c35580705292348q74281f7eu15b3b61f45b2c6f5@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> Would you prefer a patch on top of this version of the test-script or
> on top of the later patch which uses .git/config to store submodule
> url?
As you said you will be redoing submodule + .git/config stuff in
your other message, I would expect a replacement (i.e. not on
top of this) patch for tests to check the existing submodule
features. If you want to finish the submodule + .git/config one
first and then test script on top to test both existing featues
and submodule + .git/config features, that is fine as well.
Your choice.
One important point is to treat the test-script take #1 as
"already rejected", and not basing further patches on it.
^ permalink raw reply
* Re: [PATCH] Introduce git version --list-features for porcelain use
From: Junio C Hamano @ 2007-06-01 3:57 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Alex Riesen, Johannes Schindelin
In-Reply-To: <20070601030959.GY7044@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Why cat? Tcl is so horribly broken that to get data for both stdout
> and stderr through a pipe I have to do something sick like:
>
> git fetch 2>&1 | cat
>
> because in Tcl its actually:
>
> set rdr [open "| git fetch |& cat" r]
>
> The |& means 2>&1| in normal shell. But that means I have to have
> a process after it to receive the data. Normally that's cat.
> But MinGW doesn't have cat. (Nor do they have dog, but neither
> does Linux...). So I need a way to redirect output.
Wait a minute. Who interprets |& in the above? Isn't it a
shell?
That's why I asked if you are writing for shell-less
environment. If you are _not_, can't you do something like this
instead?
set rdr [open "| sh -c 'git fetch 2>&1'" r]
that is, instead of running a command called "git", you invoke a
command called "sh" with two parameters, the second parameter
being a tad long string that happens to have three letter
sequence '2>&1' in it.
^ permalink raw reply
* Re: [PATCH] Introduce git version --list-features for porcelain use
From: Shawn O. Pearce @ 2007-06-01 4:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alex Riesen, Johannes Schindelin
In-Reply-To: <7vvee8z5q9.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > Why cat? Tcl is so horribly broken that to get data for both stdout
> > and stderr through a pipe I have to do something sick like:
> >
> > git fetch 2>&1 | cat
> >
> > because in Tcl its actually:
> >
> > set rdr [open "| git fetch |& cat" r]
> >
> > The |& means 2>&1| in normal shell. But that means I have to have
> > a process after it to receive the data. Normally that's cat.
> > But MinGW doesn't have cat. (Nor do they have dog, but neither
> > does Linux...). So I need a way to redirect output.
>
> Wait a minute. Who interprets |& in the above? Isn't it a
> shell?
My understanding was it is Tcl itself. My $SHELL doesn't understand
it:
$ echo hi |& cat
-bash: syntax error near unexpected token `&'
> That's why I asked if you are writing for shell-less
> environment. If you are _not_, can't you do something like this
> instead?
Ideally with MinGW we wouldn't need a UNIX shell to get things
working in git-gui. But we have to have one for git-merge for
example, as git-gui doesn't have a builtin Grand Unified Merge
Driver. Also for git-fetch, which is one of the prime uses of this
cat redirect thing. ;-)
> set rdr [open "| sh -c 'git fetch 2>&1'" r]
Yeah, I'm already doing that sh -c trick for a different reason in
another context. I may have to do just that here too.
--
Shawn.
^ permalink raw reply
* [PATCH] catch asciidoc failures
From: Scott Lamb @ 2007-06-01 6:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Scott Lamb
If pipefail is available (GNU bash >= 3.00), fail when asciidoc returns
error rather than possibly later during XSLT.
Signed-off-by: Scott Lamb <slamb@slamb.org>
---
This is my first git patch, so please let me know if I got the procedure
wrong.
Documentation/Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index 3f92783..48c245c 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -111,6 +111,7 @@ clean:
%.html : %.txt
rm -f $@+ $@
+ set -o pipefail 2>/dev/null; \
$(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -o - $< | \
sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' >$@+
@@ -121,6 +122,7 @@ clean:
%.xml : %.txt
rm -f $@+ $@
+ set -o pipefail 2>/dev/null; \
$(ASCIIDOC) -b docbook -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -o - $< | \
sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' >$@+
--
1.5.2
^ permalink raw reply related
* Re: [PATCH] Add basic test-script for git-submodule
From: Lars Hjemli @ 2007-06-01 7:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vzm3kz5w9.fsf@assigned-by-dhcp.cox.net>
This test tries to verify basic sanity of git-submodule, i.e. that it is
able to clone and update a submodule repository, that its status output is
sane, and that it barfs when the submodule path is occupied during init.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
On 6/1/07, Junio C Hamano <junkio@cox.net> wrote:
> As you said you will be redoing submodule + .git/config stuff in
> your other message, I would expect a replacement (i.e. not on
> top of this) patch for tests to check the existing submodule
> features. If you want to finish the submodule + .git/config one
> first and then test script on top to test both existing featues
> and submodule + .git/config features, that is fine as well.
> Your choice.
My continuous quest for self-discipline left me no choice but to attempt
the creation of a proper testscript for the existing features ;-)
t/t7400-submodule-basic.sh | 143 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 143 insertions(+), 0 deletions(-)
create mode 100755 t/t7400-submodule-basic.sh
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
new file mode 100755
index 0000000..a8beee2
--- /dev/null
+++ b/t/t7400-submodule-basic.sh
@@ -0,0 +1,143 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Lars Hjemli
+#
+
+test_description='Basic porcelain support for submodules
+
+This test tries to verify basic sanity of the init, update and status
+subcommands of git-submodule.
+'
+
+. ./test-lib.sh
+
+#
+# Test setup:
+# -create a repository in directory lib
+# -add a couple of files
+# -add directory lib to 'superproject', this creates a DIRLINK entry
+# -add a couple of regular files to enable testing of submodule filtering
+# -mv lib subrepo
+# -add an entry to .gitmodules for path 'lib'
+#
+test_expect_success 'Prepare submodule testing' '
+ mkdir lib &&
+ cd lib &&
+ git-init &&
+ echo a >a &&
+ git-add a &&
+ git-commit -m "submodule commit 1" &&
+ git-tag -a -m "rev-1" rev-1 &&
+ rev1=$(git-rev-parse HEAD) &&
+ if test -z "$rev1"
+ then
+ echo "[OOPS] submodule git-rev-parse returned nothing"
+ false
+ fi &&
+ cd .. &&
+ echo a >a &&
+ echo z >z &&
+ git-add a lib z &&
+ git-commit -m "super commit 1" &&
+ mv lib .subrepo &&
+ GIT_CONFIG=.gitmodules git-config module.lib.url ./.subrepo
+'
+
+test_expect_success 'status should only print one line' '
+ lines=$(git-submodule status | wc -l)
+ test "$lines" = "1"
+'
+
+test_expect_success 'status should initially be "missing"' '
+ git-submodule status | grep "^-$rev1"
+'
+
+test_expect_success 'init should fail when path is used by a file' '
+ echo "hello" >lib &&
+ if git-submodule init
+ then
+ echo "[OOPS] init should have failed"
+ false
+ elif test -f lib && test "$(cat lib)" != "hello"
+ then
+ echo "[OOPS] init failed but lib file was molested"
+ false
+ else
+ rm lib
+ fi
+'
+
+test_expect_success 'init should fail when path is used by a nonempty directory' '
+ mkdir lib &&
+ echo "hello" >lib/a &&
+ if git-submodule init
+ then
+ echo "[OOPS] init should have failed"
+ false
+ elif test "$(cat lib/a)" != "hello"
+ then
+ echo "[OOPS] init failed but lib/a was molested"
+ false
+ else
+ rm lib/a
+ fi
+'
+
+test_expect_success 'init should work when path is an empty dir' '
+ rm -rf lib &&
+ mkdir lib &&
+ git-submodule init &&
+ head=$(cd lib && git-rev-parse HEAD) &&
+ if test -z "$head"
+ then
+ echo "[OOPS] Failed to obtain submodule head"
+ false
+ elif test "$head" != "$rev1"
+ then
+ echo "[OOPS] Submodule head is $head but should have been $rev1"
+ false
+ fi
+'
+
+test_expect_success 'status should be "up-to-date" after init' '
+ git-submodule status | grep "^ $rev1"
+'
+
+test_expect_success 'status should be "modified" after submodule commit' '
+ cd lib &&
+ echo b >b &&
+ git-add b &&
+ git-commit -m "submodule commit 2" &&
+ rev2=$(git-rev-parse HEAD) &&
+ cd .. &&
+ if test -z "$rev2"
+ then
+ echo "[OOPS] submodule git-rev-parse returned nothing"
+ false
+ fi &&
+ git-submodule status | grep "^\+$rev2"
+'
+
+test_expect_success 'the --cached sha1 should be rev1' '
+ git-submodule --cached status | grep "^\+$rev1"
+'
+
+test_expect_success 'update should checkout rev1' '
+ git-submodule update &&
+ head=$(cd lib && git-rev-parse HEAD) &&
+ if test -z "$head"
+ then
+ echo "[OOPS] submodule git-rev-parse returned nothing"
+ false
+ elif test "$head" != "$rev1"
+ then
+ echo "[OOPS] init did not checkout correct head"
+ false
+ fi
+'
+
+test_expect_success 'status should be "up-to-date" after update' '
+ git-submodule status | grep "^ $rev1"
+'
+
+test_done
--
1.5.2.839.ga3b1-dirty
^ permalink raw reply related
* Re: [PATCH] Introduce git version --list-features for porcelain use
From: Johannes Sixt @ 2007-06-01 7:13 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <20070601030959.GY7044@spearce.org>
"Shawn O. Pearce" wrote:
> Why cat? Tcl is so horribly broken that to get data for both stdout
> and stderr through a pipe I have to do something sick like:
>
> git fetch 2>&1 | cat
>
> because in Tcl its actually:
>
> set rdr [open "| git fetch |& cat" r]
>
> The |& means 2>&1| in normal shell. But that means I have to have
> a process after it to receive the data. Normally that's cat.
> But MinGW doesn't have cat. (Nor do they have dog, but neither
> does Linux...). So I need a way to redirect output.
Are you planning for the future? Currently, the MinGW port works only
with MSYS installed and $MSYS/bin in your PATH because the shell scripts
need an assorted set of POSIX tools. MSYS does ship 'cat', of course.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Make the installation targets a little less chatty
From: Alex Riesen @ 2007-06-01 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pls1qjv.fsf@assigned-by-dhcp.cox.net>
On 6/1/07, Junio C Hamano <junkio@cox.net> wrote:
> This would not even let you see what got installed. At least,
> less verbose compilation step we have these days lets you see
> what is being built. I certainly would not object if the output
> would look like this, though:
>
> MKDIR -p /usr/local/bin
> INSTALL git-foo
> INSTALL git-bar
> ...
> INSTALL templates/description
> INSTALL templates/hooks/post-update
> ...
As I said, it did _not_ look like an improvement (I actually
did that first). There is just too much information to be printed.
I'll send that first patch, with every program on its own line.
^ permalink raw reply
* Re: [PATCH] Make the installation target of git-gui a little less chatty
From: Alex Riesen @ 2007-06-01 7:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Junio C Hamano
In-Reply-To: <20070601030257.GX7044@spearce.org>
On 6/1/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> > The patch is hand-tuned to start in git-gui, so that it can be applied
> > in git-gui repo.
>
> Hand-tuning the patch isn't necessary, just making the change its
> own patch is all that is required. Git has these nifty flags for
Good to know
^ permalink raw reply
* Re: Breaking up repositories
From: Andy Parkins @ 2007-06-01 7:45 UTC (permalink / raw)
To: git; +Cc: Josh Triplett, Jason Sewall, Jamey Sharp
In-Reply-To: <465EEF96.6050307@freedesktop.org>
On Thursday 2007 May 31, Josh Triplett wrote:
> We really need to fix some things in git-split and get it merged into git.
Obviously it's Junio's call, but can I suggest that getting it in the git tree
(presumably under contrib/) should not be dependent on fixing
whatever "things" you are worrying about? Waiting until it's perfect before
submitting it. As Voltaire said (I think), "better is the enemy of good".
Speaking from my own personal viewpoint, while I'm not a huge contributor to
git, I do fix the odd buglet here and there - and here's the rub - I only do
it to those files that are in the git tree.
While git-split is being maintained separately, I would argue that there are
less eyes on it. Get it in, regardless of state, at the very least it will
mean that git-split's development will be tracked as publicly as git.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Add basic test-script for git-submodule
From: Johannes Sixt @ 2007-06-01 7:56 UTC (permalink / raw)
To: git
In-Reply-To: <op.ts8d71b89pspc6@localhost>
Lars Hjemli wrote:
> +test_expect_success 'status should only print one line' '
> + lines=$(git-submodule status | wc -l)
&& is missing.
> + test "$lines" = "1"
Please don't put output of wc in quotes because some versions of wc emit
padding:
test $lines = 1
(without the quotes around 1 - like in other test scripts).
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add basic test-script for git-submodule
From: Lars Hjemli @ 2007-06-01 8:13 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Johannes Schindelin, git@vger.kernel.org
In-Reply-To: <465FD11C.6B1D5172@eudaptics.com>
This test tries to verify basic sanity of git-submodule, i.e. that it is
able to clone and update a submodule repository, that its status output is
sane, and that it barfs when the submodule path is occupied during init.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
On Fri, 01 Jun 2007 09:56:12 +0200, Johannes Sixt <J.Sixt@eudaptics.com> wrote:
> Lars Hjemli wrote:
>> +test_expect_success 'status should only print one line' '
>> + lines=$(git-submodule status | wc -l)
>
> && is missing.
>
>> + test "$lines" = "1"
>
> Please don't put output of wc in quotes because some versions of wc emit
> padding:
>
> test $lines = 1
>
> (without the quotes around 1 - like in other test scripts).
>
Thanks, and sorry...
t/t7400-submodule-basic.sh | 143 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 143 insertions(+), 0 deletions(-)
create mode 100755 t/t7400-submodule-basic.sh
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
new file mode 100755
index 0000000..a985a6e
--- /dev/null
+++ b/t/t7400-submodule-basic.sh
@@ -0,0 +1,143 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Lars Hjemli
+#
+
+test_description='Basic porcelain support for submodules
+
+This test tries to verify basic sanity of the init, update and status
+subcommands of git-submodule.
+'
+
+. ./test-lib.sh
+
+#
+# Test setup:
+# -create a repository in directory lib
+# -add a couple of files
+# -add directory lib to 'superproject', this creates a DIRLINK entry
+# -add a couple of regular files to enable testing of submodule filtering
+# -mv lib subrepo
+# -add an entry to .gitmodules for path 'lib'
+#
+test_expect_success 'Prepare submodule testing' '
+ mkdir lib &&
+ cd lib &&
+ git-init &&
+ echo a >a &&
+ git-add a &&
+ git-commit -m "submodule commit 1" &&
+ git-tag -a -m "rev-1" rev-1 &&
+ rev1=$(git-rev-parse HEAD) &&
+ if test -z "$rev1"
+ then
+ echo "[OOPS] submodule git-rev-parse returned nothing"
+ false
+ fi &&
+ cd .. &&
+ echo a >a &&
+ echo z >z &&
+ git-add a lib z &&
+ git-commit -m "super commit 1" &&
+ mv lib .subrepo &&
+ GIT_CONFIG=.gitmodules git-config module.lib.url ./.subrepo
+'
+
+test_expect_success 'status should only print one line' '
+ lines=$(git-submodule status | wc -l) &&
+ test $lines = 1
+'
+
+test_expect_success 'status should initially be "missing"' '
+ git-submodule status | grep "^-$rev1"
+'
+
+test_expect_success 'init should fail when path is used by a file' '
+ echo "hello" >lib &&
+ if git-submodule init
+ then
+ echo "[OOPS] init should have failed"
+ false
+ elif test -f lib && test "$(cat lib)" != "hello"
+ then
+ echo "[OOPS] init failed but lib file was molested"
+ false
+ else
+ rm lib
+ fi
+'
+
+test_expect_success 'init should fail when path is used by a nonempty directory' '
+ mkdir lib &&
+ echo "hello" >lib/a &&
+ if git-submodule init
+ then
+ echo "[OOPS] init should have failed"
+ false
+ elif test "$(cat lib/a)" != "hello"
+ then
+ echo "[OOPS] init failed but lib/a was molested"
+ false
+ else
+ rm lib/a
+ fi
+'
+
+test_expect_success 'init should work when path is an empty dir' '
+ rm -rf lib &&
+ mkdir lib &&
+ git-submodule init &&
+ head=$(cd lib && git-rev-parse HEAD) &&
+ if test -z "$head"
+ then
+ echo "[OOPS] Failed to obtain submodule head"
+ false
+ elif test "$head" != "$rev1"
+ then
+ echo "[OOPS] Submodule head is $head but should have been $rev1"
+ false
+ fi
+'
+
+test_expect_success 'status should be "up-to-date" after init' '
+ git-submodule status | grep "^ $rev1"
+'
+
+test_expect_success 'status should be "modified" after submodule commit' '
+ cd lib &&
+ echo b >b &&
+ git-add b &&
+ git-commit -m "submodule commit 2" &&
+ rev2=$(git-rev-parse HEAD) &&
+ cd .. &&
+ if test -z "$rev2"
+ then
+ echo "[OOPS] submodule git-rev-parse returned nothing"
+ false
+ fi &&
+ git-submodule status | grep "^\+$rev2"
+'
+
+test_expect_success 'the --cached sha1 should be rev1' '
+ git-submodule --cached status | grep "^\+$rev1"
+'
+
+test_expect_success 'update should checkout rev1' '
+ git-submodule update &&
+ head=$(cd lib && git-rev-parse HEAD) &&
+ if test -z "$head"
+ then
+ echo "[OOPS] submodule git-rev-parse returned nothing"
+ false
+ elif test "$head" != "$rev1"
+ then
+ echo "[OOPS] init did not checkout correct head"
+ false
+ fi
+'
+
+test_expect_success 'status should be "up-to-date" after update' '
+ git-submodule status | grep "^ $rev1"
+'
+
+test_done
--
1.5.2.839.ga3b1-dirty
^ permalink raw reply related
* Re: [PATCH] catch asciidoc failures
From: Martin Waitz @ 2007-06-01 8:36 UTC (permalink / raw)
To: Scott Lamb; +Cc: Junio C Hamano, git
In-Reply-To: <11806790373908-git-send-email-slamb@slamb.org>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
hoi :)
On Thu, May 31, 2007 at 11:23:57PM -0700, Scott Lamb wrote:
> If pipefail is available (GNU bash >= 3.00), fail when asciidoc returns
> error rather than possibly later during XSLT.
perhaps we should simply change the pipe ordering to get asciidoc
to the end of the pipeline so that all shells respect its exit code?
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -111,6 +111,7 @@ clean:
>
> %.html : %.txt
> rm -f $@+ $@
> + set -o pipefail 2>/dev/null; \
> $(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
> $(ASCIIDOC_EXTRA) -o - $< | \
> sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' >$@+
something like (untested):
sed -e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' $< |
$(ASCIIDOC) -b xhtml11 -d manpage -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -o $@+ -
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Let .git/config specify the url for submodules
From: Josef Weidendorfer @ 2007-06-01 8:08 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
In-Reply-To: <8c5c35580705301717h4e9b127fr21ee19764f8ec288@mail.gmail.com>
On Thursday 31 May 2007, Lars Hjemli wrote:
> On 5/28/07, Lars Hjemli <hjemli@gmail.com> wrote:
> > This changes git-submodule in a few ways:
>
> Please don't apply the "Let .git/config specify the url for
> submodules" patch, I'm having second thoughts ;-)
>
> Your design outline in
> http://article.gmane.org/gmane.comp.version-control.git/48287 is
> obviously superior, and I'd like to take a stab at it with something
> like this:
>
> 1. 'git-submodule init' saves submodule name and suggested url from
> .gitmodules into .git/config (submodule.$name.url)
>
> 2. 'git-submodule update' keeps the work tree updated for submodules
> with five separate (and optional) operations:
> a) git-clone --bare $url .git/submodules/$name.git
> b) git-clone -l -s .git/submodules/$name.git $path
> c) cd .git/submodules/$name.git && git-fetch
> d) cd $path && git-fetch
> e) cd $path && git-checkout $sha1
>
> 3) 'git-submodule push' runs something like 'cd $path && git push
> origin $branch', where $branch is found in .gitmodules
> (path.$path.branch).
So if you need superproject related corrections in the submodule,
you always have to do it on branch "path.$path.branch" in the
submodule to get it saved?
I would assume that pushing the current branch should be enough.
If you want to play with multiple different "corrections" on
different branches in the submodule, you do not want to force
the branch name to a unique one given in .gitmodules.
Josef
^ 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