* diffcore-rename performance mode
From: Jeff King @ 2007-09-18 8:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[this is a resend of some comments I made deep in another thread on
rename limiting; I wanted to get your comments, Junio, but I was afraid
you didn't see it buried in the mess. If you have already read it and
have nothing to say, just tell me to shut up.
I was able to get 1000% speedup on a (perhaps pathological) diff, and I
suspect there may be more speedups possible in the spanhash lookups. So
I think it's worth pursuing.]
Hmm. Actually, doing some profiling, it looks like about 75% of the time
is spent not in the O(n^2) comparison, but in generating the hash
fingerprints of each file.
There seems to be a serious performance problem in diffcore-rename.
There is infrastructure to cache the "cnt_data" member of each filespec,
but it never gets used because we immediately free the filespec data
after use. Oops.
With this patch:
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 6bde439..531a844 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -362,10 +362,7 @@ void diffcore_rename(struct diff_options *options)
m->score = estimate_similarity(one, two,
minimum_score);
m->name_score = basename_same(one, two);
- diff_free_filespec_data(one);
}
- /* We do not need the text anymore */
- diff_free_filespec_data(two);
dst_cnt++;
}
/* cost matrix sorted by most to least similar pair */
My 20-minute diff becomes a 2-minute diff. The downside is that the
memory usage is much increased (for obvious reasons, it should increase
by the dataset size, since we are keeping pointers to the data around --
in my case, around 1G extra). However, keeping around _just_ the
cnt_data caused only about 100M of extra memory consumption (and gave
the same performance boost).
Of course, 2 minutes for a git-status is still way too slow, so there we
might still need a limiter. It also looks like 57% of my time is spent
in spanhash_find, and another 29% in diffcore_count_changes.
The spanhash data structure is a bit confusing. At first, it looked like
we were doing a linear search for a matching hash, but it's not quite,
since we seem to start at some magic spot based on the hashval we're
looking up.
But it seems to be an array of (hash, count) pairs for each file. Is
there a reason not to use a hash table mapping hash -> count? That would
make insertion and lookup O(1), presumably at the cost of a bit more
memory (since each filespec would have the full table).
Junio, can you shed some light on that decision?
-Peff
^ permalink raw reply related
* [PATCH] git-svnimport: Use separate arguments in the pipe for git-rev-parse
From: Matthias Urlichs @ 2007-09-18 7:47 UTC (permalink / raw)
To: Dan Libby; +Cc: git
In-Reply-To: <200709171333.48331.danda@osc.co.cr>
Signed-Off-By: Matthias Urlichs <smurf@smurf.noris.de>
---
Please tell me whether that works for you.
Somebody else, preferably its author, can fix git-svn. ;-)
diff --git a/git-svnimport.perl b/git-svnimport.perl
index d3ad5b9..aa5b3b2 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -633,7 +633,7 @@ sub commit {
my $rev;
if($revision > $opt_s and defined $parent) {
- open(H,"git-rev-parse --verify $parent |");
+ open(H,'-|',"git-rev-parse","--verify",$parent);
$rev = <H>;
close(H) or do {
print STDERR "$revision: cannot find commit '$parent'!\n";
--
1.5.2.5
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"Could a being create the fifty billion galaxies, each with two hundred
billion stars, then rejoice in the smell of burning goat flesh?"
[Ron Patterson]
^ permalink raw reply related
* [PATCH] git-push: documentation and tests for pushing only branches
From: Jeff King @ 2007-09-18 8:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Commit 098e711e caused git-push to match only branches when
considering which refs to push. This patch updates the
documentation accordingly and adds a test for this behavior.
Signed-off-by: Jeff King <peff@peff.net>
---
We had discussed this behavior in April, and I worked up an
implementation and test then. We ended up not using it, but your later
commit introduced the same behavior. So here are the supplementary
changes from my original, which still apply (I have verified that the
test goes from failure to success with 098e711e).
Documentation/git-push.txt | 4 ++--
Documentation/git-send-pack.txt | 4 ++--
t/t5400-send-pack.sh | 10 ++++++++++
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 7b8e075..6bc559d 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -48,7 +48,7 @@ even if it does not result in a fast forward update.
Note: If no explicit refspec is found, (that is neither
on the command line nor in any Push line of the
corresponding remotes file---see below), then all the
-refs that exist both on the local side and on the remote
+heads that exist both on the local side and on the remote
side are updated.
+
`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
@@ -61,7 +61,7 @@ the remote repository.
\--all::
Instead of naming each ref to push, specifies that all
- refs be pushed.
+ refs under `$GIT_DIR/refs/heads/` be pushed.
\--tags::
All refs under `$GIT_DIR/refs/tags` are pushed, in
diff --git a/Documentation/git-send-pack.txt b/Documentation/git-send-pack.txt
index 205bfd2..3271e88 100644
--- a/Documentation/git-send-pack.txt
+++ b/Documentation/git-send-pack.txt
@@ -32,7 +32,7 @@ OPTIONS
\--all::
Instead of explicitly specifying which refs to update,
- update all refs that locally exist.
+ update all heads that locally exist.
\--force::
Usually, the command refuses to update a remote ref that
@@ -70,7 +70,7 @@ With '--all' flag, all refs that exist locally are transferred to
the remote side. You cannot specify any '<ref>' if you use
this flag.
-Without '--all' and without any '<ref>', the refs that exist
+Without '--all' and without any '<ref>', the heads that exist
both on the local side and on the remote side are updated.
When one or more '<ref>' are specified explicitly, it can be either a
diff --git a/t/t5400-send-pack.sh b/t/t5400-send-pack.sh
index 6c8767e..57c6397 100755
--- a/t/t5400-send-pack.sh
+++ b/t/t5400-send-pack.sh
@@ -113,4 +113,14 @@ test_expect_success \
! git diff .git/refs/heads/master victim/.git/refs/heads/master
'
+test_expect_success \
+ 'pushing does not include non-head refs' '
+ mkdir parent && cd parent &&
+ git-init && touch file && git-add file && git-commit -m add &&
+ cd .. &&
+ git-clone parent child && cd child && git-push --all &&
+ cd ../parent &&
+ git-branch -a >branches && ! grep -q origin/master branches
+'
+
test_done
--
1.5.3.1.986.g4c9eb
^ permalink raw reply related
* Re: [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-18 8:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Eric Wong, Andreas Ericsson, Johannes Schindelin, Chris Shoemaker,
git
In-Reply-To: <7v4phsxy55.fsf@gitster.siamese.dyndns.org>
On 9/18/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > On 9/18/07, Eric Wong <normalperson@yhbt.net> wrote:
> >> Would automatically enabling --no-ff when it detects merging of two (or
> >> more) SVN branches be a good thing?
> >
> > I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.
>
> That unfortunately does not solve the problem.
>
The problem we're trying to solve is to somehow avoid fast-forward
merges between git-svn branches, right?
I don't think it's a big issue in itself. If a fast-forward occurs,
what will happen is basically that git-svn will guess the wrong
upstream branch and then proceed to do nothing [1]. The user can
always recover from this state with 'git-reset' and 'git-merge
--no-ff'. So I think the result of a fast-forward merge between
git-svn branches is annoying, but not fatal [2].
But a closely related issue is that git-svn shouldn't dcommit to the
wrong upstream (even in the case of a fast-forward merge). We need a
way to explicitly show the link between the local and remote svn
branch (something like .git/config perhaps).
--
larsh
[1] If the merged-in branch had local commits they will be 'dcommited'
to the correct upstream of the merged-in branch, which isn't to bad
[2] if git-svn could be fixed to handle even the ff case, someone
could actually prefer to get the 'cherry-picked' history in
subversion. I don't, hence my --no-ff patch, but I'm not at all
certain this should be _forced_ on git-svn branches.
^ permalink raw reply
* Re: [PATCH 0/3] the return of the strbuf
From: Junio C Hamano @ 2007-09-18 7:56 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070917125211.GA18176@artemis.corp>
Thanks, will queue in 'pu' and hopefully soon move to 'next'.
^ permalink raw reply
* Re: [EGIT PATCH] Add feature and plugin.
From: Andreas Ericsson @ 2007-09-18 7:43 UTC (permalink / raw)
To: Ben Konrath; +Cc: git
In-Reply-To: <20070917185310.GA6042@toast.toronto.redhat.com>
Ben Konrath wrote:
> Hi,
>
> I made a feature and associated branding plugin for Egit. Including
> these two plugins allows us to build Egit for Fedora but it also makes
> it easy to create an update site for Egit.
> These two plugins also add an
> entry for Egit in Help -> About Eclipse -> Feature Details.
>
When you start writing "also" in your commit messages, it's a pretty good
sign that you should have made many smaller commits rathern than one large.
Aside from that, I don't know enough about eclipse, java or xml to be of
any assistance, although I appreciate the efforts put into this.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 1/1] git-send-email: Add a --suppress-all option
From: Andreas Ericsson @ 2007-09-18 7:40 UTC (permalink / raw)
To: Felipe Balbi; +Cc: git, Felipe Balbi
In-Reply-To: <11900540373215-git-send-email-felipebalbi@users.sourceforge.net>
Felipe Balbi wrote:
> From: Felipe Balbi <felipe.lima@indt.org.br>
>
> This patch adds a --suppress-all option to avoid sending emails
> to everybody but the ones listed by --to option.
>
To my minds eye, --suppress-all is equivalent to --dry-run. Could you
rename it to "--cc-nobody" or some such?
On a side-note, I've never really understood why git-send-email *by default*
sends to a bazillion people. Does anybody ever use it without suppressing
most of the CC targets?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Sam Vilain @ 2007-09-18 7:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Lars Hjemli, Eric Wong, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <7v4phsxy55.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
>> On 9/18/07, Eric Wong <normalperson@yhbt.net> wrote:
>>> Would automatically enabling --no-ff when it detects merging of two (or
>>> more) SVN branches be a good thing?
>> I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.
>
> That unfortunately does not solve the problem.
I think we 'just' need to fix pushing merges back to SVN - so that they
properly set Subversion 1.5+ (and possibly SVK) merge attributes - and
if it is ambiguous which branch to push to, force the user to decide.
Sam.
^ permalink raw reply
* [PATCH] Drop UTF-8 characters in manual pages
From: Mike Hommey @ 2007-09-18 7:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Mike Hommey
The default character encoding for english manual pages is ISO8859-1, so
UTF-8 characters are just displayed as their sequence of bytes, which is
not very appealing.
Signed-off-by: Mike Hommey <mh@glandium.org>
---
Documentation/git-lost-found.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-lost-found.txt b/Documentation/git-lost-found.txt
index e48607f..82b0699 100644
--- a/Documentation/git-lost-found.txt
+++ b/Documentation/git-lost-found.txt
@@ -65,7 +65,7 @@ $ git rev-parse not-lost-anymore
Author
------
-Written by Junio C Hamano 濱野 純 <junkio@cox.net>
+Written by Junio C Hamano <junkio@cox.net>
Documentation
--------------
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH] contrib/fast-import: add perl version of simple example
From: Jeff King @ 2007-09-18 7:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
In-Reply-To: <20070918072627.GB3506@coredump.intra.peff.net>
On Tue, Sep 18, 2007 at 03:26:27AM -0400, Jeff King wrote:
> This is based on the git-import.sh script, but is a little
Sorry, this was meant to be 2/2 (in case you were breathless in
anticipation for the second part of the series).
-Peff
^ permalink raw reply
* [PATCH] contrib/fast-import: add perl version of simple example
From: Jeff King @ 2007-09-18 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce
This is based on the git-import.sh script, but is a little
more robust and efficient. More importantly, it should
serve as a quick template for interfacing fast-import with
perl scripts.
Signed-off-by: Jeff King <peff@peff.net>
---
contrib/fast-import/git-import.perl | 64 +++++++++++++++++++++++++++++++++++
1 files changed, 64 insertions(+), 0 deletions(-)
create mode 100755 contrib/fast-import/git-import.perl
diff --git a/contrib/fast-import/git-import.perl b/contrib/fast-import/git-import.perl
new file mode 100755
index 0000000..f9fef6d
--- /dev/null
+++ b/contrib/fast-import/git-import.perl
@@ -0,0 +1,64 @@
+#!/usr/bin/perl
+#
+# Performs an initial import of a directory. This is the equivalent
+# of doing 'git init; git add .; git commit'. It's a little slower,
+# but is meant to be a simple fast-import example.
+
+use strict;
+use File::Find;
+
+my $USAGE = 'Usage: git-import branch import-message';
+my $branch = shift or die "$USAGE\n";
+my $message = shift or die "$USAGE\n";
+
+chomp(my $username = `git config user.name`);
+chomp(my $email = `git config user.email`);
+die 'You need to set user name and email'
+ unless $username && $email;
+
+system('git init');
+open(my $fi, '|-', qw(git fast-import --date-format=now))
+ or die "unable to spawn fast-import: $!";
+
+print $fi <<EOF;
+commit refs/heads/$branch
+committer $username <$email> now
+data <<MSGEOF
+$message
+MSGEOF
+
+EOF
+
+find(
+ sub {
+ if($File::Find::name eq './.git') {
+ $File::Find::prune = 1;
+ return;
+ }
+ return unless -f $_;
+
+ my $fn = $File::Find::name;
+ $fn =~ s#^.\/##;
+
+ open(my $in, '<', $_)
+ or die "unable to open $fn: $!";
+ my @st = stat($in)
+ or die "unable to stat $fn: $!";
+ my $len = $st[7];
+
+ print $fi "M 644 inline $fn\n";
+ print $fi "data $len\n";
+ while($len > 0) {
+ my $r = read($in, my $buf, $len < 4096 ? $len : 4096);
+ defined($r) or die "read error from $fn: $!";
+ $r > 0 or die "premature EOF from $fn: $!";
+ print $fi $buf;
+ $len -= $r;
+ }
+ print $fi "\n";
+
+ }, '.'
+);
+
+close($fi);
+exit $?;
--
1.5.3.1.967.g6bb01
^ permalink raw reply related
* [PATCH 1/2] contrib/fast-import: add simple shell example
From: Jeff King @ 2007-09-18 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Shawn O. Pearce, Nguyen Thai Ngoc Duy
From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
This example just puts a directory under git control. It is
significantly slower than using the git tools directly, but
hopefully shows a bit how fast-import works.
[jk: added header comments]
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
---
contrib/fast-import/git-import.sh | 38 +++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
create mode 100755 contrib/fast-import/git-import.sh
diff --git a/contrib/fast-import/git-import.sh b/contrib/fast-import/git-import.sh
new file mode 100755
index 0000000..0ca7718
--- /dev/null
+++ b/contrib/fast-import/git-import.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+#
+# Performs an initial import of a directory. This is the equivalent
+# of doing 'git init; git add .; git commit'. It's a lot slower,
+# but is meant to be a simple fast-import example.
+
+if [ -z "$1" -o -z "$2" ]; then
+ echo "Usage: git-import branch import-message"
+ exit 1
+fi
+
+USERNAME="$(git config user.name)"
+EMAIL="$(git config user.email)"
+
+if [ -z "$USERNAME" -o -z "$EMAIL" ]; then
+ echo "You need to set user name and email"
+ exit 1
+fi
+
+git init
+
+(
+ cat <<EOF
+commit refs/heads/$1
+committer $USERNAME <$EMAIL> now
+data <<MSGEOF
+$2
+MSGEOF
+
+EOF
+ find * -type f|while read i;do
+ echo "M 100644 inline $i"
+ echo data $(stat -c '%s' "$i")
+ cat "$i"
+ echo
+ done
+ echo
+) | git fast-import --date-format=now
--
1.5.3.1.967.g6bb01
^ permalink raw reply related
* Re: State of Perforce importing.
From: Sam Vilain @ 2007-09-18 7:27 UTC (permalink / raw)
To: David Brown; +Cc: Git
In-Reply-To: <20070917193027.GA24282@old.davidb.org>
David Brown wrote:
> I'd like to track a lot of code living in a Perforce repository, so I've
> been playing with 'git-p4.py'. Is the one in the contrib/fast-import
> directory the latest version, or is there a better place.
I'm pretty close to giving a newer one a spin, that actually imports
from the raw perforce back-end files without needing the perforce
server. I am hoping that this should give a very clean import and will
be very fast and efficient, sending files that share ancestry to gfi in
sequence so that the on-the-fly delta system works.
If you're interested, take a look at
http://utsl.gen.nz/gitweb/?p=git-p4raw;a=summary. Expect the commands
that say "WIP" to be rebased :-). It requires Postgres - I haven't yet
re-written the SQL queries that step outside of MySQL's little box.
It could possibly be adapted to use the p4 client (though I'd expect
that to be relatively slow per-revision), and possibly be extended to be
bidirectional as all of the upstream change number information is
recorded, a la git-svn.
Sam.
^ permalink raw reply
* Re: commit summary, --pretty=short and other tools
From: Andreas Ericsson @ 2007-09-18 7:19 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: Mike Hommey, git
In-Reply-To: <55887C88-8523-4839-8B91-236256A5E893@lrde.epita.fr>
Benoit SIGOURE wrote:
>
> My opinion is that it would be better to keep the first line and never
> ever rewrite the commit messages.
>
I've had reason to ponder this quite a lot, as I've imported 15 repos from
CVS and SVN where the commit authors did not follow the git-recommended way
of doing things, but rather put everything as one paragraph, usually without
linebreaks, in the commit message.
>From what I've read from those rather horrid commit-messages so far, it's
usually correct to grab the first sentence in case the empty line isn't
there, so:
const char *find_commit_subject_end(const char *commit_msg)
{
const char *dot, *paragraph_end;
paragraph_end = strstr(commit_msg, "\n\n");
dot = strchr(commit_msg, '.');
return min_non_null(dot, paragraph_end);
}
would probably get it right very nearly always.
I'll submit a patch in 3 hours when I get my lunch, unless someone
beats me to it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: State of Perforce importing.
From: Simon Hausmann @ 2007-09-18 6:58 UTC (permalink / raw)
To: David Brown; +Cc: Git
In-Reply-To: <20070917193027.GA24282@old.davidb.org>
[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]
On Monday 17 September 2007 21:30:28 David Brown wrote:
> I'd like to track a lot of code living in a Perforce repository, so I've
> been playing with 'git-p4.py'. Is the one in the contrib/fast-import
> directory the latest version, or is there a better place.
This is indeed the latest version (on contrib/fast-import).
> So far, it is having a couple of problems:
>
> - The commit comment is empty. It doesn't seem to grab the Perforce
> description, and the user seems to be <a@b>.
This may be a problem with the python output of perforce. Can you run the
following command?
git-p4 debug change <a change number in your depot>
That should print a dictionary that has a 'desc' field containing the commit
comment/log and a 'user' field that has the perforce user name.
> - Every revision seems to check every file out of Perforce. This means
> that for the directory I want, every revision is going to take about
> 20 minutes.
For every revision only every _changed_ file is retrieved (using p4
print //path/file#revision).
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Junio C Hamano @ 2007-09-18 6:53 UTC (permalink / raw)
To: Lars Hjemli
Cc: Eric Wong, Junio C Hamano, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <8c5c35580709172312w55613a1bw8cc58b200c526fab@mail.gmail.com>
"Lars Hjemli" <hjemli@gmail.com> writes:
> On 9/18/07, Eric Wong <normalperson@yhbt.net> wrote:
>> Would automatically enabling --no-ff when it detects merging of two (or
>> more) SVN branches be a good thing?
>
> I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.
That unfortunately does not solve the problem.
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Eric Wong @ 2007-09-18 6:23 UTC (permalink / raw)
To: Lars Hjemli
Cc: Junio C Hamano, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <8c5c35580709172312w55613a1bw8cc58b200c526fab@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> wrote:
> On 9/18/07, Eric Wong <normalperson@yhbt.net> wrote:
> > Would automatically enabling --no-ff when it detects merging of two (or
> > more) SVN branches be a good thing?
>
> I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.
That still involves having to get the user to use something new to avoid
shooting themselves in the foot. Perhaps putting a
"test -d $GIT_DIR/svn" condition in front of the git-svn call I proposed
in git-merge would be alright.
If anybody else is thinking about 'git-svn rebase', this is completely
different. Using git-rebase alone doesn't allow git-svn users to shoot
themselves in the foot like git-merge does. 'git-svn rebase' only
serves to minimize typing and brain power needed to operate git-svn.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Lars Hjemli @ 2007-09-18 6:12 UTC (permalink / raw)
To: Eric Wong
Cc: Junio C Hamano, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <20070918005013.GA6368@muzzle>
On 9/18/07, Eric Wong <normalperson@yhbt.net> wrote:
> Would automatically enabling --no-ff when it detects merging of two (or
> more) SVN branches be a good thing?
I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.
--
larsh
^ permalink raw reply
* Re: [PATCH 0/3] the return of the strbuf
From: Shawn O. Pearce @ 2007-09-18 3:57 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070917133522.GD18176@artemis.corp>
Pierre Habouzit <madcoder@debian.org> wrote:
> On lun, sep 17, 2007 at 12:52:11 +0000, Pierre Habouzit wrote:
> > While getting rid of ->eof in strbuf (as it was somehow tasteless). It
> > made me aware of the fact that fast-import.c was using a custom buffer
> > implementation (I think that was the fourth if not the fifth). So here
> > is the series that eradicates it.
>
> Shawn: Johannes makes me remark that you are git-fast-import author,
> hence may want to be Cc-ed of that series, so here is a mail so that you
> don't miss the thread.
Thanks. The subject caught my attention. The patches look good and
fast-import is usually maintained by me applying them and Junio pulling
from my fast-import tree. I'm doing that now.
BTW, I haven't thanked you for doing this cleanup work. It really
is appreciated. The code is definately more readable in the end.
Thanks.
> The list: it's often hard to know who you should Cc on a given change,
> I use format.headers to force Junio and git@, but sometimes you want a
> different set of persons. I wonder if this could not be wired in the
> repository, as a .gitattribute extension ?
The Linux kernel folks were talking about this not too long ago
and the discussion spilled onto the git list when someone CC'd it
in the middle of the thread. If I recall correctly it ended off with
this is probably something that a build script should be doing, not
something Git should do natively, as the data is readily available
from tools like git-log.
Indeed in this case if you do:
$ git log --pretty=format:%an --since=6.months.ago -- fast-import.c \
| sort | uniq -c | sort -nr
14 Shawn O. Pearce
3 Pierre Habouzit
3 Junio C Hamano
2 Simon Hausmann
2 Alex Riesen
1 Theodore Ts'o
1 Sven Verdoolaege
1 Sami Farin
1 Nicolas Pitre
1 Luiz Fernando N. Capitulino
1 Dana L. How
So you'd probably want to CC me on stuff in that file. On the other hand
looking at something else that's much more important to Git:
$ git log --pretty=format:%an --since=6.months.ago -- builtin-pack-objects.c \
| sort | uniq -c | sort -nr
38 Nicolas Pitre
12 Junio C Hamano
4 Dana L. How
3 Martin Koegler
3 Linus Torvalds
3 Brian Downing
2 Theodore Ts'o
2 Dana How
1 Luiz Fernando N. Capitulino
1 Geert Bosch
1 Alex Riesen
I don't think anyone would argue that CC'ing Nico and Junio on all
sizeable pack-objects changes would be prudent. Dana too actually
as he has been active in here recently. Meanwhile I don't make
the 6 month cut. ;-)
The other alternative that men with real computing horsepower at
their disposal can ask is through git-blame:
$ git blame -C -C -w --porcelain builtin-pack-objects.c | grep 'author ' \
| sort | uniq -c | sort -nr
52 author Nicolas Pitre
39 author Junio C Hamano
22 author Linus Torvalds
6 author Shawn O. Pearce
6 author Dana L. How
3 author Martin Koegler
...
Again Nico scores very high (52 commits surviving in current `next`)
but so does Junio and Linus. The output of git-blame may actually
be a better indicator of who Junio likes to CC when changes are
made in this module.
Doing something like this automatically based on the filepaths shown
by `git diff --name-only $cmit^ $cmt` could be expensive in terms
of CPU time, and might offer little gain for an old hand who knows
where the maintainer boundaries tend to be, but it does really help
someone who is newer to the project and might not know who is the
best person to talk to.
--
Shawn.
^ permalink raw reply
* The git-gui Times - Volume Zero Edition Eight Dot Three
From: Shawn O. Pearce @ 2007-09-18 3:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
Recent Shortages at git-gui Times
---------------------------------
Unlike our sister publication ``The msysGit Herald'' the git-gui
Times is published on an apple stem. To conserve bits and bites
our editors try to use only short logs, as long logs are simply
too expensive with today's rising paper costs.
maint
-----
gitgui-0.8.3 has been tagged from the maint branch and published
on repo.or.cz
git://repo.or.cz/git-gui.git maint
http://repo.or.cz/r/git-gui.git maint
and we continue to thank Pasky for his publishing services. The
full list of changes since gitgui-0.8.2 (which shipped with git
1.5.3/1.5.3.1) is reprinted below:
Gerrit Pape (1):
git-gui: lib/index.tcl: handle files with % in the filename properly
Michele Ballabio (2):
git-gui: show unstaged symlinks in diff viewer
git-gui: handle "deleted symlink" diff marker
Shawn O. Pearce (13):
git-gui: Correct starting of git-remote to handle -w option
git-gui: Fix detaching current branch during checkout
git-gui: Properly set the state of "Stage/Unstage Hunk" action
git-gui: Disable Tk send in all git-gui sessions
git-gui: Avoid use of libdir in Makefile
git-gui: Assume untracked directories are Git submodules
git-gui: Trim trailing slashes from untracked submodule names
git-gui: Don't delete send on Windows as it doesn't exist
git-gui: Make backporting changes from i18n version easier
git-gui: Font chooser to handle a large number of font families
git-gui: Provide 'uninstall' Makefile target to undo an installation
git-gui: Paper bag fix "Commit->Revert" format arguments
git-gui: Disable native platform text selection in "lists"
We hope these will appear on a mainstream git near you.
master
------
In addition to the above fixes the master branch has collected a few
items since the last edition of ``The git-gui Times''. The editors
would not mind if this list was larger in the next edition, but can't
promise anything in advance of it being typeset for publication.
Letters to the editor in the form of patches are always welcome.
git://repo.or.cz/git-gui.git master
http://repo.or.cz/r/git-gui.git master
Harri Ilari Tapio Liusvaara (1):
git-gui: Disambiguate "commit"
Michele Ballabio (1):
git-gui: add some strings to translation
Shawn O. Pearce (3):
git-gui: Document the new i18n context support
git-gui: Make the tree browser also use lightgray selection
git-gui: Paper bag fix missing translated strings
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/8] repack -A -d: use --keep-unreachable when repacking
From: Shawn O. Pearce @ 2007-09-18 3:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0709171027400.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 17 Sep 2007, Junio C Hamano wrote:
>
> > -USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--window-memory=N] [--depth=N]'
> > +USAGE='[-a|-A] [-d] [-f] [-l] [-n] [-q] [--max-pack-size=N] [--window=N] [--window-memory=N] [--depth=N]'
>
> Would "[-a] [-A]" not be better? In other usage lines, we have the "|"
> for alternative forms of the _same_ option, like "[-m|--merge]".
>
> > + -A) all_into_one=t
> > + keep_unreachable=t ;;
>
> Why not "keep_unreachable=--keep-unreachable" and use "$args
> $keep_unreachable" later?
I agree. Aside from the above and my other reply about editing
pack_name in place to test the .keep file I'm happy with this series.
I know the automatic GC thing has been a hot topic in the past with
various parties on different sides of the fence. I think this is
a pretty reasonable implementation that actually is a fairly good
comprimise between the two sides.
Thanks Junio.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 8/8] git-gc --auto: run "repack -A -d -l" as necessary.
From: Shawn O. Pearce @ 2007-09-18 2:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1190018716666-git-send-email-gitster@pobox.com>
Junio C Hamano <gitster@pobox.com> wrote:
> +static int too_many_packs(void)
> +{
> + struct packed_git *p;
> + int cnt;
> +
> + if (gc_auto_pack_limit <= 0)
> + return 0;
> +
> + for (cnt = 0, p = packed_git; p; p = p->next) {
> + char *suffix;
> + int keep;
> + if (!p->pack_local)
> + continue;
> + suffix = p->pack_name + strlen(p->pack_name) - 5;
> + if (memcmp(suffix, ".pack", 6))
> + continue;
> + memcpy(suffix, ".keep", 6);
> + keep = access(p->pack_name, F_OK) && (errno == ENOENT);
> + memcpy(suffix, ".pack", 6);
*rubs eyes* Am I reading that right? You are modifying pack_name
in the middle of this function? WHY is pack_name not const char*?
*sigh*. I'd NEVER consider doing that. Not in a million years.
Because someday someone is going to make a change that's going to
break that somehow, like by jumping out of this loop early and not
fixing pack_name up first.
Yea, sure, there's no way today that this would fail. But I like
to think that some poor sap is going to have to read my code after
I write it and that they should not be forced to deal with stuff
like this when such a time comes.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-merge: add option --no-ff
From: Eric Wong @ 2007-09-18 1:39 UTC (permalink / raw)
To: Junio C Hamano
Cc: Lars Hjemli, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <7vk5qoye2t.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > Would automatically enabling --no-ff when it detects merging of two (or
> > more) SVN branches be a good thing? We can add scripting support to
> > git-svn for detecting if any given commit is really from SVN or not.
> > Then we could do something like this in git-merge
> >
> > ---------------------------- 8< --------------------------------
> > if git-svn test-svn-commits "$@"
> > then
> > no_ff=t
> > no_fast_forward_strategies=$all_strategies
> > fi
> > ---------------------------- 8< --------------------------------
>
> Yuck, do I understand you correctly? Are you talking about
> adding dependency on git-svn to git-merge?
It could be another simple independent script, then. git-svn isn't
installed on most distros when git is, so it won't always work...
--
Eric Wong
^ permalink raw reply
* [PATCH 4/4] Make git-pull give hints on what to do when there is no branch to merge from
From: Federico Mena Quintero @ 2007-09-18 1:12 UTC (permalink / raw)
To: git
In-Reply-To: <1190077493.22387.54.camel@cacharro.xalalinux.org>
Signed-off-by: Federico Mena Quintero <federico@gnu.org>
---
git-pull.sh | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 5e96d1f..7beef4d 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -98,7 +98,11 @@ case "$merge_head" in
curr_branch=${curr_branch#refs/heads/}
echo >&2 "Warning: No merge candidate found because value of config option
- \"branch.${curr_branch}.merge\" does not match any remote branch fetched."
+ \"branch.${curr_branch}.merge\" does not match any remote branch fetched.
+ This branch is not set up to track any other branches. Please name which
+ branch you want to merge from on the command line, or if you almost always
+ want to merge from the same branch, then set this up with
+ \"git branch --track\"."
echo >&2 "No changes."
exit 0
;;
--
1.5.2.4
^ permalink raw reply related
* Re: [PATCH] git-merge: add option --no-ff
From: Junio C Hamano @ 2007-09-18 1:09 UTC (permalink / raw)
To: Eric Wong
Cc: Lars Hjemli, Andreas Ericsson, Johannes Schindelin,
Chris Shoemaker, git
In-Reply-To: <20070918005013.GA6368@muzzle>
Eric Wong <normalperson@yhbt.net> writes:
> Would automatically enabling --no-ff when it detects merging of two (or
> more) SVN branches be a good thing? We can add scripting support to
> git-svn for detecting if any given commit is really from SVN or not.
> Then we could do something like this in git-merge
>
> ---------------------------- 8< --------------------------------
> if git-svn test-svn-commits "$@"
> then
> no_ff=t
> no_fast_forward_strategies=$all_strategies
> fi
> ---------------------------- 8< --------------------------------
Yuck, do I understand you correctly? Are you talking about
adding dependency on git-svn to git-merge?
^ 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