* Re: Decompression speed: zip vs lzo
From: Marco Costalba @ 2008-01-10 6:55 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Johannes Schindelin, Sam Vilain, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.1.00.0801092234130.3054@xanadu.home>
On Jan 10, 2008 4:41 AM, Nicolas Pitre <nico@cam.org> wrote:
> On Wed, 9 Jan 2008, Johannes Schindelin wrote:
>
> > I agree that gzip is already fast enough.
> >
> > However, pack v4 had more goodies than just being faster; it also promised
> > to have smaller packs.
>
> Right, like not having to compress tree objects and half of commit
> objects at all.
>
>
Decompression speed has been shown to be a bottle neck on some tests
involving mainly 'git log'.
Regarding back compatibility I really don't know at what level git
functions actually need to know the compression format, looking at the
code I would say at very low level, functions that deal directly with
inflate() and friends are few [1] and not directly connected to UI,
nor to git config. Is this compression format something user should
know/care? and if yes why?
In my tests the assumption of a source files tar ball is unrealistic,
to test the final size difference I would like testing different
compressions on a big already packaged but still not zipped file.
Someone could be so kind to hint me on how to create such a package
with good quality, i.e. with packaging levels similar to what is done
for public repos?
This does not realistically tests speed because as Junio pointed out
the real decompressing schema is different: many calls on small
objects, not one call on a big one. But if final size is acceptable we
can go on more difficult tests.
Marco
[1] where inflate() is called:
-inflate_it() in builtin-apply.c
-check_pack_inflate() in builtin-pack-objects.c
-get_data() in builtin-unpack-objects.c
-fwrite_sha1_file() in http-push.c and http-walker.c [mmm interesting
same function in two files, also the signature and the contents seems
the same....]
-unpack_entry_data() in index-pack.c
-unpack_sha1_header(), unpack_sha1_rest(), get_size_from_delta(),
unpack_compressed_entry, write_sha1_from_fd() in sha1_file.c
^ permalink raw reply
* Re: [PATCH] - Updated usage and simplified sub-command action invocation
From: Imran M Yousuf @ 2008-01-10 6:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x2y8ahw.fsf@gitster.siamese.dyndns.org>
On Jan 10, 2008 12:23 PM, Junio C Hamano <gitster@pobox.com> wrote:
> imyousuf@gmail.com writes:
>
> > From: Imran M Yousuf <imyousuf@smartitengineering.com>
> >
> > - manual page of git-submodule and usage mentioned in git-subcommand.sh
> > were not same, thus synchronized them. In doing so also had to change the
> > way the subcommands were parsed.
> >
> > - Previous version did not allow commands such as "git-submodule add init
> > update". Thus not satisfying the following case -
> >
> > mkdir g; mkdir f; cd g/
> > touch g.txt; echo "sample text for g.txt" >> ./g.txt; git-init;
> > git-add g.txt; git-commit -a -m "First commit on g"
> > cd ../f/; ln -s ../g/ init
> > git-init; git-submodule add init update;
> > git-commit -a -m "With module update"
> > mkdir ../test; cd ../test
> > git-clone ../f/; cd f
> > git-submodule init update; git-submodule update update
> > cd ../..; rm -rf ./f/ ./test/ ./g/
>
> I find this too verbose with too little information.
>
> If I am reading you correctly, what you meant was that the way
> command parser was structured made subcommand names such as
> "init" and "update" reserved words, and it was impossible to use
> them as arguments to commands.
>
> You could have said something like this instead:
>
> The command parser incorrectly made subcommand names to
> git-submodule reserved, refusing them to be used as
> parameters to subcommands. For example,
>
> $ git submodule add init update
>
> to add a submodule whose (symbolic) name is "init" and
> that resides at path "update" was refused.
>
I agree that your comment is better than, I will change it accordingly
when resubmitting it.
> That would have been much cleaner and easier on the reader than
> having to decipher what the 20+ command shell script sequence
> was doing.
>
> I do agree that the breakage is worth fixing, though.
>
> > +# Synopsis of this commands are as follows
> > +# git-submodule [--quiet] [-b branch] add <repository> [<path>]
> > +# git-submodule [--quiet] [--cached] [status] [--] [<path>...]
> > +# git-submodule [--quiet] init [--] [<path>...]
> > +# git-submodule [--quiet] update [--] [<path>...]
>
> I somehow feel that syntactically the original implementation
> that allowed subcommand specific options to come before the
> subcommand name was a mistake. It may be easier for users that
> both "-b branch add" and "add -b branch" are accepted, but I
> have to wonder if it would really hurt if we made "-b branch
> add" a syntax error.
>
I will recode it to have all options except for --quiet (which is
inverse of -v or --verbose) be mentioned after the subcommand.
> So how about reorganizing the top-level option parser like this:
>
> while :
> do
> case $# in 0) break ;; esac
> case "$1" in
> add | status | init | update)
> # we have found subcommand.
> command="$1"
> shift
> break ;;
> --)
> # end of parameters
> shift
> break ;;
> --quiet)
> quiet=1
> ;;
> -*)
> die "unknown option $1"
> esac
> shift
> done
> test -n "$command" || command=$default_command
> module_$command "$@"
>
Actually module_$command is not possible because only add's module is
module_add rest are modules_$command. Thus I would require another if
else and that was the original reason for not using it. Instead I
should have (and will) used -
case "$1" in
add)
add=1
command="module_$1"
shift
break
;;
init|update|status)
init=1
command="modules_$1"
shift
check_for_terminator "$1"
break
;;
> And then make individual command implementations responsible for
> parsing their own options (and perhaps the common ones, to allow
> "git submodule add --quiet", but that is optional), like:
>
> module_add () {
> while :
> do
> case $# in 0) break ;; esac
> case "$1" in
> --cached)
> cached=1
> ;;
> -b | --branch)
> shift
> branch="$1"
> test -n "$branch" ||
> die "no branch name after -b?"
> ;;
> --)
> shift
> break
> ;;
> --quiet)
> quiet=1
> ;;
> -*)
> die "unknown option $1"
> esac
> shift
> done
> repo=$1
> path=$2
> ...
> }
>
> In the above illustration I did not bother eliminating cut&paste
> duplication, but there may be a better way to share the piece to
> parse common options across subcommands option parsers and the
> toplevel one.
>
As add subcommand does not support --cached it should be considered in
-*, just mentioning for your FYI, I got the point of module parsing
their own arguments and I am in agreement.
>
I will make the necessary changes and resubmit the patch tomorrow.
Best regards,
--
Imran M Yousuf
^ permalink raw reply
* Re: [PATCH] - Updated usage and simplified sub-command action invocation
From: Junio C Hamano @ 2008-01-10 6:23 UTC (permalink / raw)
To: imyousuf; +Cc: git, Imran M Yousuf
In-Reply-To: <1199938045-16289-1-git-send-email-imyousuf@gmail.com>
imyousuf@gmail.com writes:
> From: Imran M Yousuf <imyousuf@smartitengineering.com>
>
> - manual page of git-submodule and usage mentioned in git-subcommand.sh
> were not same, thus synchronized them. In doing so also had to change the
> way the subcommands were parsed.
>
> - Previous version did not allow commands such as "git-submodule add init
> update". Thus not satisfying the following case -
>
> mkdir g; mkdir f; cd g/
> touch g.txt; echo "sample text for g.txt" >> ./g.txt; git-init;
> git-add g.txt; git-commit -a -m "First commit on g"
> cd ../f/; ln -s ../g/ init
> git-init; git-submodule add init update;
> git-commit -a -m "With module update"
> mkdir ../test; cd ../test
> git-clone ../f/; cd f
> git-submodule init update; git-submodule update update
> cd ../..; rm -rf ./f/ ./test/ ./g/
I find this too verbose with too little information.
If I am reading you correctly, what you meant was that the way
command parser was structured made subcommand names such as
"init" and "update" reserved words, and it was impossible to use
them as arguments to commands.
You could have said something like this instead:
The command parser incorrectly made subcommand names to
git-submodule reserved, refusing them to be used as
parameters to subcommands. For example,
$ git submodule add init update
to add a submodule whose (symbolic) name is "init" and
that resides at path "update" was refused.
That would have been much cleaner and easier on the reader than
having to decipher what the 20+ command shell script sequence
was doing.
I do agree that the breakage is worth fixing, though.
> +# Synopsis of this commands are as follows
> +# git-submodule [--quiet] [-b branch] add <repository> [<path>]
> +# git-submodule [--quiet] [--cached] [status] [--] [<path>...]
> +# git-submodule [--quiet] init [--] [<path>...]
> +# git-submodule [--quiet] update [--] [<path>...]
I somehow feel that syntactically the original implementation
that allowed subcommand specific options to come before the
subcommand name was a mistake. It may be easier for users that
both "-b branch add" and "add -b branch" are accepted, but I
have to wonder if it would really hurt if we made "-b branch
add" a syntax error.
So how about reorganizing the top-level option parser like this:
while :
do
case $# in 0) break ;; esac
case "$1" in
add | status | init | update)
# we have found subcommand.
command="$1"
shift
break ;;
--)
# end of parameters
shift
break ;;
--quiet)
quiet=1
;;
-*)
die "unknown option $1"
esac
shift
done
test -n "$command" || command=$default_command
module_$command "$@"
And then make individual command implementations responsible for
parsing their own options (and perhaps the common ones, to allow
"git submodule add --quiet", but that is optional), like:
module_add () {
while :
do
case $# in 0) break ;; esac
case "$1" in
--cached)
cached=1
;;
-b | --branch)
shift
branch="$1"
test -n "$branch" ||
die "no branch name after -b?"
;;
--)
shift
break
;;
--quiet)
quiet=1
;;
-*)
die "unknown option $1"
esac
shift
done
repo=$1
path=$2
...
}
In the above illustration I did not bother eliminating cut&paste
duplication, but there may be a better way to share the piece to
parse common options across subcommands option parsers and the
toplevel one.
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Sam Vilain @ 2008-01-10 5:02 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Schindelin, Marco Costalba, Junio C Hamano
In-Reply-To: <47856E8D.4010006@vilain.net>
Sam Vilain wrote:
> I do really like LZOP as far as compression algorithms go. It seems a
> lot faster for not a huge loss in ratio.
Coincidentally, I read this today on an algorithm (LZMA - same as 7zip)
which is very slow to compress, high ratio but quick decompression:
http://use.perl.org/~acme/journal/35330
Which sounds excellent for squeezing those "archive packs" into even
more ridiculously tiny spaces.
Samn.
^ permalink raw reply
* Re: [PATCH] - Added recurse command to git submodule
From: Imran M Yousuf @ 2008-01-10 4:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lars Hjemli, git
In-Reply-To: <7vy7ay8gpq.fsf@gitster.siamese.dyndns.org>
On Jan 10, 2008 10:09 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Imran M Yousuf" <imyousuf@gmail.com> writes:
>
> >> Also, some commands cannot be made recursive by driving them
> >> from a higher level recursive wrapper. "git submodule recursive
> >> log" would not make much sense, not only because the order of
> >> the log entries are output from different invocations would not
> >> be useful, but because the revision range specifier would need
> >> to be different in different submodules (e.g. library submodules
> >> and application submodule will not share version name namespace,
> >> i.e. "log v1.0..v2.0" is undefined, and worse yet, running "log
> >> v1.0:path/to/sub..v2.0:path/to/sub" in a submodule when running
> >> "log v1.0..v2.0" in the toplevel is not a correct solution
> >> either in general).
> >
> > What is you suggestion in such cases Junio?
>
> Not doing it using the wrapper approach, but actually have the
> underlying command be aware of the recursiveness.
Yes, I do agree fully that the wrapper approach has problem in
recursing; as I mentioned earlier it is the user who has to be aware
of the command he wants to execute recursively; as all currently
available work can still be performed even if the wrapper recurse is
added. But at least having recurse would allow users to execute
certain simple commands from the top level which otherwise would have
required to be done from each sub-module.
>
> Let's take a small example of library project contained within
> an application project as a submodule (think of ffmpeg in
> mplayer or something like that).
>
> Library project has this history:
>
> 3---A
> /
> ---1---2---4---B
>
> while the application project has this history:
>
> ---5---X---6---Y
>
> and at time X (and before that point), it binds commit A at a
> directory "lib/" as a submodule. The commit 6 (between X and Y)
> changes it to bind commit B there instead. You have both
> toplevel and submodule checked out. The HEAD in the application
> project is at Y while the HEAD in the library project is at B.
> Your work tree may or may not be clean.
>
> How would a recursive "git diff" between two versions should
> behave, with various arguments?
>
> $ git diff X Y
>
> Currently this will say something like:
>
> --- a/lib
> +++ b/lib
> @@ -1 +1 @@
> -Subproject commit A
> +Subproject commit B
>
> You can make it recurse naturally by recursing into lib/
> subproject instead (at least conceptually this is a simple
> change but it may not be so straightforward, implementation
> wise).
>
> How would you handle this, then?
>
> $ git diff X Y -- Documentation/
>
> A wrapper approach that blindly descends into lib/ and runs "git
> diff X Y -- Documentation/" there is wrong at two levels.
> Commits X and Y do not even exist there, and Documentation/
> pathspec is wrong. The documentation may be called docs/ in the
> library project, or it may not even exist, and that is not what
> the user asked to see anyway. If the user were interested in
> the documentation of the library, the pathspec would have said
> lib/Documentaiton/ (or lib/docs/).
>
> For "git diff", the right solution happens to be invoking the
> command recursively without any pathspec. The higher level
> chose to recurse into the directory already because it saw
> changes --- by definition everything underneath is interesting.
>
> Side note. If we support asking for lib/docs/ from the
> toplevel, the recursive one would use docs/ as its
> pathspec in this case.
>
> The point is that pathspec needs to be munged from the higher
> level iteration, and more importantly that is pretty much
> specific to "git diff". "git diff" itself needs to have the
> knowledge of what to do when working recursively --- wrapper
> approach would not work well.
Yes, it is absolutely right that if the command was aware of the
recursion it could necessary measures to ensure that it can fallback
to default execution; e.g. remove the path spec from git-diff.
Alternatively, the recurse module could actually check whether if
simply passed the command would generate error or not; if yes then
display a message mentioning it and fallback to simplest form of the
command. The real disadvantage is that, firstly in this approach the
command gets executed twice in average case and secondly, the module
will have to know the fallback version of the command.
>
> How would a recursive version of "git log" work, then?
>
> $ git log X..Y
>
> Again, a naive wrapper approach of descending into lib/ and
> running "git log X..Y" recursively would not give us anything
> useful.
>
> But if "git log" itself knew recursive behaviour, it should be
> able to do much better. It can show Y and 6, and at that point
> it could notice that between 6 and its parent X the commit bound
> at lib/ as submodule has changed from A to B, so it could insert
> the log from submodule there. If we were running with
> --left-right, we might see something like this:
>
> >Y
> >6
> >B
> >4
> >2
> <A
> <3
> -2
> -X
>
> If the toplevel "git log" was invoked with a pathspec, again, it
> needs to be adjusted to submodule.
>
> I think a wrapper approach could be adequate for simple things
> like "checking out the whole tree including all of its
> submodules". But even that has to be done carefully.
>
> What should this command (recursive version) do?
>
> $ git checkout X
>
> The toplevel detaches head at commit X, and notices that it
> contains a submodule at lib/ whose HEAD now needs to point at
> A. The recursive command should go there, and say
>
> $ git checkout A
>
> What should it do when this checkout cannot be made because your
> work tree is not clean? Ideally, it should abort and roll-back
> the checkout of commit X at the toplevel (otherwise you will end
> up in a mixed state).
>
> There are more interesting issues when you bring up a situation
> where X and Y binds that library project at different place
> (i.e. submodule was moved inside the toplevel), which I avoided
> to talk about here to keep this message short.
>
Thank you for the detailed explanation and I can visualize more
scenarios which you did not mention. From this I get the following
ideas for the recurse command -
1. Instead of supporting all he git commands support a subset with
limited feature
2. Support full range of git commands, as is submitted in this patch,
but if error occurs in execution fall back to the default version of
the command. This is probably not a efficient version; but would be
beneficial as other commands will not be effected.
3. Support full range of git commands, as is submitted in this patch,
leave it to the user on how he wants to use it.
4. Scrap the recurse idea (I actually do not prefer it :)).
Let me know which one you prefer (please not 4 :)).
>
>
Best regards,
--
Imran M Yousuf
^ permalink raw reply
* Re: [PATCH] - Added recurse command to git submodule
From: Junio C Hamano @ 2008-01-10 4:09 UTC (permalink / raw)
To: Imran M Yousuf; +Cc: Lars Hjemli, git, Imran M Yousuf
In-Reply-To: <7bfdc29a0801091927v4eb65a60qf5b185924b9d1e44@mail.gmail.com>
"Imran M Yousuf" <imyousuf@gmail.com> writes:
>> Also, some commands cannot be made recursive by driving them
>> from a higher level recursive wrapper. "git submodule recursive
>> log" would not make much sense, not only because the order of
>> the log entries are output from different invocations would not
>> be useful, but because the revision range specifier would need
>> to be different in different submodules (e.g. library submodules
>> and application submodule will not share version name namespace,
>> i.e. "log v1.0..v2.0" is undefined, and worse yet, running "log
>> v1.0:path/to/sub..v2.0:path/to/sub" in a submodule when running
>> "log v1.0..v2.0" in the toplevel is not a correct solution
>> either in general).
>
> What is you suggestion in such cases Junio?
Not doing it using the wrapper approach, but actually have the
underlying command be aware of the recursiveness.
Let's take a small example of library project contained within
an application project as a submodule (think of ffmpeg in
mplayer or something like that).
Library project has this history:
3---A
/
---1---2---4---B
while the application project has this history:
---5---X---6---Y
and at time X (and before that point), it binds commit A at a
directory "lib/" as a submodule. The commit 6 (between X and Y)
changes it to bind commit B there instead. You have both
toplevel and submodule checked out. The HEAD in the application
project is at Y while the HEAD in the library project is at B.
Your work tree may or may not be clean.
How would a recursive "git diff" between two versions should
behave, with various arguments?
$ git diff X Y
Currently this will say something like:
--- a/lib
+++ b/lib
@@ -1 +1 @@
-Subproject commit A
+Subproject commit B
You can make it recurse naturally by recursing into lib/
subproject instead (at least conceptually this is a simple
change but it may not be so straightforward, implementation
wise).
How would you handle this, then?
$ git diff X Y -- Documentation/
A wrapper approach that blindly descends into lib/ and runs "git
diff X Y -- Documentation/" there is wrong at two levels.
Commits X and Y do not even exist there, and Documentation/
pathspec is wrong. The documentation may be called docs/ in the
library project, or it may not even exist, and that is not what
the user asked to see anyway. If the user were interested in
the documentation of the library, the pathspec would have said
lib/Documentaiton/ (or lib/docs/).
For "git diff", the right solution happens to be invoking the
command recursively without any pathspec. The higher level
chose to recurse into the directory already because it saw
changes --- by definition everything underneath is interesting.
Side note. If we support asking for lib/docs/ from the
toplevel, the recursive one would use docs/ as its
pathspec in this case.
The point is that pathspec needs to be munged from the higher
level iteration, and more importantly that is pretty much
specific to "git diff". "git diff" itself needs to have the
knowledge of what to do when working recursively --- wrapper
approach would not work well.
How would a recursive version of "git log" work, then?
$ git log X..Y
Again, a naive wrapper approach of descending into lib/ and
running "git log X..Y" recursively would not give us anything
useful.
But if "git log" itself knew recursive behaviour, it should be
able to do much better. It can show Y and 6, and at that point
it could notice that between 6 and its parent X the commit bound
at lib/ as submodule has changed from A to B, so it could insert
the log from submodule there. If we were running with
--left-right, we might see something like this:
>Y
>6
>B
>4
>2
<A
<3
-2
-X
If the toplevel "git log" was invoked with a pathspec, again, it
needs to be adjusted to submodule.
I think a wrapper approach could be adequate for simple things
like "checking out the whole tree including all of its
submodules". But even that has to be done carefully.
What should this command (recursive version) do?
$ git checkout X
The toplevel detaches head at commit X, and notices that it
contains a submodule at lib/ whose HEAD now needs to point at
A. The recursive command should go there, and say
$ git checkout A
What should it do when this checkout cannot be made because your
work tree is not clean? Ideally, it should abort and roll-back
the checkout of commit X at the toplevel (otherwise you will end
up in a mixed state).
There are more interesting issues when you bring up a situation
where X and Y binds that library project at different place
(i.e. submodule was moved inside the toplevel), which I avoided
to talk about here to keep this message short.
^ permalink raw reply
* [PATCH] - Updated usage and simplified sub-command action invocation
From: imyousuf @ 2008-01-10 4:07 UTC (permalink / raw)
To: git; +Cc: gitster, Imran M Yousuf
From: Imran M Yousuf <imyousuf@smartitengineering.com>
- manual page of git-submodule and usage mentioned in git-subcommand.sh
were not same, thus synchronized them. In doing so also had to change the
way the subcommands were parsed.
- Previous version did not allow commands such as "git-submodule add init
update". Thus not satisfying the following case -
mkdir g; mkdir f; cd g/
touch g.txt; echo "sample text for g.txt" >> ./g.txt; git-init;
git-add g.txt; git-commit -a -m "First commit on g"
cd ../f/; ln -s ../g/ init
git-init; git-submodule add init update;
git-commit -a -m "With module update"
mkdir ../test; cd ../test
git-clone ../f/; cd f
git-submodule init update; git-submodule update update
cd ../..; rm -rf ./f/ ./test/ ./g/
This patch fixes this issue and allows it as well.
- Added 2 specific messages for usage error related to branch and cached
- Simplified subcommand action invocation by simply invoking the action if
all conditions are fulfilled. Excepting for parsing command line arguments
case statements are avoided and instead more direct if statement is
introduced.
Signed-off-by: Imran M Yousuf <imyousuf@smartitengineering.com>
---
git-submodule.sh | 97 ++++++++++++++++++++++++++++++++++++------------------
1 files changed, 65 insertions(+), 32 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index ad9fe62..5d5e41d 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -4,18 +4,23 @@
#
# Copyright (c) 2007 Lars Hjemli
-USAGE='[--quiet] [--cached] [add <repo> [-b branch]|status|init|update] [--] [<path>...]'
+# Synopsis of this commands are as follows
+# git-submodule [--quiet] [-b branch] add <repository> [<path>]
+# git-submodule [--quiet] [--cached] [status] [--] [<path>...]
+# git-submodule [--quiet] init [--] [<path>...]
+# git-submodule [--quiet] update [--] [<path>...]
+USAGE='[--quiet] [[[[-b branch] add <repo>]|[[[[--cached] status]|init|update] [--]]] [<path>...]]'
OPTIONS_SPEC=
. git-sh-setup
require_work_tree
+MODULES_LIST='modules_list'
+
add=
branch=
-init=
-update=
-status=
quiet=
cached=
+command=
#
# print stuff on stdout unless -q was specified
@@ -293,20 +298,47 @@ modules_list()
done
}
+# If there is '--' as the first argument simply ignores it and thus shifts
+check_for_terminator()
+{
+ if test -n "$1" && test "$1" = "--"
+ then
+ shift
+ fi
+}
+
+# Command synopsis clearly shows that all arguments after
+# subcommand are arguments to the command itself. Thus
+# there lies no command that has configuration argument
+# after the mention of the subcommand. Thus once the
+# subcommand is found and the separator ('--') is ignored
+# rest can be safely sent the subcommand action
while test $# != 0
do
case "$1" in
add)
add=1
+ command="module_$1"
+ shift
+ break
;;
init)
- init=1
+ command="modules_$1"
+ shift
+ check_for_terminator "$1"
+ break
;;
update)
- update=1
+ command="modules_$1"
+ shift
+ check_for_terminator "$1"
+ break
;;
status)
- status=1
+ command="$MODULES_LIST"
+ shift
+ check_for_terminator "$1";
+ break
;;
-q|--quiet)
quiet=1
@@ -323,6 +355,9 @@ do
cached=1
;;
--)
+ # It is shifted so that it is not passed
+ # as an argument to the default subcommand
+ shift
break
;;
-*)
@@ -335,30 +370,28 @@ do
shift
done
-case "$add,$branch" in
-1,*)
- ;;
-,)
- ;;
-,*)
+# Throws usage error if branch is not used with add command
+if test -n "$branch" &&
+ test -z "$add"
+then
+ echo Branch can not be specified without add subcommand
usage
- ;;
-esac
-
-case "$add,$init,$update,$status,$cached" in
-1,,,,)
- module_add "$@"
- ;;
-,1,,,)
- modules_init "$@"
- ;;
-,,1,,)
- modules_update "$@"
- ;;
-,,,*,*)
- modules_list "$@"
- ;;
-*)
+fi
+
+# If no command is specified than default command
+# is - git submodule status
+if test -z "$command"
+then
+ command="$MODULES_LIST"
+fi
+
+# Throws usage if --cached is used by other than status, init or update
+# that is used with add command
+if test -n "$cached" &&
+ test "$command" != "$MODULES_LIST"
+then
+ echo Cached can only be used with the status subcommand
usage
- ;;
-esac
+fi
+
+"$command" "$@"
--
1.5.3.7
^ permalink raw reply related
* Re: [Fwd: [FORCEDETH]: Fix reversing the MAC address on suspend.]
From: Linus Torvalds @ 2008-01-10 3:47 UTC (permalink / raw)
To: David Miller; +Cc: dwmw2, B.Steinbrink, Junio C Hamano, Git Mailing List
In-Reply-To: <20080109.164149.264906319.davem@davemloft.net>
On Wed, 9 Jan 2008, David Miller wrote:
>
> > How do you generate those MSG_FILE/PATCH_FILE things? Using
> > "git-mailinfo"? Do you by any chance give it the "-n" flag to make it
> > *not* do the conversion to UTF8?
>
> I create them by hand in my editor.
Ok. Apparently you get them in latin1, and save them as such.
If you can make your editor/mail setup (I assume it's Gnu "bovine
excrement" Emacs, since you say that you use your editor for email) use
utf8 natively for saving any results, then all your problems should go
away.
That said, I suspect we could make git-commit just do the same thing that
git-am already does, namely if it's not given an explicit character set
for the input/output _and_ it's supposed to be in utf8, it could do the
"guess_charset()" thing on a per-line basis.
It's not perfect, but the reason git-am does that (through "git mailinfo")
is exactly the fact that it's very easy indeed to have mixed messages with
some parts in UTF-8 (the body, for example) and others *not* in utf-8 (eg
have headers in Latin1).
Doing the "check each line one at a time, see if it is already in UTF-8,
otherwise assume it's the traditional Latin1" is kind of hacky, but it's
probably better than just acceping a non-utf8 commit message and writing
random data.
For people who really want to use Latin1 (or any other non-utf8 model), we
already have a way to get the current behaviour, by forcing something like
[i18n]
commitencoding = binary
but we seem to have ended up with UTF-8 being the default encoding, so we
should probably just make sure that we do end up writing valid utf-8
unless some other explicit commit encoding has been set up.
So I think it's really your own fault for basically giving a latin1
message (and not using the tools that know how to convert emails correctly
from *many* different encodings).
But I *also* think that git probably should at least have warned you (I
think it does, if you use "git commit" rather than "git commit-tree), and
preferably have refused to write an invalid encoding or just converted
from what is the most common one (and even if I feel a bit bad about just
saying "latin1 is the default non-utf8 encoding", I think it makes sense
for historical reasons).
Linus
^ permalink raw reply
* Re: gmail smtp server and git-send-mail. Is this combination working?
From: Douglas Stockwell @ 2008-01-10 3:45 UTC (permalink / raw)
To: git
In-Reply-To: <4d8e3fd30801091509q49c02e1dua4ca42805ba891d6@mail.gmail.com>
Paolo Ciarrocchi wrote:
> Well, it would be nice to add this information to the wiki, it's still
> mentioning
> that you require an external program for supporting the TLS connection.
> I'll do that when I'll get my box working with the configuration you suggested,
>
> What I'm getting at the moment is:
> paolo@paolo-desktop:~/git$ git-send-email -compose -to
> paolo.ciarrocchi@gmail.com /home/paolo/Desktop/patch/
> snip
> snip
> Can't locate Net/SMTP/SSL.pm in @INC (@INC contains:
As indicated, the module you need is Net::SMTP::SSL, if there is no
package for ubuntu, you can install it using CPAN:
perl -MCPAN -e 'install Net::SMTP::SSL'
Doug
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Nicolas Pitre @ 2008-01-10 3:41 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sam Vilain, Marco Costalba, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LSU.1.00.0801092328580.31053@racer.site>
On Wed, 9 Jan 2008, Johannes Schindelin wrote:
> I agree that gzip is already fast enough.
>
> However, pack v4 had more goodies than just being faster; it also promised
> to have smaller packs.
Right, like not having to compress tree objects and half of commit
objects at all.
Nicolas
^ permalink raw reply
* Re: [PATCH] - Added recurse command to git submodule
From: Imran M Yousuf @ 2008-01-10 3:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Lars Hjemli, git, Imran M Yousuf
In-Reply-To: <7vhchmhhjv.fsf@gitster.siamese.dyndns.org>
On Jan 10, 2008 2:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > A possible extension is to specifiy "inter-submodule" paths to the
> > init subcommand, i.e. for a possible KDE layout:
> > git submodule -r init kdelibs kdelibs/admin
> >
> > This should then recursively initialize the kdelibs submodule and the
> > admin-submodule (in the kdelibs submodule).
>
> Beautiful.
Firstly, thank you for the feedback Junio and Lars. Secondly, I was
not planning to add recurse to the init/update command, but your
(Lars) suggestion seems really handy; I will implement it in my patch.
About auto-initialization, I, as writing, am implementing it to be
optional and an extra -i has to be specified if the user wants to do
it.
>
> > Btw: from my reading of the code, the git-command specified for
> > 'recurse' will be done top-to-bottom: I guess that's what you want for
> > something like 'git submodule recurse diff', but not for something
> > like 'git submodule recurse commit' (but IMHO the latter one should
> > never be executed ;-)
>
> Thanks for raising a very good point. Yes, some commands
> inherently wants depth first.
>
I could not agree more and in fact, I wanted to leave to the user how
they use the recurse command. I basically will be using for status and
diff primarily; and may be for creating and checking out branches; but
as I said it mostly depends on how the user wants to use it.
> While I agree that making a recursive is a grave usage error
> (submodule commit and toplevel commit are logically different
> events and even their commit log message should be different, as
> they talk about changes in logically different levels) from
> project management point of view, I do not think it is something
> a tool has to explicitly forbid the users to do. I view it as a
> kind of a long rope, a misuse the users can be allowed to
> inflict on themselves if they really wanted to.
>
In fact if I am also thinking whether to add intelligence in such
scenarios. What do you think if we choose DF of BF based on the
command and options?
> Also, some commands cannot be made recursive by driving them
> from a higher level recursive wrapper. "git submodule recursive
> log" would not make much sense, not only because the order of
> the log entries are output from different invocations would not
> be useful, but because the revision range specifier would need
> to be different in different submodules (e.g. library submodules
> and application submodule will not share version name namespace,
> i.e. "log v1.0..v2.0" is undefined, and worse yet, running "log
> v1.0:path/to/sub..v2.0:path/to/sub" in a submodule when running
> "log v1.0..v2.0" in the toplevel is not a correct solution
> either in general).
>
What is you suggestion in such cases Junio?
>
--
Imran M Yousuf
^ permalink raw reply
* Re: [PATCH] Simplified the invocation of command action in submodule
From: Imran M Yousuf @ 2008-01-10 3:05 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Sixt, git, gitster
In-Reply-To: <8c5c35580801090224l1e30df6cw5d3fefe99c0cdd7@mail.gmail.com>
On Jan 9, 2008 4:24 PM, Lars Hjemli <lh@elementstorage.no> wrote:
> On Jan 9, 2008 10:51 AM, Imran M Yousuf <imyousuf@gmail.com> wrote:
> > On Jan 9, 2008 2:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > >
> > > - Previously, passing --cached to add, init, or update was an error, now
> > > it is not.
> >
> > The usage statement and this behaviour is rather contradicting. The
> > usage says that --cached can be used with all commands; so I am not
> > sure whether using --cached with add should be an error or not. IMHO,
> > if the previous implementation was right than the USAGE has to be
> > changed, and if the previous implementation was incorrect, than if the
> > default command is set to status than current implementation is right.
> >
> > I would like to get comment on this until I fix the patch and resend it.
>
> --cached only makes sense for the status subcommand, so the
> usage/manpage probably should have looked like this (except for the
> whitespace mangling...):
>
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index cffc6d4..331e806 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -10,7 +10,10 @@ SYNOPSIS
> --------
> [verse]
> 'git-submodule' [--quiet] [-b branch] add <repository> [<path>]
> -'git-submodule' [--quiet] [--cached] [status|init|update] [--] [<path>...]
> +'git-submodule' [--quiet] [--cached] [status] [--] [<path>...]
> +'git-submodule' [--quiet] init [--] [<path>...]
> +'git-submodule' [--quiet] update [--] [<path>...]
> +
>
This change makes a lot sense. Thus I will make sure that it is used
in this manner :). Thanks a lot for clarifying it Lars. I wanted to
know what is the purpose of '--'? If it is simply meant to be a
separator than fine; else I would be grateful if you would please
explain its purpose, so that I do not again implement wrongly :).
>
> COMMANDS
> --
> 1.5.3.7.1141.g4eb39
>
--
Imran M Yousuf
^ permalink raw reply
* Signing by StGIT broken
From: Pavel Roskin @ 2008-01-10 2:53 UTC (permalink / raw)
To: Karl Hasselström, Catalin Marinas; +Cc: git
Hello!
"stg edit --sign" is not working anymore. It was working in version
0.14.
$ stg edit --sign
Checking for changes in the working directory ... done
Updating patch "id123" ... Traceback (most recent call last):
File "/home/proski/bin/stg", line 43, in <module>
main()
File "home/proski/lib/python2.5/site-packages/stgit/main.py", line 278, in main
File "home/proski/lib/python2.5/site-packages/stgit/commands/edit.py", line 235, in func
File "home/proski/lib/python2.5/site-packages/stgit/commands/edit.py", line 93, in __update_patch
File "home/proski/lib/python2.5/site-packages/stgit/commands/common.py", line 469, in parse_patch
File "home/proski/lib/python2.5/site-packages/stgit/commands/common.py", line 359, in __split_descr_diff
AttributeError: 'NoneType' object has no attribute 'split'
git-bisect reports this:
a08e424021d32bf93ee7bb13ed0a9d7313367660 is first bad commit
commit a08e424021d32bf93ee7bb13ed0a9d7313367660
Author: Karl Hasselström <kha@treskal.com>
Date: Thu Dec 13 00:13:55 2007 +0100
Make generic --message/--file/--save-template flags
And let "stg edit" use them.
Signed-off-by: Karl Hasselström <kha@treskal.com>
:040000 040000 0c9317423123d328e8bf03866c08fa458808dce4 9195692410c3ed8171f2f799a8e3efd101a89a14 M stgit
I suspect this part:
- elif options.file:
- __update_patch(pname, options.file, options)
+ elif any([options.message, options.authname, options.authemail,
+ options.authdate, options.commname, options.commemail,
+ options.sign_str]):
+ out.start('Updating patch "%s"' % pname)
+ __update_patch(pname, options.message, options)
+ out.done()
options.message is passed even if it's None and something else (like
options.sign_str) is defined.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: An interaction with ce_match_stat_basic() and autocrlf
From: Junio C Hamano @ 2008-01-10 2:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.1.00.0801080748080.3148@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> This patch should fix it, but I suspect we should think hard about that
> change to ie_modified(), and see what the performance issues are (ie that
> code has tried to avoid doing the more expensive ce_modified_check_fs()
> for a reason).
>
> The change to diff.c is similarly interesting. It is logically wrong to
> use the worktree_file there (since we have to read the object anyway), but
> since "reuse_worktree_file" is also tied into the whole refresh logic, I
> think the diff.c change is correct.
>
> I dunno. This is not meant to be applied, it is meant to be thought about.
There are a few cases around the changing value of autocrlf (and
filter attributes --- anything that affects convert_to_git() and
convert_to_working_tree()).
* The cached stat information matches the work tree, but user
changed convert_to_working_tree(). "git diff" reports
nothing. The user needs to remove the work tree file and
check it out again.
* The cached stat information matches the work tree, but user
changed convert_to_git(). Again, diff reports nothing. The
user needs to "git add" to cause rehashing.
* The cached stat information does not match. What the working
tree file stores hasn't changed, but convert_to_git() was
changed.
The fact that the working tree "file" contents did not change
does not have much significance in this case. What defines
the "contents" as far as git is concerned is the combination
of the working tree file contents _and_ what convert_to_git()
does to it.
Depending on the nature of the change to convert_to_git(),
"git diff-files" may or may not report real changes in this
case.
* The working tree file has changed, and convert_to_git() also
has changed.
Depending on the nature of the change to convert_to_git(),
"git diff" may or may not report change in this case. The
most extreme case is when unix2dos is run on the working tree
file and convert_to_git() is made to strip CR. The object
registered in the index won't change in this case.
But in practice, the most problematic case also falls into
this category. The user has _real_ changes to the work tree
file, but at the same time flipped convert_to_git() to
operate differently from before. Users should not be making
such a change, not because of git, but because a commit like
that will be impossible to review (and understand three
months later while archaeologying).
The ie_modified() change you suggested will not be hurt by the
first two cases (which I see are one-shot events and re-checkout
and re-add are good enough solution to them, and I do not want
them to hurt the performance for normal use cases).
I originally thought it was a _bug_, but I suspect the false
positive changes reported by "git diff" is even a good thing.
^ permalink raw reply
* Re: git svn fetch segfaults
From: Dennis Schridde @ 2008-01-10 1:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, git
In-Reply-To: <7v4pdmiwo4.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1078 bytes --]
Replying to this, as I haven't recieved the newer mail. (Not subscribed.)
Handcopied the text, hope I didn't forgot anything.
> > > Has anybody determined which executable is the segfaulting one?
> >
> > I just tried to, but it's still running, at r600 now.
> >
> > > If it is svn executable spawned by Perl that runs git-svn, or
> > > libsvn shared object linked to Perl while running git-svn, I
> > > suspect testing with different git versions will not be very
> > > productive.
> >
> > Oh well, anyway, just for the record:
> > doener@atjola:~ $ svn --version
> > svn, version 1.4.4 (r25188)
> >
> > doener@atjola:~ $ git --version
> > git version 1.5.4.rc1.11.gd2f82
>
> It finished by now, no segfault with --use-svnsync-props.
For me it always segfaulted at r13 in tags/1.10a.
I crosses r13 before that already (trunk), but doesn't crash there.
I am now recompiling svn,git,perl to create a coredump, will the rerun it and
hopefully get some backtraces from the dump.
Btw, I am running perl 5.8.8, in case that matters somehow.
--Dennis
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [STG PATCH] add a --index option to refresh which takes the contents of the index as the new commit
From: Karl Hasselström @ 2008-01-10 0:08 UTC (permalink / raw)
To: Peter Oberndorfer; +Cc: Git Mailing List, Catalin Marinas
In-Reply-To: <20080109072358.GB28839@diana.vm.bytemark.co.uk>
On 2008-01-09 08:23:58 +0100, Karl Hasselström wrote:
> On 2008-01-08 21:42:46 +0100, Peter Oberndorfer wrote:
>
> > Patch now comes with a Signed-off-by and a log message that
> > explains how this feature could be used. It was tested with the
> > testcase, used during development of this patch and on another
> > repo, but still take care when using it :-)
>
> I may be promising too much now, but hopefully I'll get to this
> tonight.
I've rebased my patch stack on top of Catalin's master now, and put
your two patches on top. The --index patch is only in experimental and
not stable, since you recommend further testing.
I massaged the commit messages slightly, mainly to get a reasonably
short first line and end all sentences with a period (except on the
first line, of course!).
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Sam Vilain @ 2008-01-10 1:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <alpine.LSU.1.00.0801092328580.31053@racer.site>
Johannes Schindelin wrote:
> No new object type. Why should it? But it has to have a config variable
> which says what type of packs/loose objects it has (and you will not be
> able to mix them).
I meant loose object. However this is configured, it affects things
like HTTP push/pull. Configuring like that would be a bit too fragile
for my tastes.
>> Not really worth it IMHO - gzip is already fast enough on even the most
>> modern processor these days.
>
> I agree that gzip is already fast enough.
>
> However, pack v4 had more goodies than just being faster; it also promised
> to have smaller packs. And pack v4 would need to have the same
> infrastructure of repacking if the client does not understand v4 packs.
Ineed - I think it would be a lot easier to implement if it didn't
bother with loose objects. It can just be a new pack version with more
compression formats. For when you know you're going to be doing a lot
of analysis you'd already run "git-repack -a -f" to shorten the deltas,
so this might be a useful option for some - but again I'd want to see
figures first.
I do really like LZOP as far as compression algorithms go. It seems a
lot faster for not a huge loss in ratio.
Sam.
^ permalink raw reply
* Re: [EGIT PATCH] Showing commit info like the CVS plugin instead of tooltips.
From: Roger C. Soares @ 2008-01-10 0:17 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, Shawn O. Pearce
In-Reply-To: <200801091912.37723.robin.rosenberg.lists@dewire.com>
Robin Rosenberg escreveu:
>> Showing the tooltips when you press F2 makes more sense to me. What I'm
>>
> Actually not what I meant. Javadoc tooltips popup as a tooltip. When it is
> active you can press F2 to see more information,
> copy text etc.
>
Humnmn, I see...
>> For the search bar, I would like to make it visible by pressing ctrl-f
>> when the history panel has the focus.
>>
> You're free to experiment. I'm quite fond of the search field in kmail. It is
> a textfield that filters mail on
> header fields as I type.
>
Yep, I'm willing to do something in this direction. The behavior I'm
thinking right now won't be to hide the lines that don't match but to do
more like gitk. Highlight rows and have next/previous buttons, and if
possible show where I am (like 3/10 or 3 of 10).
> I found a bug. When you travel down the histtory using arrow keys all of the
> sudden the commit info disappears.
>
Cool, thanks, I'll investigate it.
[]s,
Roger.
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Junio C Hamano @ 2008-01-09 23:49 UTC (permalink / raw)
To: Sam Vilain; +Cc: Marco Costalba, Git Mailing List
In-Reply-To: <47855765.9090001@vilain.net>
Sam Vilain <sam@vilain.net> writes:
> I think to go forward this would need a prototype and benchmark figures
> for things like "annotate" and "fsck --full" - but bear in mind it would
> be a long road to follow-up to completion, as repository compatibility
> would need to be a primary concern and this essentially would create a
> new pack type AND a new *object* type. Not only that, but currently
> there is no header in the objects on disk which can be used to detect a
> gzip vs. an lzop stream. Not really worth it IMHO - gzip is already
> fast enough on even the most modern processor these days.
For the compression type detection, I was hoping that we could
do something like sha1_file.c::legacy_loose_object(), but I tend
to agree it is not probably worth it.
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Johannes Schindelin @ 2008-01-09 23:31 UTC (permalink / raw)
To: Sam Vilain; +Cc: Marco Costalba, Git Mailing List, Junio C Hamano
In-Reply-To: <47855765.9090001@vilain.net>
Hi,
On Thu, 10 Jan 2008, Sam Vilain wrote:
> I think to go forward this would need a prototype and benchmark figures
> for things like "annotate" and "fsck --full" - but bear in mind it would
> be a long road to follow-up to completion, as repository compatibility
> would need to be a primary concern and this essentially would create a
> new pack type AND a new *object* type.
No new object type. Why should it? But it has to have a config variable
which says what type of packs/loose objects it has (and you will not be
able to mix them).
> Not really worth it IMHO - gzip is already fast enough on even the most
> modern processor these days.
I agree that gzip is already fast enough.
However, pack v4 had more goodies than just being faster; it also promised
to have smaller packs. And pack v4 would need to have the same
infrastructure of repacking if the client does not understand v4 packs.
Ciao,
Dscho
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Sam Vilain @ 2008-01-09 23:23 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <7v4pdmfw27.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Note that the space nor time performance of compressing and
> uncompressing a single huge blob is not as interesting in the
> context of git as compressing/uncompressing millions of small
> pieces whose total size is comparable to the specimen of "huge
> single blob" experiment. Obviously loose object files are
> compressed individually, and packfile contents are also
> individually and independently compressed. Set-up cost for
> individual invocation of compression and uncompression on
> smaller data matters a lot more than an experiment on
> compressing and uncompressiong a single huge blob (this applies
> to both time and space).
Yes - and lzo will almost certainly win on all those counts!
I think to go forward this would need a prototype and benchmark figures
for things like "annotate" and "fsck --full" - but bear in mind it would
be a long road to follow-up to completion, as repository compatibility
would need to be a primary concern and this essentially would create a
new pack type AND a new *object* type. Not only that, but currently
there is no header in the objects on disk which can be used to detect a
gzip vs. an lzop stream. Not really worth it IMHO - gzip is already
fast enough on even the most modern processor these days.
Sam.
^ permalink raw reply
* Re: gmail smtp server and git-send-mail. Is this combination working?
From: Paolo Ciarrocchi @ 2008-01-09 23:09 UTC (permalink / raw)
To: Douglas Stockwell; +Cc: git
In-Reply-To: <fm1h7t$nnr$1@ger.gmane.org>
On Jan 9, 2008 5:06 AM, Douglas Stockwell <doug@11011.net> wrote:
> Paolo Ciarrocchi wrote:
> > " Mailing off a set of patches to a mailing list can be quite neatly
> > done by git-send-email.
> > One of the problems you may encounter there is figuring out which machine
> > is going to send your mail.
> > I tried smtp.gmail.com, but that one requires tls and a password,
> > and git-send-email could not handle that "
> >
> > From http://git.or.cz/gitwiki/GitTips.
> >
> > Is this statemant still correct ?
> > Is msmtp the only solution for using git-send-mail with gmail? (tls +
> > autentication).
>
> No, as of 34cc60ce2b48f6037997543ddbab1ed9903df4a8 you can use SSL and
> SMTP-Auth.
>
> [sendemail]
> smtpserver = smtp.gmail.com
> smtpuser = <user>@gmail.com
> smtppass = <password>
> smtpssl = true
>
> Can you suggest changes to the documentation if these options are unclear?
Well, it would be nice to add this information to the wiki, it's still
mentioning
that you require an external program for supporting the TLS connection.
I'll do that when I'll get my box working with the configuration you suggested,
What I'm getting at the moment is:
paolo@paolo-desktop:~/git$ git-send-email -compose -to
paolo.ciarrocchi@gmail.com /home/paolo/Desktop/patch/
snip
snip
Can't locate Net/SMTP/SSL.pm in @INC (@INC contains:
/home/paolo/share/perl/5.8.8 /etc/perl /usr/local/lib/perl/5.8.8
/usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5
/usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at
/home/paolo/bin/git-send-email line 627.
Tv on #git helped me in finding an Ubuntu package which includes SSL.pm :
http://packages.ubuntu.com/cgi-bin/search_contents.pl?word=SSL.pm&searchmode=searchfiles&case=insensitive&version=gutsy&arch=i386
which repors:
usr/lib/perl5/Net/SSL.pm perl/libcrypt-ssleay-perl [universe]
usr/share/perl5/HTTP/Daemon/SSL.pm perl/libhttp-daemon-ssl-perl [universe]
usr/share/perl5/IO/Socket/SSL.pm perl/libio-socket-ssl-perl
usr/share/perl5/Net/IMAP/Simple/SSL.pm
perl/libnet-imap-simple-ssl-perl [universe]
usr/share/perl5/Net/Server/Proto/SSL.pm perl/libnet-server-perl [universe]
usr/share/perl5/POE/Component/Client/HTTP/SSL.pm
perl/libpoe-component-client-http-perl [universe]
I installed libcrypt-ssleay-perl but still no luck.
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: Odd number of elements in anonymous hash
From: Eric Wong @ 2008-01-09 22:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Dennis Schridde, git, Sam Vilain
In-Reply-To: <7vbq7wteq4.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Dennis Schridde <devurandom@gmx.net> writes:
>
> > Hello!
> >
> > I am getting "Odd number of elements in anonymous hash at /usr/bin/git-svn
> > line 1760." (normal output, no warning/error) during git-svn-clone.
> > I am using git version 1.5.4.rc2.
> >
> > Line 1760 is this (with context, marked with '!!'):
> > # see if we have it in our config, first:
> > eval {
> > my $section = "svn-remote.$self->{repo_id}";
> > !! $svnsync = {
> > url => tmp_config('--get', "$section.svnsync-url"),
> > uuid => tmp_config('--get', "$section.svnsync-uuid"),
> > }
> > };
> >
> > The commandline was "git svn
> > clone --authors-file=/var/git/org.gna.warzone.git/authors --use-svnsync-props --stdlayout
> > file:///var/svn/warzone2100/ org.gna.warzone.git/"
> >
> > I assume this is some kind of bug?
>
> More than one svn-remote.$your_repo.svnsync-{url,uuid}?
>
> (Eric CC'ed).
I don't use svnsync myself. I think Sam does, or would have more
insight into this than myself. I'll hopefully have time to take a
harder look at it later tonight.
--
Eric Wong
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Junio C Hamano @ 2008-01-09 22:55 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550801091401y753ea883p8d08b01f2b391147@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> P.S: Compression size is better for zip but a more realistic test
> would be to try with a delta packaged repo instead of a simple tar of
> source files. Because delta packaged is already compressed in his way
> perhaps difference in final file sizes is smaller.
Note that the space nor time performance of compressing and
uncompressing a single huge blob is not as interesting in the
context of git as compressing/uncompressing millions of small
pieces whose total size is comparable to the specimen of "huge
single blob" experiment. Obviously loose object files are
compressed individually, and packfile contents are also
individually and independently compressed. Set-up cost for
individual invocation of compression and uncompression on
smaller data matters a lot more than an experiment on
compressing and uncompressiong a single huge blob (this applies
to both time and space).
^ permalink raw reply
* Re: [PATCH] Trim leading / off of paths in git-svn prop_walk
From: Eric Wong @ 2008-01-09 22:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kevin Ballard, Benoit Sigoure
In-Reply-To: <7v63y2hg8x.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Kevin Ballard <kevin@sb.org> writes:
>
> > prop_walk adds a leading / to all subdirectory paths. Unfortunately
> > this causes a problem when the remote repo lives in a subdirectory itself,
> > as the leading / causes subsequent PROPFIND calls to be executed on
> > the wrong path. Trimming the / before calling the PROPFIND fixes this problem.
> >
> > Signed-off-by: Kevin Ballard <kevin@sb.org>
>
> Eric, the change is very limited in scope (only the parameter to
> ra->get_dir() changes) so I can apply myself, if you agree this
> is a trivially correct fix. I just do not know svn-perl
> interface well enough to judge.
Yes it is. It appears this regression was introduced in
01bdab84e31763a98206c31cf99b9dc3cb221356 so yes, it's trivially
correct :)
Acked-by: Eric Wong <normalperson@yhbt.net>
>
> > All tests passed after this change, but since it seems to only apply
> > to WebDAV SVN repos I saw no way to add a new test.
> > git-svn.perl | 1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git a/git-svn.perl b/git-svn.perl
> > index 3308fe1..d5316eb 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -1858,6 +1858,7 @@ sub rel_path {
> > sub prop_walk {
> > my ($self, $path, $rev, $sub) = @_;
> >
> > + $path =~ s#^/##;
> > my ($dirent, undef, $props) = $self->ra->get_dir($path, $rev);
> > $path =~ s#^/*#/#g;
> > my $p = $path;
> > --
> > 1.5.4.rc2.68.ge708a-dirty
--
Eric Wong
^ 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