* [PATCH] Teach merge.log to "git-merge" again
From: Junio C Hamano @ 2008-07-10 7:50 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
The command forgot the configuration variable when rewritten in C.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-merge.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index 821edcd..bc3f921 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -519,8 +519,10 @@ int git_merge_config(const char *k, const char *v, void *cb)
else if (!strcmp(k, "pull.twohead"))
return git_config_string(&pull_twohead, k, v);
else if (!strcmp(k, "pull.octopus"))
return git_config_string(&pull_octopus, k, v);
+ else if (!strcmp(k, "merge.log") || !strcmp(k, "merge.summary"))
+ option_log = git_config_bool(k, v);
return git_diff_ui_config(k, v, cb);
}
static int read_tree_trivial(unsigned char *common, unsigned char *head,
^ permalink raw reply related
* THREADED_DELTA_SEARCH
From: Pierre Habouzit @ 2008-07-10 7:53 UTC (permalink / raw)
To: Git ML
[-- Attachment #1: Type: text/plain, Size: 589 bytes --]
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…
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: THREADED_DELTA_SEARCH
From: Johannes Sixt @ 2008-07-10 8:01 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Git ML
In-Reply-To: <20080710075327.GD24819@artemis.madism.org>
Pierre Habouzit schrieb:
> 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…
Don't forget to turn it off in the MINGW section in the Makefile since we
don't have pthreads on Windows.
-- Hannes
^ permalink raw reply
* [PATCH] Add testcase for merge.log
From: Miklos Vajna @ 2008-07-10 8:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7ibuqisc.fsf@gitster.siamese.dyndns.org>
Make sure that the merge.log boolean config setting is the same as --log
and --no-log.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Thu, Jul 10, 2008 at 12:50:59AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> The command forgot the configuration variable when rewritten in C.
Thanks. Here is a testcase.
t/t7600-merge.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index dfddd86..a3c17a9 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -456,6 +456,17 @@ test_expect_success 'merge log message' '
verify_diff msg.log msg.act "[OOPS] bad merge log message"
'
+test_expect_success 'merge log message (from config)' '
+ git reset --hard c0 &&
+ git merge c2 &&
+ git show -s --pretty=format:%b HEAD >msg.act &&
+ verify_diff msg.nolog msg.act "[OOPS] bad merge log message" &&
+ git config merge.log true &&
+ git merge c3 &&
+ git show -s --pretty=format:%b HEAD >msg.act &&
+ verify_diff msg.log msg.act "[OOPS] bad merge log message"
+'
+
test_debug 'gitk --all'
test_done
--
1.5.6.2.450.g8d367.dirty
^ permalink raw reply related
* Re: [PATCH] Fix problem with authentification on http repository.
From: Jeff King @ 2008-07-10 8:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Mike Hommey, jean.guyader, git, Jean Guyader
In-Reply-To: <7vk5fuqjn8.fsf@gitster.siamese.dyndns.org>
On Thu, Jul 10, 2008 at 12:32:27AM -0700, Junio C Hamano wrote:
> > Wouldn't there still be a race condition for publicly broadcasting your
> > password via ps?
>
> In addition, I think on some Unices overwriting argv[0] does not have the
> effect Dscho is aiming for.
I thought so, too, but I couldn't find any mention of it online. For
curiosity's sake, do you happen to know offhand any platform where this
doesn't work (of course, Dscho is really proposing overwriting argv[i],
but I don't know if that makes a difference to the portability)?
-Peff
^ permalink raw reply
* Re: THREADED_DELTA_SEARCH
From: Jakub Narebski @ 2008-07-10 8:51 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…
Doues our ./configure detects if it makes sense (i.e. if it is SMP
machine)? What is the cost of THREADED_DELTA_SEARCH for single processor
single core machine?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Bug: /usr/local/bin/git-daemon starts /usr/sbin/git-upload-pack?
From: Jeff King @ 2008-07-10 8:59 UTC (permalink / raw)
To: Brian Foster; +Cc: Git Mailing List, Jan Wielemaker
In-Reply-To: <200807100932.06569.brian.foster@innova-card.com>
On Thu, Jul 10, 2008 at 09:32:06AM +0200, Brian Foster wrote:
> GIT_TRACE=/tmp/LOG-git-daemon
>
> gave some valuable clews. I'm unaware of GIT_TRACE
> being documented. I also concur it's annoying neither
It's in git(1).
-Peff
^ permalink raw reply
* Re: THREADED_DELTA_SEARCH
From: Pierre Habouzit @ 2008-07-10 9:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git ML
In-Reply-To: <m3hcaydswg.fsf@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1172 bytes --]
On Thu, Jul 10, 2008 at 08:51:06AM +0000, Jakub Narebski wrote:
> 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…
>
> Doues our ./configure detects if it makes sense (i.e. if it is SMP
> machine)?
I don't know if it does, but it wouldn't make sense for distros.
> What is the cost of THREADED_DELTA_SEARCH for single processor
> single core machine?
Threading has to be enabled in the configuration, and there is a
--thread=0 mode that enables autodetection of the number of CPUs online.
so there is no overhead for single CPU systems.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] bisect: test merge base if good rev is not an ancestor of bad rev
From: Johannes Schindelin @ 2008-07-10 10:04 UTC (permalink / raw)
To: Christian Couder; +Cc: Junio C Hamano, Michael Haggerty, Jeff King, git
In-Reply-To: <20080710054152.b051989c.chriscool@tuxfamily.org>
Hi,
On Thu, 10 Jul 2008, Christian Couder wrote:
> Before this patch, "git bisect", when it was given some good revs that
> are not ancestor of the bad rev, didn't check if the merge bases were
> good. "git bisect" just supposed that the user knew what he was doing,
> and that, when he said the revs were good, he knew that it meant that
> all the revs in the history leading to the good revs were also
> considered good.
Well, it is not completely relying on the user.
The common scenario before a bisect is this: something used to work _all
the time_, and all of a sudden, it does not anymore.
So it is expected that there is no fix in the history. Not in the current
branch, not in the "good" branch, not wherever.
In that case, you are literally guaranteed that all ancestors of a good
commit are good, too, because if there was a bad one, there would be a
fix, too.
The whole idea of "bisect" relies on that idea, that any ancestor of a
good commit is good. Otherwise you'd have to check the commits one by
one, not in a bisecting manner.
Ciao,
Dscho
^ permalink raw reply
* 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
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