* [PATCH] git-remote - Unset remotes.default when deleting the default remote
From: Mark Levedahl @ 2008-01-11 3:29 UTC (permalink / raw)
To: gitster; +Cc: git, Mark Levedahl
In-Reply-To: <1200022189-2400-2-git-send-email-mlevedahl@gmail.com>
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
git-remote.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/git-remote.perl b/git-remote.perl
index d13e4c1..2469b59 100755
--- a/git-remote.perl
+++ b/git-remote.perl
@@ -328,6 +328,11 @@ sub rm_remote {
$git->command('config', '--remove-section', "remote.$name");
+ my $defremote = $git->config("remotes.default");
+ if (defined $defremote && $defremote eq $name) {
+ $git->command("config", "--unset", "remotes.default");
+ }
+
eval {
my @trackers = $git->command('config', '--get-regexp',
'branch.*.remote', $name);
--
1.5.4.rc2.99.g3ef7-dirty
^ permalink raw reply related
* [PATCH] Teach remote machinery about remotes.default config variable
From: Mark Levedahl @ 2008-01-11 3:29 UTC (permalink / raw)
To: gitster; +Cc: git, Mark Levedahl
In-Reply-To: <1200022189-2400-1-git-send-email-mlevedahl@gmail.com>
This introduces a new configuration variable, remotes.default, that
defines the name of the default remote to be used. Traditionally, this
is "origin", and could be overridden for a given branch. This change
introduces a way to redefine the default as desired and have that honored
regardless of the currently checked out head (e.g., remotes.default is
used when on a detached head or any other non-tracking branch).
Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
---
Documentation/config.txt | 6 ++++++
git-parse-remote.sh | 5 +++--
remote.c | 11 ++++++++++-
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 1b6d6d6..01ce295 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -800,6 +800,12 @@ remote.<name>.tagopt::
Setting this value to --no-tags disables automatic tag following when fetching
from remote <name>
+remotes.default::
+ The name of the remote used by default for fetch / pull. If unset,
+ origin is assumed. This value is used whenever the current branch
+ has no corresponding branch.<name>.remote, such as when working on
+ a detached head.
+
remotes.<group>::
The list of remotes which are fetched by "git remote update
<group>". See linkgit:git-remote[1].
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 695a409..1b235e0 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -56,8 +56,9 @@ get_remote_url () {
get_default_remote () {
curr_branch=$(git symbolic-ref -q HEAD | sed -e 's|^refs/heads/||')
- origin=$(git config --get "branch.$curr_branch.remote")
- echo ${origin:-origin}
+ git config --get "branch.$curr_branch.remote" ||
+ git config --get "remotes.default" ||
+ echo origin
}
get_remote_default_refs_for_push () {
diff --git a/remote.c b/remote.c
index 0e00680..4937237 100644
--- a/remote.c
+++ b/remote.c
@@ -10,6 +10,7 @@ static int allocated_branches;
static struct branch *current_branch;
static const char *default_remote_name;
+static const char *remotes_default_name;
#define BUF_SIZE (2048)
static char buffer[BUF_SIZE];
@@ -233,6 +234,11 @@ static int handle_config(const char *key, const char *value)
add_merge(branch, xstrdup(value));
return 0;
}
+ if (!strcmp(key, "remotes.default")) {
+ if (value)
+ remotes_default_name = xstrdup(value);
+ return 0;
+ }
if (prefixcmp(key, "remote."))
return 0;
name = key + 7;
@@ -291,7 +297,6 @@ static void read_config(void)
int flag;
if (default_remote_name) // did this already
return;
- default_remote_name = xstrdup("origin");
current_branch = NULL;
head_ref = resolve_ref("HEAD", sha1, 0, &flag);
if (head_ref && (flag & REF_ISSYMREF) &&
@@ -300,6 +305,10 @@ static void read_config(void)
make_branch(head_ref + strlen("refs/heads/"), 0);
}
git_config(handle_config);
+ if (!default_remote_name) {
+ default_remote_name = remotes_default_name ?
+ remotes_default_name : xstrdup("origin");
+ }
}
struct refspec *parse_ref_spec(int nr_refspec, const char **refspec)
--
1.5.4.rc2.99.g3ef7-dirty
^ permalink raw reply related
* Allowing override of the default "origin" nickname
From: Mark Levedahl @ 2008-01-11 3:29 UTC (permalink / raw)
To: gitster; +Cc: git
git's current support for remote nicknames other than
"origin" is restricted to tracking branches where
branch.<name>.remote is defined. This does not work on
detached heads, and thus does not work for managed
submodules as those are kept on detached heads. When working
with submodules, the remote must be called "origin."
As my project is distributed across multiple domains with
many firewalls and airgaps such that no single server is
available to all, we really need to use nicknames to refer
to different servers, and we need that to work well with
submodules.
So, this patch series:
1) defines a new "remotes.default" config variable per
repository to be the default remote used if no
branch.<name>.remote is found.
2) teaches clone to set remotes.default according to
the user's command (via -o).
3) teaches remote rm to unset remotes.default if deleting
that remote.
4) teaches git-submodule to propoagate the parent's default
branch to submoules during "init", IFF those modules are
defined using relative urls. (Modules using absolute urls
are likely from a different server, so this inheritence is
not likely the right thing in that case.)
This is working well for me, allowing
git clone -o myserver <url> project
cd project
git submodule init
git submoule update
to work as expected, with all submodules pointing to
"myserver" rather than "origin" and updating correctly despite
being on detached heads.
Mark Levedahl
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Linus Torvalds @ 2008-01-11 2:10 UTC (permalink / raw)
To: Sam Vilain
Cc: Nicolas Pitre, Pierre Habouzit, Git Mailing List,
Johannes Schindelin, Marco Costalba, Junio C Hamano
In-Reply-To: <4786BFCD.1000303@vilain.net>
On Fri, 11 Jan 2008, Sam Vilain wrote:
>
> Without compression of deltas:
>
> wilber:~/src/perl-preview$ du -sk .git/objects/pack/
> 86781 .git/objects/pack/
>
> With compression of deltas:
>
> wilber:~/src/perl-preview$ du -sk .git/objects/pack/
> 72907 .git/objects/pack/
Ok, so non-compressed deltas are 20% bigger.
That may well be a perfectly acceptable trade-off if the end result is
then a lot faster. Has somebody done performance numbers? I may have
missed them.. The best test is probably something like "git blame" on a
file that takes an appreciable amount of time.
Linus
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Junio C Hamano @ 2008-01-11 1:15 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Gregory Jefferis, Steffen Prohaska, Git Mailing List
In-Reply-To: <47868530.2010501@dawes.za.net>
Rogan Dawes <lists@dawes.za.net> writes:
> One example that bit me recently was "git-apply --whitespace=strip"
You might want to go back the list archive for a few days to
find this patch:
[PATCH 2/2] core.whitespace cr-at-eol-is-ok
and try it out.
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Sam Vilain @ 2008-01-11 1:01 UTC (permalink / raw)
To: Linus Torvalds
Cc: Nicolas Pitre, Pierre Habouzit, Git Mailing List,
Johannes Schindelin, Marco Costalba, Junio C Hamano
In-Reply-To: <alpine.LFD.1.00.0801101454440.3148@woody.linux-foundation.org>
Linus Torvalds wrote:
>
> On Fri, 11 Jan 2008, Sam Vilain wrote:
>> Drat, guess that means I'll have to recompute the deltas - I was trying
>> to avoid that.
>
> Well, you could try to reuse the delta base information itself, but then
> recompute the actual delta data contents. It would require some
> source-code changes, but that may be faster (and result in a more accurate
> before/after picture) than actually recomputing the deltas.
Yes, it would - but my runs have finished.
Without compression of deltas:
wilber:~/src/perl-preview$ git-repack -a -d -f --window=250 --depth=100
Compressing objects: 100% (236554/236554), done.
Writing objects: 100% (244360/244360), done.
Total 244360 (delta 182343), reused 0 (delta 0)
wilber:~/src/perl-preview$ du -sk .git/objects/pack/
86781 .git/objects/pack/
With compression of deltas:
wilber:~/src/perl-preview$ time git-repack -a -d -f --window=250 --depth=100
Counting objects: 244360, done.
Compressing objects: 100% (236554/236554), done.
Writing objects: 100% (244360/244360), done.
Total 244360 (delta 182343), reused 0 (delta 0)
real 20m34.985s
user 20m1.003s
sys 0m25.558s
wilber:~/src/perl-preview$ du -sk .git/objects/pack/
72907 .git/objects/pack/
wilber:~/src/perl-preview$ git --version
git version 1.5.4.rc2.7.g079c9-dirty
Of course those compression parameters are quite insane.
And as a side note either repack-objects got significantly better about
memory use between 1.5.3.5 and that version (the OOM killer fired -
killing first firefox and thunderbird :)) or apparently running
git-repack with a ulimit stops it from allocating too much VM.
Sam.
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Junio C Hamano @ 2008-01-11 0:32 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Gregory Jefferis, Steffen Prohaska, Git Mailing List
In-Reply-To: <alpine.LFD.1.00.0801101556380.3148@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> (Side note: if there are known filetype extensions that have problems with
> the git guessing, we sure as heck could take the filename into account
> when guessing! There's absolutely nothing that says that we only have to
> look at the contents when guessing about the text/binary thing!)
You do not have to yell.
Instead, just give yourself a pat in the back for having a
brilliant foresight to give "path" parameter when you did
6c510bee2013022fbce52f4b0ec0cc593fc0cc48 (Lazy man's auto-CRLF)
to convert_to_git() function, even though the code originally
did not use it back then ;-).
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Linus Torvalds @ 2008-01-11 0:02 UTC (permalink / raw)
To: Gregory Jefferis; +Cc: Junio C Hamano, Steffen Prohaska, Git Mailing List
In-Reply-To: <C3AC3E6F.10D42%jefferis@gmail.com>
On Thu, 10 Jan 2008, Gregory Jefferis wrote:
>
> So this is what has to be accommodated. But instead of having autocrlf
> always set on Windows and always converting to LF in the repository, why not
> do nothing by default [ .. ]
Why? You can screw yourself more, and much more easily (and much more
subtly), by leaving CRLF alone on Windows.
The thing is, 99.9% of all people will be *much* better off with
autocrlf=true on Windows than with it defaulting to off (or even fail).
Isn't *that* the whole point of having a default? Pick the thing that is
the right thing for almost everybody?
And no, "but think of the children.." is not a valid argument. Sure, you
*can* corrupt binary imags with CRLF conversion. But it's really quite
hard, since the git heuristics for guessing are rather good. You really
have to work at it, and if you do, you're pretty damn likely to know about
the issue, so that 0.1% that really needs to not convert (and it's usually
one specific file type!) would probably not even turn off CRLF, but rather
add a .gitattributes entry for that one filetype!
(Side note: if there are known filetype extensions that have problems with
the git guessing, we sure as heck could take the filename into account
when guessing! There's absolutely nothing that says that we only have to
look at the contents when guessing about the text/binary thing!)
Linus
^ permalink raw reply
* Re: [EGIT PATCH] Showing abbreviated commit hash of the versions in Compare editor.
From: Robin Rosenberg @ 2008-01-10 23:46 UTC (permalink / raw)
To: Roger C. Soares; +Cc: git, Shawn O. Pearce
In-Reply-To: <4784247B.10604@intelinet.com.br>
onsdagen den 9 januari 2008 skrev Roger C. Soares:
> Robin Rosenberg escreveu:
> > I'm implementing fetch (with some help from Shawn). Progress in
> > place. I still need to update refs and get in consistent with native
> > git behaviour.
> >
> > I'm also updating the javadocs.
> Cool.
>
> I use a lot the eclipse feature that highlights all occurences of a
> variable or method but with all the warnings in the project it is
> difficult to visually find these occurences. So I'm anxious to remove a
> lot of warnings. Public methods without documentation are one of them.
> Is it ok if I send you a patch removing all the warnings I know how but
> the ones about public methods needing documentation as you're already
> documenting them? I also want to remove the auto generated TODOs, as
> they don't actually say what to do, like this one:
> // TODO Auto-generated catch block
I pushed my doc-branch as pu, you can look at it. My intention is take a look again
and then push it as master if there are no objections. Is it ok and good to flags
public stuff without javadoc as an error (tip pu commit)?
The abbr commit patch is already pushed to master.
-- robin
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Dmitry Potapov @ 2008-01-10 23:23 UTC (permalink / raw)
To: Gregory Jefferis
Cc: Linus Torvalds, Junio C Hamano, Steffen Prohaska,
Git Mailing List
In-Reply-To: <C3AC3E6F.10D42%jefferis@gmail.com>
On Thu, Jan 10, 2008 at 09:28:15PM +0000, Gregory Jefferis wrote:
>
> Insisting that repos created on windows should have textfiles munged to LF
> by default doesn't seem right. Even using Dmitry's clever autocrlf=safe
> option on Windows would lead to inconvenience since all LF files have to be
> explicitly attributed as text. We should be helping Windows people to use
> LF files rather than hindering them!
I think people may have different preferences about that. Some people
may want to have text files with CRLF but others with LF. Some trust Git
heuristic for detecting text files (which seems works rahter good for
most commonly used formats) but others are paranoid about loss some
data. Finally, there are some people, who just wants to store their
messy files as is. Based on that, the following options are possible:
1. autocrlf=input for those who want LF and trust Git text heuristic
2. autocrlf=true is for those who want CRLF and trust Git text heuristic
3. autocrlf=fail for those who want LF but do not trust Git heuristic
4. autocrlf=safe for those who want CRLF but do not trust Git heuristic
5. autocrlf=false for those who like messy files with different EOLs
All these options have been mentioned in this thread, and I don't think
we are likely to come up with a better solution, because "better"
depends in which category of people you fall. IMHO, #5 is the least
reasonable of all.
Dmitry
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Linus Torvalds @ 2008-01-10 22:56 UTC (permalink / raw)
To: Sam Vilain
Cc: Nicolas Pitre, Pierre Habouzit, Git Mailing List,
Johannes Schindelin, Marco Costalba, Junio C Hamano
In-Reply-To: <47869C24.3000400@vilain.net>
On Fri, 11 Jan 2008, Sam Vilain wrote:
>
> Drat, guess that means I'll have to recompute the deltas - I was trying
> to avoid that.
Well, you could try to reuse the delta base information itself, but then
recompute the actual delta data contents. It would require some
source-code changes, but that may be faster (and result in a more accurate
before/after picture) than actually recomputing the deltas.
Linus
^ permalink raw reply
* Re: gmail smtp server and git-send-mail. Is this combination working?
From: Paolo Ciarrocchi @ 2008-01-10 22:49 UTC (permalink / raw)
To: Douglas Stockwell; +Cc: git
In-Reply-To: <fm44ck$299$1@ger.gmane.org>
On Jan 10, 2008 4:45 AM, Douglas Stockwell <doug@11011.net> wrote:
> 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'
I'm now getting:
Unable to initialize SMTP properly. Is there something wrong with
your config? at /home/paolo/bin/git-send-email line 638.
I tried to get help on #git but I failed, it looks like other people
are getting the same error.
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Sam Vilain @ 2008-01-10 22:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: Nicolas Pitre, Pierre Habouzit, Git Mailing List,
Johannes Schindelin, Marco Costalba, Junio C Hamano
In-Reply-To: <alpine.LFD.1.00.0801101400550.3148@woody.linux-foundation.org>
Linus Torvalds wrote:
>> wilber:~/src/perl-preview$ du -sk .git
>> 73274 .git
>> wilber:~/src/perl-preview$ git-repack -a
>> Counting objects: 244360, done.
>> Compressing objects: 100% (55493/55493), done.
>> Writing objects: 100% (244360/244360), done.
>> Total 244360 (delta 181061), reused 244360 (delta 181061)
>> wilber:~/src/perl-preview$ du -sk .git/objects/pack/
>> 75389 .git/objects/pack/
>
> Hmm. I'm not sure I understand what this was supposed to show?
>
> You reused all the old deltas, and you did "du -sk" on two different
> things before/after (and didn't do a "-a -d" to repack the old pack
> either). So does the result actually have anything to do with any
> compression algorithm?
>
> Use "-a -d -f" to repack a whole archive.
Drat, guess that means I'll have to recompute the deltas - I was trying
to avoid that.
Ok, see you in an hour or two, hopefully sans bonehead mistakes this time :)
Sam.
^ permalink raw reply
* Re: [PATCH 6/6] Use new compress helpers in builtin-pack-objects.c
From: Nicolas Pitre @ 2008-01-10 22:26 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550801101334p5df5adaerf0eeae02ddf28334@mail.gmail.com>
On Thu, 10 Jan 2008, Marco Costalba wrote:
> This is the last one for this evening, this is interesting
> because pack_compression_level instead of the usual
> zlib_compression_level is used.
See documentation for the core.compression, core.loosecompression and
pack.compression config variables.
Nicolas
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Nicolas Pitre @ 2008-01-10 22:18 UTC (permalink / raw)
To: Marco Costalba
Cc: Pierre Habouzit, Sam Vilain, Git Mailing List,
Johannes Schindelin, Junio C Hamano
In-Reply-To: <e5bfff550801101351w257975b1q9391d556c7af22a0@mail.gmail.com>
On Thu, 10 Jan 2008, Marco Costalba wrote:
> On Jan 10, 2008 9:39 PM, Nicolas Pitre <nico@cam.org> wrote:
> >
> > Right. Abstracting the zlib code and having different compression
> > algorithms tested in the Git context is the only way to do meaningful
> > comparisons.
> >
>
> The first thing I would like to test when zlib abstraction is ready is
> to test with NULL compressor, i.e. not compression/decompression at
> all and see if 'git log' and friends are happy.
Easy: git config core.compression 0
Nicolas
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Linus Torvalds @ 2008-01-10 22:03 UTC (permalink / raw)
To: Sam Vilain
Cc: Nicolas Pitre, Pierre Habouzit, Git Mailing List,
Johannes Schindelin, Marco Costalba, Junio C Hamano
In-Reply-To: <478691EB.1080704@vilain.net>
On Fri, 11 Jan 2008, Sam Vilain wrote:
>
> For reference, 20 years of Perl with very deep deltas:
>
> wilber:~/src/perl-preview$ du -sk .git
> 73274 .git
> wilber:~/src/perl-preview$ git-repack -a
> Counting objects: 244360, done.
> Compressing objects: 100% (55493/55493), done.
> Writing objects: 100% (244360/244360), done.
> Total 244360 (delta 181061), reused 244360 (delta 181061)
> wilber:~/src/perl-preview$ du -sk .git/objects/pack/
> 75389 .git/objects/pack/
Hmm. I'm not sure I understand what this was supposed to show?
You reused all the old deltas, and you did "du -sk" on two different
things before/after (and didn't do a "-a -d" to repack the old pack
either). So does the result actually have anything to do with any
compression algorithm?
Use "-a -d -f" to repack a whole archive.
Linus
^ permalink raw reply
* Re: [PATCH 1/5] Add zlib decompress helper functions
From: Marco Costalba @ 2008-01-10 22:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.1.00.0801101351250.3148@woody.linux-foundation.org>
On Jan 10, 2008 10:57 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 10 Jan 2008, Marco Costalba wrote:
> >
> > When decompressing a zlib stream use this
> > helpers instead of calling low level zlib
> > function.
>
> I really *really* hate your naming.
>
I agree 100% it was chosen only to keep zlib conventions.
>
> [ How many people really know that "inflate" means "uncompress", without
> having to think about it a bit?
>
I misnamed the whole patch series but the last one due to deflate
being tot intuitive !!!
Ok I wrote the e-mails very quickly and cut and paste was heavily
involved, but when I realized that I called all the series 'decompress
helpers' I went blush!
Marco
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Sam Vilain @ 2008-01-10 22:01 UTC (permalink / raw)
To: Marco Costalba
Cc: Nicolas Pitre, Pierre Habouzit, Git Mailing List,
Johannes Schindelin, Junio C Hamano
In-Reply-To: <e5bfff550801101351w257975b1q9391d556c7af22a0@mail.gmail.com>
Marco Costalba wrote:
> BTW would be possible to test git with zlib disabled also now? I mean
> there is a quick hack to disable zlib not only in writing but also in
> reading, so that we can see what happens when running a repository
> packed without compression?
See Nicholas Pitre's hack on another branch of this thread - it won't
cut out zlib entirely, but at least it's just configuring it to do plain
pass-through. You can probably just replace pack_compression_level with 0.
Sam
^ permalink raw reply
* Re: [PATCH 1/5] Add zlib decompress helper functions
From: Linus Torvalds @ 2008-01-10 21:57 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550801101304m4f0b97baua6553c45772793b6@mail.gmail.com>
On Thu, 10 Jan 2008, Marco Costalba wrote:
>
> When decompressing a zlib stream use this
> helpers instead of calling low level zlib
> function.
I really *really* hate your naming.
> This is the first step in generalizing compress and
> decompress functions avoiding zlib directly calls.
If that's the goal, why keep the horrible "z_" prefix, and why the opaque
and non-obvious "inflate"/"deflate" names?
I'd suggest that you just replace all "z_deflate_" with "compress_" and
"z_inflate_" with "decompress_".
Yes, it would still leave zlib-specific stuff in there (the return codes,
the "z_stream" type thing etc), but at least it would be a _step_ towards
more readable code and code that is less obviously zlib-specific.
With those changes, I'd heartily recommend merging this even if we never
actually switch away from zlib, if only because zlib has all these
horrible names.
Linus
[ How many people really know that "inflate" means "uncompress", without
having to think about it a bit?
I guarantee that any computer person immediately knows the difference
between "compress" and "decompress" without even thinking, but ask
somebody what "inflate" vs "deflate" does, and they'll be able to answer
you, but they'll first have to think about an air mattress or something.
Yeah, yeah, old-time zip users probably think the whole xxflate thing
makes sense, and I'm just grouchy because _I_ always have to think
about it. ]
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Marco Costalba @ 2008-01-10 21:51 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Pierre Habouzit, Sam Vilain, Git Mailing List,
Johannes Schindelin, Junio C Hamano
In-Reply-To: <alpine.LFD.1.00.0801101332150.3054@xanadu.home>
On Jan 10, 2008 9:39 PM, Nicolas Pitre <nico@cam.org> wrote:
>
> Right. Abstracting the zlib code and having different compression
> algorithms tested in the Git context is the only way to do meaningful
> comparisons.
>
The first thing I would like to test when zlib abstraction is ready is
to test with NULL compressor, i.e. not compression/decompression at
all and see if 'git log' and friends are happy.
BTW would be possible to test git with zlib disabled also now? I mean
there is a quick hack to disable zlib not only in writing but also in
reading, so that we can see what happens when running a repository
packed without compression?
Thanks
Marco
^ permalink raw reply
* Re: Odd number of elements in anonymous hash
From: Junio C Hamano @ 2008-01-10 21:45 UTC (permalink / raw)
To: Dennis Schridde; +Cc: Eric Wong, git
In-Reply-To: <200801102213.04082.devurandom@gmx.net>
Dennis Schridde <devurandom@gmx.net> writes:
> Am Donnerstag, 10. Januar 2008 21:08:52 schrieb Junio C Hamano:
>> Dennis Schridde <devurandom@gmx.net> writes:
>> >> [svn-remote "svn"]
>> >> reposRoot = file:///var/svn/warzone2100
>> >> uuid = 4a71c877-e1ca-e34f-864e-861f7616d084
>> >> branches-maxRev = 14
>> >> tags-maxRev = 14
>> >> svnsync-uuid = 4a71c877-e1ca-e34f-864e-861f7616d084\n
>> >> svnsync-url = http://svn.gna.org/svn/warzone
>> >> [svn-remote "tags/1.10a.12"]
>> >> reposRoot = file:///var/svn/warzone2100
>> >> uuid = 4a71c877-e1ca-e34f-864e-861f7616d084
>> >> ---
>> >
>> > The rest of the file is rather boring. The "svn" remote is not changed
>> > (besides having higher revisions) and the other remotes look exactly like
>> > the "tags/1.10a.12" one.
>> >
>> > Somehow I think that the \n at the end of the svnsync-uuid shouldn't be
>> > there... It could be that this is the same linebreak which prevents
>> > people from relocating (svn switch --relocate) from
>> > svn://svn.gna.org/svn/warzone to http://svn.gna.org/svn/warzone, so that
>> > would be a Gna bug.
>> > However git-svn shouldn't throw any warnings (or even (make perl) crash?)
>> > on such occasions, either...
>> >
>> > I now got it to run through without a segfault, by compiling an unstriped
>> > perl binary with debug symbols (Gentoo: FEATURES=nostrip CFLAGS="...
>> > -g"). Maybe this is a bug in GCC or something...
>> >
>> > The "Odd number of elements in anonymous hash" still stays, though.
>>
>> The code in question is:
>>
>> my $svnsync;
>> # 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"),
>> }
>> };
>>
>> I think the "Odd number" is an indication that one of the
>> tmp_config() calls is returning an even number of elements (so
>> the hash whose ref will be stored in $svnsync ends up having an
>> odd number of elements), and that is why I initially asked you
>> about "more than one" svnsync-url. 0 is also an even number,
>> and it could be that it is not finding any.
>>
>> How about doing something ugly like this _just for diagnosis_?
>>
>> my $svnsync;
>> # see if we have it in our config, first:
>> eval {
>> my $section = "svn-remote.$self->{repo_id}";
>> my @u = tmp_config('--get', "$section.svnsync-url");
>> my @v = tmp_config('--get', "$section.svnsync-uuid");
>> if (@u != 1 || @v != 1) {
>> print STDERR "Oops: <$section> $#u <@u> $#v <@v>\n";
>> }
>> $svnsync = {
>> url => @u,
>> uuid => @v,
>> }
>> };
> I've created /usr/bin/git-svndbg and changed that part, like you proposed.
> I now get this output. (As it continues to run, there are probably more
> occassions of the Oops.)
> ---
> Oops: <svn-remote.svn> 0 <http://svn.gna.org/svn/warzone> 1
> <4a71c877-e1ca-e34f-864e-861f7616d084 >
> Odd number of elements in anonymous hash at /usr/bin/git-svndbg line 1768.
> r13 = ee6d5a48dd5cf1a96ed5217d638f372d2c173d89 (tags/1.10a)
> ---
Exactly. The trailing newline is taken as a record separator by
tmp_config subroutine.
^ permalink raw reply
* Re: Decompression speed: zip vs lzo
From: Sam Vilain @ 2008-01-10 21:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: Nicolas Pitre, Pierre Habouzit, Git Mailing List,
Johannes Schindelin, Marco Costalba, Junio C Hamano
In-Reply-To: <alpine.LFD.1.00.0801101252030.3148@woody.linux-foundation.org>
Linus Torvalds wrote:
> Maybe the difference to other repositories isn't huge, and maybe the
> kernel *is* a good test-case, but I just wouldn't take that for granted.
>
> Try with the gcc repo, especially the one that has deep delta chains (so
> it has even *more* deltas in relation to full objects than the kernel has)
For reference, 20 years of Perl with very deep deltas:
wilber:~/src/perl-preview$ du -sk .git
73274 .git
wilber:~/src/perl-preview$ git-repack -a
Counting objects: 244360, done.
Compressing objects: 100% (55493/55493), done.
Writing objects: 100% (244360/244360), done.
Total 244360 (delta 181061), reused 244360 (delta 181061)
wilber:~/src/perl-preview$ du -sk .git/objects/pack/
75389 .git/objects/pack/
wilber:~/src/perl-preview$
There are a few generated files in this history, but really only yacc
files etc. It is in general also a lot of small changes.
Sam.
^ permalink raw reply
* [PATCH 6/6] Use new compress helpers in builtin-pack-objects.c
From: Marco Costalba @ 2008-01-10 21:34 UTC (permalink / raw)
To: Git Mailing List
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
---
It's 'compress helper' not 'decomrpess helper' of course.
All my patch series is misnamed by my idiocy!
This is the last one for this evening, this is interesting
because pack_compression_level instead of the usual
zlib_compression_level is used.
The goal of this patch series is to have some
comment before to procede with remaining conversions.
When compression is fully abstarceted out I will go with
decompression (inflate).
At the end of this job perhaps we have something that
allows us to have fun with different compression libraries.
In any case IMHO this patch series is valid 'per se' as a
cleanup and (a lot of) code lines removing.
builtin-pack-objects.c | 21 ++++-----------------
1 files changed, 4 insertions(+), 17 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index a39cb82..682d7fb 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1,5 +1,6 @@
#include "builtin.h"
#include "cache.h"
+#include "compress.h"
#include "attr.h"
#include "object.h"
#include "blob.h"
@@ -409,9 +410,7 @@ static unsigned long write_object(struct sha1file *f,
*/
if (!to_reuse) {
- z_stream stream;
- unsigned long maxsize;
- void *out;
+ unsigned char *out = NULL;
if (!usable_delta) {
buf = read_sha1_file(entry->idx.sha1, &obj_type, &size);
if (!buf)
@@ -432,20 +431,8 @@ static unsigned long write_object(struct sha1file *f,
OBJ_OFS_DELTA : OBJ_REF_DELTA;
}
/* compress the data to store and put compressed length in datalen */
- memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, pack_compression_level);
- maxsize = deflateBound(&stream, size);
- out = xmalloc(maxsize);
- /* Compress it */
- stream.next_in = buf;
- stream.avail_in = size;
- stream.next_out = out;
- stream.avail_out = maxsize;
- while (deflate(&stream, Z_FINISH) == Z_OK)
- /* nothing */;
- deflateEnd(&stream);
- datalen = stream.total_out;
- deflateEnd(&stream);
+ datalen = z_deflate_all(pack_compression_level, buf, size, &out);
+
/*
* The object header is a byte of 'type' followed by zero or
* more bytes of length.
--
1.5.4.rc2.89.g1b3f-dirty
^ permalink raw reply related
* Re: Decompression speed: zip vs lzo
From: Nicolas Pitre @ 2008-01-10 21:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: Pierre Habouzit, Sam Vilain, Git Mailing List,
Johannes Schindelin, Marco Costalba, Junio C Hamano
In-Reply-To: <alpine.LFD.1.00.0801101252030.3148@woody.linux-foundation.org>
On Thu, 10 Jan 2008, Linus Torvalds wrote:
>
>
> On Thu, 10 Jan 2008, Nicolas Pitre wrote:
> >
> > Here's my rather surprising results:
> >
> > My kernel repo pack size without the patch: 184275401 bytes
> > Same repo with the above patch applied: 205204930 bytes
> >
> > So it is only 11% larger. I was expecting much more.
>
> It's probably worth doing those statistics on some other projects.
>
> Maybe the difference to other repositories isn't huge, and maybe the
> kernel *is* a good test-case, but I just wouldn't take that for granted.
Obviously.
This was a really crud test, and my initial goal was to quickly dismiss
Pierre's assertion. Turns out that he wasn't that wrong after all, and
if a significant increase in access speed by avoiding zlib for 82% of
object accesses can also be demonstrated for the kernel, then we have an
opportunity for some optimization tradeoff with no backward
compatibility concerns.
> Yes, delta's are bound to compress much less well than non-deltas, and
> especially for tree objects (which is a large chunk of them) they probably
> compress even less (because a big part of the delta is actually just the
> SHA1 changes), but if it's 11% on the kernel, it could easily be 25% on
> something else.
Right. But again this is not worth pursuing if a significant speed
increase in repo access is not demonstrated at least with the kernel.
Nicolas
^ permalink raw reply
* Re: CRLF problems with Git on Win32
From: Gregory Jefferis @ 2008-01-10 21:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Steffen Prohaska, Git Mailing List
In-Reply-To: <alpine.LFD.1.00.0801101208500.3148@woody.linux-foundation.org>
On 10/1/08 20:20, "Linus Torvalds" <torvalds@linux-foundation.org> wrote:
> - Mixed windows usage - either with other UNIX users, or even just
> *within* a windows environment if *some* of the tools are basically
> UNIX ports (ie MinGW or Cygwin without text-mounts)
>
> In this case, some tools will write files with CRLF, and others will
> write them with LF. Again, usually all tools can *read* either form,
> but the writing is mixed and depends on the tool (so if you work in a
> group where different people use different editors, you will literally
> switch back-and-forth between LF and CRLF, sometimes mixing the two in
> the same file!).
>
> This one - at the very least - basically requires "autocrlf=input".
> Anything else is just madness, because otherwise you'll get files that
> get partly or entirely rewritten in the object database just due to
> line ending changes.
So this is what has to be accommodated. But instead of having autocrlf
always set on Windows and always converting to LF in the repository, why not
do nothing by default unless the repository contains some information
specifying that it wants some or all text files to have a particular kind of
line ending (e.g. in gitattributes). Then the choice of line ending inside
the repository is up to the people creating/maintaining the repo, which just
seems right.
Insisting that repos created on windows should have textfiles munged to LF
by default doesn't seem right. Even using Dmitry's clever autocrlf=safe
option on Windows would lead to inconvenience since all LF files have to be
explicitly attributed as text. We should be helping Windows people to use
LF files rather than hindering them!
^ 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