* Re: git over rsync+ssh
From: Michael J Gruber @ 2008-07-10 10:06 UTC (permalink / raw)
To: git
In-Reply-To: <e2b179460807090802j2dbb72efo4f03c0a9e79241c0@mail.gmail.com>
Mike Ralphson venit, vidit, dixit 09.07.2008 17:02:
> 2008/7/9 Michael J Gruber <michaeljgruber+gmane@fastmail.fm>:
>> I want to put a git repo on a server where I have ssh access but failed to
>> compile git (AIX 5.1, has libz.a but no .so nor headers; compiling
>> prerequisite zlib failed, probably due to a botched build environment).
>
> I can send you a binary to try if you'd like. It would be compiled on
> AIX 5.3 but I have to jump through hoops on several non-identically
> set-up servers here, so one might work for you.
Thanks for the offer. I found an AIX 4.3 box with a working build
environment there, including zlib-devel, and I got git 1.5.6.2 compiled
now (no tcltk, don't care). Runs fine on the AIX 5.1 box, I can clone
and push happily. Yeah.
Michael
^ permalink raw reply
* Re: git over rsync+ssh
From: Michael J Gruber @ 2008-07-10 10:09 UTC (permalink / raw)
To: git
In-Reply-To: <20080709171721.GA3679@mithlond.arda.local>
Teemu Likonen venit, vidit, dixit 09.07.2008 19:17:
> Avery Pennarun wrote (2008-07-09 12:02 -0400):
>
>> I don't know if this will help in your case, but if it will be only
>> you pushing to this repository, one option is to simply create a bare
>> push repository on your local machine, and then manually just
>> rsync+ssh it to the remote machine from the command line as
>> a so-called "push" operation.
>
> Again, I don't know if this is helpful for Michael, but this "manual"
> rsyncing can be done automatically via hooks/post-receive. Just like
> Avery said, "git push" to a bare repository in a local machine and this
> bare repo has post-receive hook which does "git update-server-info" and
> the rsyncing (or "sitecopy --update" or similar).
Thanks for your hints. Your posts combined made me understand the trick,
using the "auxiliary" local repo for the hooks triggering the rsync.
I'll hopefully remember it when I need it; in this case, a second repo
would not have been very convenient, but I managed to get git running on
the server side meanwhile.
Michael
^ permalink raw reply
* Re: git over rsync+ssh
From: Michael J Gruber @ 2008-07-10 10:14 UTC (permalink / raw)
To: git
In-Reply-To: <9b3e2dc20807091333l38260b88na89939bdde09508e@mail.gmail.com>
Stephen Sinclair venit, vidit, dixit 09.07.2008 22:33:
> On Wed, Jul 9, 2008 at 10:01 AM, Michael J Gruber
> <michaeljgruber+gmane@fastmail.fm> wrote:
>> I want to put a git repo on a server where I have ssh access but failed to
>> compile git (AIX 5.1, has libz.a but no .so nor headers; compiling
>> prerequisite zlib failed, probably due to a botched build environment).
>>
>> As far as I can see my only option for a private repo is using rsync over
>> ssh.
>
> Have you tried sshfs?
Yes, in other cases, with mixed success. In the present situation, I'm
just John Doh User on both the client and the server, no sshfs available.
> It allows you to mount an ssh-accessible file system onto your local
> file system.
> This might make it possible to use your local git to access the remote account.
> Not sure of the implications for data integrity...
Integrity would be okay (single developper). But git is fast with a fast
filesystem, not so fast on NFS; on sshfs? I'm not even sure sshfs is
"filesystem-like" enough for git. Have you tried it with git?
Michael
P.S.: Problem solved differently now: got git going(TM) on the server.
^ permalink raw reply
* Re: [PATCH] Fix problem with authentification on http repository.
From: Johannes Schindelin @ 2008-07-10 10:51 UTC (permalink / raw)
To: Jeff King; +Cc: Mike Hommey, Junio C Hamano, jean.guyader, git, Jean Guyader
In-Reply-To: <20080710072420.GA5167@sigill.intra.peff.net>
Hi,
On Thu, 10 Jul 2008, Jeff King wrote:
> On Wed, Jul 09, 2008 at 01:43:07PM +0200, Johannes Schindelin wrote:
>
> > > Note that http://user:pass@server/path/ /should/ work (but that
> > > would need validation), though not a good idea on command line.
> >
> > Well, now that the programs using URLs are all builtins, we can
> > actually do something about it. We can edit out the "user[:pass]@"
> > part out of argv, which usually means that "ps" will not see it
> > anymore.
>
> Wouldn't there still be a race condition for publicly broadcasting your
> password via ps?
Yes. For a brief amount of time, but yes.
BTW I thought I remembered one program xxx'ing out the password via argv,
but unfortunately I do not remember which one it was.
Anyway, was just an idea.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Fix problem with authentification on http repository.
From: Andreas Ericsson @ 2008-07-10 11:30 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jeff King, Mike Hommey, Junio C Hamano, jean.guyader, git,
Jean Guyader
In-Reply-To: <alpine.DEB.1.00.0807101248360.3135@eeepc-johanness>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 10 Jul 2008, Jeff King wrote:
>
>> On Wed, Jul 09, 2008 at 01:43:07PM +0200, Johannes Schindelin wrote:
>>
>>>> Note that http://user:pass@server/path/ /should/ work (but that
>>>> would need validation), though not a good idea on command line.
>>> Well, now that the programs using URLs are all builtins, we can
>>> actually do something about it. We can edit out the "user[:pass]@"
>>> part out of argv, which usually means that "ps" will not see it
>>> anymore.
>> Wouldn't there still be a race condition for publicly broadcasting your
>> password via ps?
>
> Yes. For a brief amount of time, but yes.
>
> BTW I thought I remembered one program xxx'ing out the password via argv,
> but unfortunately I do not remember which one it was.
>
The mysql client does (or did) it, although perhaps only on systems that
support it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Errors importing Apache Synapse SVN using Git
From: Asankha C. Perera @ 2008-07-10 12:01 UTC (permalink / raw)
To: git
In-Reply-To: <4875F5D6.9080906@wso2.com>
Hi All
I am an Apache Synapse developer, and want to import the Synapse SVN
repo into Git, so that Ohloh can properly get the Synapse history
(http://www.ohloh.net/topics/1326?page=1#post_6287)
However, when I try the command: "git svn clone --trunk=trunk
--tags=tags --branches=branches http://svn.apache.org/repos/asf/synapse"
it seems to take forever, (or at least until the next network glitch),
and keeps filling up a file with just plain zeros ("0") :
./.git/svn/trunk/.rev_db.13f79535-47bb-0310-9956-ffa450edef68
Can someone try the above command on the Synapse repo and tell me what I
can do to import from the SVN?
many thanks
asankha
^ permalink raw reply
* Re: Errors importing Apache Synapse SVN using Git
From: Michael J Gruber @ 2008-07-10 12:59 UTC (permalink / raw)
To: git
In-Reply-To: <4875FA23.30603@wso2.com>
Asankha C. Perera venit, vidit, dixit 10.07.2008 14:01:
> Hi All
>
> I am an Apache Synapse developer, and want to import the Synapse SVN
> repo into Git, so that Ohloh can properly get the Synapse history
> (http://www.ohloh.net/topics/1326?page=1#post_6287)
>
> However, when I try the command: "git svn clone --trunk=trunk
> --tags=tags --branches=branches http://svn.apache.org/repos/asf/synapse"
> it seems to take forever, (or at least until the next network glitch),
> and keeps filling up a file with just plain zeros ("0") :
> ./.git/svn/trunk/.rev_db.13f79535-47bb-0310-9956-ffa450edef68
>
> Can someone try the above command on the Synapse repo and tell me what I
> can do to import from the SVN?
"svn log" takes forever on that repo, too. Current rev seems to be
675546, and the synapse path does not exist in early revisions. Knowing
the initial revision would help, then you could save "git svn" from
having to comb through (supposedly) tens of thousands of irrelevant revs.
I just checked out trunk using svn 1.4.6, "svn log ." takes forever in
the root dir. So the svn repo seems to be largely unusable, at least
when accessed from svn 1.4.6 clients (the server is 1.5.0, I see).
Okay, I bisected it and got r234477 as the beginning of time for
synapse. "svn log -r 234477:HEAD" is still painful.
You may want to fetch 1000 revs each or so from there each time.
Michael
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Geoffrey Irving @ 2008-07-10 14:09 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin, git@vger.kernel.org
In-Reply-To: <7f9d599f0807092034n438f0976pf44d4c9305871087@mail.gmail.com>
On Wed, Jul 9, 2008 at 8:34 PM, Geoffrey Irving <irving@naml.us> wrote:
> Add cached-sha-map.[ch] implementing a persistent hash map from sha1 to
> sha1. The map is read with mmap, and completely rewritten if any entries
> change. It would be good to add incremental update to handle the usual case
> where only a few entries change.
>
> This structure is used by patch-ids.c to cache the mapping from commit to
> patch-id into $GIT_DIR/patch-id-cache. In the one case I've tested so far,
> this speeds up the second invocation of git-cherry by two orders of
> magnitude. The caching can be disabled by setting cherry.cachepatchids to
> false.
>
> Original code cannibalized from Johannes Schindelin's notes-index structure.
>
> Signed-off-by: Geoffrey Irving <irving@naml.us>
> ---
>
> Note: there are at least two "holes" in this code. First, it is impossible
> to verify the validity of the entries (this is impossible to fix). Second,
> it is possible to write a malicious patch-id-cache file that causes git-cherry
> to go into an infinite loop. Fixing the loop requires either traversing every
> entry on load (bad) or adding a second loop termination condition to
> find_helper. Since looping forever is better than returning incorrect
> results, I figured fixing the weaker hole would just result in a false sense
> of security.
Oops: avoiding the infinite loop only requires reading expected O(1)
entries on load, so I can fix that if you like. It would only be all
of them if it actually did detect the infinite loop.
Geoffrey
^ permalink raw reply
* Re: [PATCH] apply: fix copy/rename breakage
From: Don Zickus @ 2008-07-10 14:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vy74aqvr1.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 09, 2008 at 08:10:58PM -0700, Junio C Hamano wrote:
> Recently, 7ebd52a (Merge branch 'dz/apply-again', 2008-07-01) taught
> "git-apply" to grok a (non-git) patch that is a concatenation of separate
> patches that touch the same file number of files, by recording the
> postimage of patch application of previous round and using it as the
> preimage for later rounds.
>
> However, this "incremental" mode of patch application contradicts with the
> way git rename/copy patches are fundamentally designed. When a git patch
> talks about a file A getting modified, and a new file B created out of B,
> like this:
>
> diff --git a/A b/A
> --- a/A
> +++ b/A
> ... change text here ...
> diff --git a/A b/B
> copy from A
> copy to B
> --- a/A
> +++ b/B
> ... change text here ...
>
> the second change to produce B does not depend on what is done to A with
> the first change (this is explicitly done so for reviewability of
> individual patches).
>
> With this patch, we disable the postimage record 'fn_table' when applying
> a patch to produce new files out of existing file by copying to fix this
> issue.
Odd. I guess the way I read this workflow is
apply change X to A, copy A' to B, apply change Y to B => B' now has changes X+Y
But instead you are saying B' only has change Y because A is copied to B
not A'.
Regardless, it doesn't affect my workflow.
ACK.
Cheers,
Don
^ permalink raw reply
* [PATCH] Added --export option to git-send-email.
From: Eduard - Gabriel Munteanu @ 2008-07-10 14:07 UTC (permalink / raw)
To: ryan; +Cc: gitster, git
This option allows the user to process patches with git-send-email and then
import them into an email client, without having to send them directly. The
output format is mbox.
Signed-off-by: Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro>
---
Documentation/git-send-email.txt | 6 ++++++
git-send-email.perl | 19 +++++++++++++++++++
2 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index afbb294..17a59dd 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -73,6 +73,12 @@ The --cc option must be repeated for each user you want on the cc list.
Default is the value of 'sendemail.signedoffcc' configuration value;
if that is unspecified, default to --signed-off-by-cc.
+--export::
+ Do not send anything, just export the emails in mbox format. You can
+ use this if you need to import the messages into your email client,
+ for example. Overwrites the target, which must not be one of the
+ input files.
+
--quiet::
Make git-send-email less verbose. One line per email should be
all that is output.
diff --git a/git-send-email.perl b/git-send-email.perl
index 3564419..53539cf 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -100,6 +100,9 @@ Options:
--thread Specify that the "In-Reply-To:" header should be set on all
emails. Defaults to on.
+ --export Don't actually send emails, just export them to a mbox file.
+ Overwrites target, which must not be one of the input files.
+
--quiet Make git-send-email less verbose. One line per email
should be all that is output.
@@ -184,6 +187,7 @@ if ($@) {
# Behavior modification variables
my ($quiet, $dry_run) = (0, 0);
+my ($export_file);
# Variables with corresponding config settings
my ($thread, $chain_reply_to, $suppress_from, $signed_off_cc, $cc_cmd);
@@ -260,6 +264,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"suppress-from!" => \$suppress_from,
"suppress-cc=s" => \@suppress_cc,
"signed-off-cc|signed-off-by-cc!" => \$signed_off_cc,
+ "export=s" => \$export_file,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
@@ -691,6 +696,7 @@ sub sanitize_address
}
+my ($out);
sub send_message
{
my @recipients = unique_email_list(@to);
@@ -741,6 +747,10 @@ X-Mailer: git-send-email $gitversion
if ($dry_run) {
# We don't want to send the email.
+ } elsif (defined $export_file) {
+ my $mbox_from = "From $raw_from $date";
+ $message =~ s/^(>{0,})From/>$1From/m;
+ print $out "$mbox_from\n$header\n$message";
} elsif ($smtp_server =~ m#^/#) {
my $pid = open my $sm, '|-';
defined $pid or die $!;
@@ -835,6 +845,11 @@ $reply_to = $initial_reply_to;
$references = $initial_reply_to || '';
$subject = $initial_subject;
+if (defined $export_file) {
+ my $err = open $out, '>', $export_file;
+ defined $err or die "Can't open '$export_file': $!";
+}
+
foreach my $t (@files) {
open(F,"<",$t) or die "can't open file $t";
@@ -979,6 +994,10 @@ foreach my $t (@files) {
$message_id = undef;
}
+if (defined $export_file) {
+ close $out or warn $?;
+}
+
if ($compose) {
cleanup_compose_files();
}
--
1.5.6.1
^ permalink raw reply related
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Johannes Schindelin @ 2008-07-10 14:28 UTC (permalink / raw)
To: Geoffrey Irving; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <7f9d599f0807100709u778f0ab1y28776d7efb831b61@mail.gmail.com>
Hi,
On Thu, 10 Jul 2008, Geoffrey Irving wrote:
> On Wed, Jul 9, 2008 at 8:34 PM, Geoffrey Irving <irving@naml.us> wrote:
>
> > Note: there are at least two "holes" in this code. First, it is
> > impossible to verify the validity of the entries (this is impossible
> > to fix). Second, it is possible to write a malicious patch-id-cache
> > file that causes git-cherry to go into an infinite loop. Fixing the
> > loop requires either traversing every entry on load (bad) or adding a
> > second loop termination condition to find_helper. Since looping
> > forever is better than returning incorrect results, I figured fixing
> > the weaker hole would just result in a false sense of security.
>
> Oops: avoiding the infinite loop only requires reading expected O(1)
> entries on load, so I can fix that if you like. It would only be all of
> them if it actually did detect the infinite loop.
I have to admit that you lost me there. AFAIR the patch-id cache is a
simple commit->patch_id store, right? Then there should be no way to get
an infinite loop.
Besides, this is a purely local cache, no? Never to be transmitted... So
not much chance of a malicious attack, except if you allow write access to
your local repository, in which case you are endangered no matter what.
Ciao,
Dscho
^ permalink raw reply
* Re: GiT and CentOS 5.2
From: Jeffrey Ollie @ 2008-07-10 14:32 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20080709T132329-674@post.gmane.org>
On Wed, Jul 9, 2008 at 8:25 AM, David Voit <david.voit@gmail.com> wrote:
>
> Just use the EPEL packages:
> http://wiki.centos.org/AdditionalResources/Repositories?action=show&redirect=Repositories
>
> Maybe not alwaya the newest version, but it works.
Here's a better link for EPEL information:
https://fedoraproject.org/wiki/EPEL
Jeff
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Geoffrey Irving @ 2008-07-10 14:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0807101526380.18205@racer>
On Thu, Jul 10, 2008 at 7:28 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 10 Jul 2008, Geoffrey Irving wrote:
>
>> On Wed, Jul 9, 2008 at 8:34 PM, Geoffrey Irving <irving@naml.us> wrote:
>>
>> > Note: there are at least two "holes" in this code. First, it is
>> > impossible to verify the validity of the entries (this is impossible
>> > to fix). Second, it is possible to write a malicious patch-id-cache
>> > file that causes git-cherry to go into an infinite loop. Fixing the
>> > loop requires either traversing every entry on load (bad) or adding a
>> > second loop termination condition to find_helper. Since looping
>> > forever is better than returning incorrect results, I figured fixing
>> > the weaker hole would just result in a false sense of security.
>>
>> Oops: avoiding the infinite loop only requires reading expected O(1)
>> entries on load, so I can fix that if you like. It would only be all of
>> them if it actually did detect the infinite loop.
>
> I have to admit that you lost me there. AFAIR the patch-id cache is a
> simple commit->patch_id store, right? Then there should be no way to get
> an infinite loop.
If every entry is nonnull, find_helper loops forever.
> Besides, this is a purely local cache, no? Never to be transmitted... So
> not much chance of a malicious attack, except if you allow write access to
> your local repository, in which case you are endangered no matter what.
Yep, that's why it's only a hole in quotes, and why I didn't fix it.
Geoffrey
^ permalink raw reply
* git pull is slow
From: Stephan Hennig @ 2008-07-10 14:40 UTC (permalink / raw)
To: git
Hi,
I am observing very large data transfers when pulling from the
repository at <URL:http://repo.or.cz/w/wortliste.git>. This repository
contains one 13 MB text file that compressed is roughly 3 MB large.
While I'd expect pulling commits that change only a few lines of the
large text file to result in a download of less than, say 10kB, git pull
seems to transfer the complete, compressed file. I have observed this
several times for different commits. On the other hand, pushing my own
commits to the repository is fast (with git+ssh access method). Any
ideas what's going on and how to make pulling faster?
Best regards,
Stephan Hennig
> $ git version
> git version 1.5.6.1.1071.g76fb
^ permalink raw reply
* Re: git pull is slow
From: Martin Langhoff @ 2008-07-10 15:13 UTC (permalink / raw)
To: Stephan Hennig; +Cc: git
In-Reply-To: <g5570s$d5m$1@ger.gmane.org>
On Thu, Jul 10, 2008 at 11:40 AM, Stephan Hennig <mailing_list@arcor.de> wrote:
> commits to the repository is fast (with git+ssh access method). Any
> ideas what's going on and how to make pulling faster?
When pushing you can use --thin to get a "thin pack" transfer, where
the delta-base is not transferred. Not sure how you request this from
git fetch these days though :-/ Search the list for "thin packs"
perhaps?
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH] apply: fix copy/rename breakage
From: Johannes Sixt @ 2008-07-10 15:22 UTC (permalink / raw)
To: Don Zickus; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <20080710140154.GN26957@redhat.com>
Don Zickus schrieb:
> On Wed, Jul 09, 2008 at 08:10:58PM -0700, Junio C Hamano wrote:
>> However, this "incremental" mode of patch application contradicts with the
>> way git rename/copy patches are fundamentally designed. When a git patch
>> talks about a file A getting modified, and a new file B created out of B,
>> like this:
>>
>> diff --git a/A b/A
>> --- a/A
>> +++ b/A
>> ... change text X here ...
>> diff --git a/A b/B
>> copy from A
>> copy to B
>> --- a/A
>> +++ b/B
>> ... change text Y here ...
>>
>> the second change to produce B does not depend on what is done to A with
>> the first change (this is explicitly done so for reviewability of
>> individual patches).
>>
>> With this patch, we disable the postimage record 'fn_table' when applying
>> a patch to produce new files out of existing file by copying to fix this
>> issue.
>
> Odd. I guess the way I read this workflow is
>
> apply change X to A, copy A' to B, apply change Y to B => B' now has changes X+Y
>
> But instead you are saying B' only has change Y because A is copied to B
> not A'.
>
> Regardless, it doesn't affect my workflow.
Oh, it does. It's a normal git diff where a copy was detected!
Don't let you distract by the word "incremental" and by the names A and B.
In the example above, the change X comes first because 'A' is sorted
before 'B'. If the roles of A and B were swapped, then you have this patch:
diff --git a/A b/A
copy from B
copy to A
--- a/A
+++ b/A
... change text Y here ...
diff --git a/A b/B
--- a/A
+++ b/B
... change text X here ...
See?
-- Hannes
^ permalink raw reply
* Re: git pull is slow
From: Petr Baudis @ 2008-07-10 15:28 UTC (permalink / raw)
To: Stephan Hennig; +Cc: git
In-Reply-To: <g5570s$d5m$1@ger.gmane.org>
Hi,
On Thu, Jul 10, 2008 at 04:40:17PM +0200, Stephan Hennig wrote:
> I am observing very large data transfers when pulling from the
> repository at <URL:http://repo.or.cz/w/wortliste.git>. This repository
> contains one 13 MB text file that compressed is roughly 3 MB large.
>
> While I'd expect pulling commits that change only a few lines of the
> large text file to result in a download of less than, say 10kB, git pull
> seems to transfer the complete, compressed file. I have observed this
> several times for different commits. On the other hand, pushing my own
> commits to the repository is fast (with git+ssh access method). Any
> ideas what's going on and how to make pulling faster?
do you use HTTP or native Git protocol for pulling? If HTTP, you have
to live with this, sorry - the automatic repacks will create a new pack
every time and you will have to redownload the whole history; I tried to
avoid this problem but in the end I had to bow down to the agressive
repacking strategy because the number of packs was getting out of hand.
It is technically possible to implement some alternative more
HTTP-friendly packing strategy, but this has always stayed only in idea
stage. If you want to implement something, repo.or.cz will become a glad
user. :-)
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: git pull is slow
From: Johannes Sixt @ 2008-07-10 15:30 UTC (permalink / raw)
To: Stephan Hennig; +Cc: git
In-Reply-To: <g5570s$d5m$1@ger.gmane.org>
Stephan Hennig schrieb:
> I am observing very large data transfers when pulling from the
> repository at <URL:http://repo.or.cz/w/wortliste.git>. This repository
> contains one 13 MB text file that compressed is roughly 3 MB large.
>
> While I'd expect pulling commits that change only a few lines of the
> large text file to result in a download of less than, say 10kB, git pull
> seems to transfer the complete, compressed file. I have observed this
> several times for different commits. On the other hand, pushing my own
> commits to the repository is fast (with git+ssh access method). Any
> ideas what's going on and how to make pulling faster?
Do you by any chance use a http URL to pull? Don't do that. Use git protocol.
-- Hannes
^ permalink raw reply
* Re: [JGIT PATCH 1/1] jgit: create a tag command
From: Mike Ralphson @ 2008-07-10 15:31 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, Marek Zawirski, git
In-Reply-To: <200807070116.39892.robin.rosenberg.lists@dewire.com>
2008/7/7 Robin Rosenberg <robin.rosenberg.lists@dewire.com>:
>
> This command allows us to create simple or annotated tags.
> PGP signed tags are not yet supported.
>
> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Apologies this will be whitespace damaged, but it's trivial.
diff --git a/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
index 110db6b..a215fbd 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/pgm/Tag.java
@@ -47,6 +47,8 @@ class Tag extends TextBuiltin {
String message = null;
String ref = "HEAD";
boolean force = false;
+ if (args.length == 0)
+ usage();
for (int i = 0; i < args.length; ++i) {
if (args[i].equals("-f")) {
force = true;
@@ -97,6 +99,6 @@ class Tag extends TextBuiltin {
}
private void usage() {
- throw die("Usage: -m message tag [head]");
+ throw die("Usage: [-m message] [-f] tag [head]");
}
}
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Loving the make_jgit stuff.
Mike
^ permalink raw reply related
* Re: THREADED_DELTA_SEARCH
From: Junio C Hamano @ 2008-07-10 15:34 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Git ML
In-Reply-To: <20080710075327.GD24819@artemis.madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> I'm using it in production for quite a long time now, and I wonder if
> there is any specific reason why it's not default. Debian activated it
> by default too a couple of weeks ago, which means that it's in
> production on quite a large scale, and there are no issues reported
> either. Would a patch making it default be accepted ? It's quite handy
> given that SMP machines are really pervasive nowadays…
There were two issues, IIRC.
(1) resulting pack could be suboptimal, due to delta-chain getting cut
betweeen the worker thread boundary.
(2) exploding memory use, suspected to be due to malloc pool
fragmentation under multithreading.
The former was only an issue with early iterations of the code and the
current code has much improved behaviour on this point, but I do not
recall the latter issue has been addressed.
^ permalink raw reply
* Re: git pull is slow
From: Stephan Hennig @ 2008-07-10 15:45 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt
In-Reply-To: <48762B27.90004@viscovery.net>
Johannes Sixt schrieb:
> Stephan Hennig schrieb:
>> I am observing very large data transfers when pulling from the
>> repository at <URL:http://repo.or.cz/w/wortliste.git>. This
>> repository contains one 13 MB text file that compressed is roughly
>> 3 MB large.
>
> Do you by any chance use a http URL to pull? Don't do that. Use git
> protocol.
No, I'm already using git+ssh.
Best regards,
Stephan Hennig
^ permalink raw reply
* Re: git pull is slow
From: Petr Baudis @ 2008-07-10 15:50 UTC (permalink / raw)
To: Stephan Hennig; +Cc: git, Johannes Sixt
In-Reply-To: <48762E8A.7070203@arcor.de>
On Thu, Jul 10, 2008 at 05:45:14PM +0200, Stephan Hennig wrote:
> Johannes Sixt schrieb:
> > Stephan Hennig schrieb:
> >> I am observing very large data transfers when pulling from the
> >> repository at <URL:http://repo.or.cz/w/wortliste.git>. This
> >> repository contains one 13 MB text file that compressed is roughly
> >> 3 MB large.
> >
> > Do you by any chance use a http URL to pull? Don't do that. Use git
> > protocol.
>
> No, I'm already using git+ssh.
Oh, ok. By the way, how long are you hitting this issue? Just today,
I have upgraded the chroot Git from some anonymous 2007-12-08 version
to the almost-latest #next.
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Re: [PATCH] cherry: cache patch-ids to avoid repeating work
From: Johannes Schindelin @ 2008-07-10 15:56 UTC (permalink / raw)
To: Geoffrey Irving; +Cc: Junio C Hamano, git@vger.kernel.org
In-Reply-To: <7f9d599f0807100733s4435a9bga89749f2f6e10cf@mail.gmail.com>
Hi,
On Thu, 10 Jul 2008, Geoffrey Irving wrote:
> On Thu, Jul 10, 2008 at 7:28 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Thu, 10 Jul 2008, Geoffrey Irving wrote:
> >
> >> On Wed, Jul 9, 2008 at 8:34 PM, Geoffrey Irving <irving@naml.us> wrote:
> >>
> >> > Note: there are at least two "holes" in this code. First, it is
> >> > impossible to verify the validity of the entries (this is
> >> > impossible to fix). Second, it is possible to write a malicious
> >> > patch-id-cache file that causes git-cherry to go into an infinite
> >> > loop. Fixing the loop requires either traversing every entry on
> >> > load (bad) or adding a second loop termination condition to
> >> > find_helper. Since looping forever is better than returning
> >> > incorrect results, I figured fixing the weaker hole would just
> >> > result in a false sense of security.
> >>
> >> Oops: avoiding the infinite loop only requires reading expected O(1)
> >> entries on load, so I can fix that if you like. It would only be all
> >> of them if it actually did detect the infinite loop.
> >
> > I have to admit that you lost me there. AFAIR the patch-id cache is a
> > simple commit->patch_id store, right? Then there should be no way to
> > get an infinite loop.
>
> If every entry is nonnull, find_helper loops forever.
Ah, that is because you did not use that part of my implementation. My
hash did not wrap.
> > Besides, this is a purely local cache, no? Never to be transmitted...
> > So not much chance of a malicious attack, except if you allow write
> > access to your local repository, in which case you are endangered no
> > matter what.
>
> Yep, that's why it's only a hole in quotes, and why I didn't fix it.
Then it is not a hole.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] apply: fix copy/rename breakage
From: Don Zickus @ 2008-07-10 15:43 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git, Linus Torvalds
In-Reply-To: <48762919.6070902@viscovery.net>
On Thu, Jul 10, 2008 at 05:22:01PM +0200, Johannes Sixt wrote:
> >> With this patch, we disable the postimage record 'fn_table' when applying
> >> a patch to produce new files out of existing file by copying to fix this
> >> issue.
> >
> > Odd. I guess the way I read this workflow is
> >
> > apply change X to A, copy A' to B, apply change Y to B => B' now has changes X+Y
> >
> > But instead you are saying B' only has change Y because A is copied to B
> > not A'.
> >
> > Regardless, it doesn't affect my workflow.
>
> Oh, it does. It's a normal git diff where a copy was detected!
>
> Don't let you distract by the word "incremental" and by the names A and B.
> In the example above, the change X comes first because 'A' is sorted
> before 'B'. If the roles of A and B were swapped, then you have this patch:
>
> diff --git a/A b/A
> copy from B
> copy to A
> --- a/A
> +++ b/A
> ... change text Y here ...
> diff --git a/A b/B
> --- a/A
> +++ b/B
> ... change text X here ...
>
> See?
Yes, thank you!
Cheers,
Don
^ permalink raw reply
* [PATCH] tutorial: prefix the prompts with names alice or bob, to make it clear who is doing what
From: Ian Katz @ 2008-07-10 16:12 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.DEB.1.00.0807101654080.18205@racer>
---
Documentation/gittutorial.txt | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index e71b561..e4248b6 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -274,7 +274,7 @@ same machine, wants to contribute.
Bob begins with:
------------------------------------------------
-$ git clone /home/alice/project myrepo
+bob$ git clone /home/alice/project myrepo
------------------------------------------------
This creates a new directory "myrepo" containing a clone of Alice's
@@ -285,7 +285,7 @@ Bob then makes some changes and commits them:
------------------------------------------------
(edit files)
-$ git commit -a
+bob$ git commit -a
(repeat as necessary)
------------------------------------------------
@@ -293,8 +293,8 @@ When he's ready, he tells Alice to pull changes from the rep
ository
at /home/bob/myrepo. She does this with:
------------------------------------------------
-$ cd /home/alice/project
-$ git pull /home/bob/myrepo master
+alice$ cd /home/alice/project
+alice$ git pull /home/bob/myrepo master
------------------------------------------------
This merges the changes from Bob's "master" branch into Alice's
@@ -312,7 +312,7 @@ again. By defining 'remote' repository shorthand, you can m
ake
it easier:
------------------------------------------------
-$ git remote add bob /home/bob/myrepo
+alice$ git remote add bob /home/bob/myrepo
------------------------------------------------
With this, Alice can perform the first operation alone using the
@@ -320,7 +320,7 @@ With this, Alice can perform the first operation alone using
the
using:
-------------------------------------
-$ git fetch bob
+alice$ git fetch bob
-------------------------------------
Unlike the longhand form, when Alice fetches from Bob using a
@@ -329,7 +329,7 @@ fetched is stored in a remote tracking branch, in this case
`bob/master`. So after this:
-------------------------------------
-$ git log -p master..bob/master
+alice$ git log -p master..bob/master
-------------------------------------
shows a list of all the changes that Bob made since he branched from
@@ -339,14 +339,14 @@ After examining those changes, Alice
could merge the changes into her master branch:
-------------------------------------
-$ git merge bob/master
+alice$ git merge bob/master
-------------------------------------
This `merge` can also be done by 'pulling from her own remote
tracking branch', like this:
-------------------------------------
-$ git pull . remotes/bob/master
+alice$ git pull . remotes/bob/master
-------------------------------------
Note that git pull always merges into the current branch,
@@ -355,7 +355,7 @@ regardless of what else is given on the command line.
Later, Bob can update his repo with Alice's latest changes using
-------------------------------------
-$ git pull
+bob$ git pull
-------------------------------------
Note that he doesn't need to give the path to Alice's repository;
@@ -364,7 +364,7 @@ repository in the repository configuration, and that locatio
n is
used for pulls:
-------------------------------------
-$ git config --get remote.origin.url
+bob$ git config --get remote.origin.url
/home/alice/project
-------------------------------------
@@ -376,7 +376,7 @@ Git also keeps a pristine copy of Alice's master branch unde
r the
name "origin/master":
-------------------------------------
-$ git branch -r
+bob$ git branch -r
origin/master
-------------------------------------
@@ -384,7 +384,7 @@ If Bob later decides to work from a different host, he can s
till
perform clones and pulls using the ssh protocol:
-------------------------------------
-$ git clone alice.org:/home/alice/project myrepo
+bob$ git clone alice.org:/home/alice/project myrepo
-------------------------------------
Alternatively, git has a native protocol, or can use rsync or http;
--
1.5.3.7
^ permalink raw reply related
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