* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Johannes Schindelin @ 2007-09-07 10:21 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <a1bbc6950709061721r537b153eu1b0bb3c27fb7bd51@mail.gmail.com>
Hi,
On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
> Anyway I don't mean to start a religious C vs. C++ war.
You have a very strange way of not meaning to start a C vs. C++ war.
> It's a matter of beliefs and as such pointless.
No, it's not. As has been shown by some very good _arguments_. Once you
have facts to back up your claims, it is not any belief any longer.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Johannes Schindelin @ 2007-09-07 10:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Dmitry Kakurin, Matthieu Moy, Git
In-Reply-To: <alpine.LFD.0.999.0709070212300.5626@evo.linux-foundation.org>
Hi,
On Fri, 7 Sep 2007, Linus Torvalds wrote:
> On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
>
> > I was pointing out that I've been programming in different languages
> > (many more actually) and observed bad developers writing bad code in
> > all of them. So this quality "bad developer" is actually
> > language-agnostic :-).
>
> You can write bad code in any language. However, some languages, and
> especially some *mental* baggages that go with them are bad.
There is an important additional point: a language like C _holds_ you to a
certain degree of diligence.
In my day-job I have to code in other languages, which make it "easy" to
code. As a result, the code I have to work with is sloppy, ugly and
buggy. By applying the same principles I am _forced_ to use in C, with
Git, I produce better code.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Johannes Schindelin @ 2007-09-07 10:28 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <a1bbc6950709062009x59a41cb7re6051739c11e370c@mail.gmail.com>
Hi,
On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
> Now, I realize that I'm a very infrequent contributor to Git, but I want
> my opinion to be heard.
We are a happy little meritocracy here. Once you proved that you're not
full of shit (some seem to try the opposite, you know who you are), you
can go all caps. Before that, you'll have to show that you earn to be
heard first.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 4/3] archive: specfile syntax change: "$Format:%PLCHLDR$" instead of just "%PLCHLDR"
From: Johannes Schindelin @ 2007-09-07 10:44 UTC (permalink / raw)
To: René Scharfe
Cc: Junio C Hamano, Andreas Ericsson, Git Mailing List,
Michael Gernoth, Thomas Glanzmann
In-Reply-To: <46E0647A.10000@lsrfire.ath.cx>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 925 bytes --]
Hi,
On Thu, 6 Sep 2007, René Scharfe wrote:
> Johannes Schindelin schrieb:
> >> +
> >> + b = memchr(a, '$', len);
> >> + if (!b || a + len < b + 9 || memcmp(b + 1, "Format:", 7))
> >> + break;
> >
> > Wouldn't memmem(buffer, len, "$Format:", 8) be better here?
>
> Oh, that's a nice GNU extension, didn't know it before.
Oh sorry, I didn't even realise that this is a GNU extension...
> > A general comment: since you plan to output the result into a file
> > anyway, it should be even easier to avoid realloc(), and do a
> > print_formatted_specfile() instead of a format_specfile(), no?
>
> Hmm, not sure what you mean. At least archive-tar needs the expanded
> contents in a buffer (not immediately written to stdout) because it
> tries to mimic a real tar and always writes in blocks of 10k and
> therefore needs to buffer the output.
Yeah, I missed that. Thanks for explaining it to me!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 5/3] archive: rename attribute specfile to export-subst
From: Johannes Schindelin @ 2007-09-07 10:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: René Scharfe, Andreas Ericsson, Git Mailing List,
Michael Gernoth, Thomas Glanzmann
In-Reply-To: <7vd4wva4lv.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 6 Sep 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > The bigger question is now if these two patches should be folded back
> > into your original patch series, or stand alone as commits of their
> > own...
>
> That is no brainer, as there is a simple and hard rule that any topic
> already in 'next' are not to be rewound ever. Follow-up patches are the
> right thing to do in this case.
Right. At the time I suggested it, I was not aware that the patches were
in next already.
Sorry,
Dscho
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Lukas Sandström @ 2007-09-07 10:47 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <46DDC500.5000606@etek.chalmers.se>
Lukas Sandström wrote:
> Hi.
>
> This is an attempt to use "The Better String Library"[1] in builtin-mailinfo.c
>
> The patch doesn't pass all the tests in the testsuit yet, but I thought I'd
> send it out so people can decide if they like how the code looks.
>
> I'm not sending a patch to add the library files at this time. I'll send
> that patch when this patch is working.
>
> The changes required to make it pass the tests shouldn't be very large.
>
> /Lukas
>
> [1] http://bstring.sourceforge.net/
>
> ---
> builtin-mailinfo.c | 795 ++++++++++++++++++++++++++--------------------------
> 1 files changed, 392 insertions(+), 403 deletions(-)
Unfortunatley, I haven't had any time inte the last few days to code, nor read
mail. I'm assuming that there is no point in me finishing the patch and that git
will go with the strbuf solution?
/Lukas
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Johannes Schindelin @ 2007-09-07 10:56 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Wincent Colaiuta, Dmitry Kakurin, Linus Torvalds, Matthieu Moy,
Git
In-Reply-To: <46E0EEC6.4020004@op5.se>
Hi,
On Fri, 7 Sep 2007, Andreas Ericsson wrote:
> Wincent Colaiuta wrote:
> > El 7/9/2007, a las 2:21, Dmitry Kakurin escribi?:
> >
> > > I just wanted to get a sense of how many people share this "Git should
> > > be in pure C" doctrine.
> >
> > Count me as one of them. Git is all about speed, and C is the best choice
> > for speed, especially in context of Git's workload.
> >
>
> Nono, hand-optimized assembly is the best choice for speed. C is just
> a little more portable ;-)
I have a buck here that says that you cannot hand-optimise assembly (on
modern processors at least) as good as even gcc.
Ciao,
Dscho
^ permalink raw reply
* [PATCH (try 2)] git-svn: fix "Malformed network data" with svn:// servers
From: Eric Wong @ 2007-09-07 11:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, 430091
In-Reply-To: <20070907100711.GA24166@muzzle>
We have a workaround for the reparent function not working
correctly on the SVN native protocol servers. This workaround
opens a new connection (SVN::Ra object) to the new
URL/directory.
Since libsvn appears limited to only supporting one connection
at a time, this workaround invalidates the Git::SVN::Ra object
that is $self inside gs_fetch_loop_common(). So we need to
restart that connection once all the fetching is done for each
loop iteration to be able to run get_log() successfully.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index d3c8cd0..fbd4691 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3013,7 +3013,7 @@ package Git::SVN::Ra;
use vars qw/@ISA $config_dir $_log_window_size/;
use strict;
use warnings;
-my ($can_do_switch, %ignored_err, $RA);
+my ($ra_invalid, $can_do_switch, %ignored_err, $RA);
BEGIN {
# enforce temporary pool usage for some simple functions
@@ -3174,7 +3174,11 @@ sub gs_do_switch {
$self->{url} = $full_url;
$reparented = 1;
} else {
+ $_[0] = undef;
+ $self = undef;
+ $RA = undef;
$ra = Git::SVN::Ra->new($full_url);
+ $ra_invalid = 1;
}
}
$ra ||= $self;
@@ -3234,6 +3238,7 @@ sub gs_fetch_loop_common {
my $inc = $_log_window_size;
my ($min, $max) = ($base, $head < $base + $inc ? $head : $base + $inc);
my $longest_path = longest_common_path($gsv, $globs);
+ my $ra_url = $self->{url};
while (1) {
my %revs;
my $err;
@@ -3295,6 +3300,13 @@ sub gs_fetch_loop_common {
"$g->{t}-maxRev";
Git::SVN::tmp_config($k, $r);
}
+ if ($ra_invalid) {
+ $_[0] = undef;
+ $self = undef;
+ $RA = undef;
+ $self = Git::SVN::Ra->new($ra_url);
+ $ra_invalid = undef;
+ }
}
# pre-fill the .rev_db since it'll eventually get filled in
# with '0' x40 if something new gets committed
--
Eric Wong
^ permalink raw reply related
* Re: Distributing revisions to patches in a series
From: Johannes Schindelin @ 2007-09-07 11:04 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709062219320.13907@iabervon.org>
Hi,
On Thu, 6 Sep 2007, Daniel Barkalow wrote:
> I was wondering if anybody's got a good process for the following
> situation: I've just rebased a series onto the new origin/next. In the
> afterwards, I determined that some of the intermediate merges weren't
> right (the patch to split bundle-handling out of builtin-bundle didn't
> pick up fixes to builtin-bundle). I also found and fixed a warning added
> by my series. I want to take these changes, split them into individual
> hunks, and apply each hunk to the appropriate commit from the series
> before that commit, generating a new series.
>
> I know how to do it by figuring out where the hunk should go myself and
> branching, fixing, and rebasing, but I was wondering if there was a
> magic script to just do it. It seems like it should be an automatable
> operation (take the last commit as a set of hunks, and walk back up the
> history, leaving each one at the oldest commit to which it applies
> cleanly; when all of the hunks are allocated, generate a new history by
> amending commits).
Sounds like you want to read the new section "splitting commits" in
git-rebase.txt ;-)
Hth,
Dscho
^ permalink raw reply
* [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Junio C Hamano @ 2007-09-07 11:21 UTC (permalink / raw)
To: Keith Packard; +Cc: Git Mailing List
In-Reply-To: <1189133898.30308.58.camel@koto.keithp.com>
Keith Packard <keithp@keithp.com> writes:
> On Thu, 2007-09-06 at 16:26 -0700, Junio C Hamano wrote:
> ...
>> Perhaps you have ".git/master" by mistake?
>
> oops.
Ok, that explains it; git is doing exactly what the user asked
it to do.
5---6 side
/
1---2---3---4 master
The user has this history. But he has a stray .git/master file,
perhaps created by hand by mistake (it would be very interesting
to find how that file got there in the first place), that points
at commit "3". From a side branch, he says "git rebase master".
The first parameter to "git rebase" in a single parameter form
is "the commit on which to replay the changes my current branch
has". It is not limited to a branch name. IOW, it can be an
arbitrary object name, and one of the rules to translate a user
string that is supposed to mean an arbitrary object name goes
through this table:
"%s", "refs/%s", "refs/tags/%s", "refs/heads/%s",
"refs/remotes/%s", "refs/remotes/%s/HEAD"
For each entry in the above table, "%s" part of the entry is
replaced by the user string, and resulting string is used to see
if there is such a file under .git/ directory, and the first
match is used (this explanation is simplifying things a bit).
This rule has been there almost from the beginning. The first
entry allowed you to have a tag A and a branch A at the same
time, while giving you a way to disambiguate them by spelling
them out as "refs/tags/A" and "refs/heads/A", respectively.
Also the first rule covered special "ref" names such as HEAD and
ORIG_HEAD.
Alas, there is one drawback of this rule. His .git/master hides
refs/heads/master. So essentially his command line said "I've
built a few commits since I forked from the history that leads
to commit 3; I want to replay my changes on top of that commit".
He meant to say 4, but said 3, and as a unfortunate consequence,
commit 4 is lost.
The above explanation is solely for understanding the situation
and, not meant to defend the current behaviour. I think the
current behaviour is inviting mistakes and confusion.
This patch brings in a new world order by introducing a backward
incompatible change. When the string the user gave us does not
contain any slash, we do not apply the first entry (i.e.
directly underneath .git/ without any "refs/***") unless the
name consists solely of uppercase letters or an underscore,
thereby ignoring .git/master. The ones we often use, such as
HEAD and ORIG_HEAD are not affected by this change.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
sha1_name.c | 35 ++++++++++++++++++++++++++++++++++
t/t3407-rebase-confused.sh | 45 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 80 insertions(+), 0 deletions(-)
create mode 100755 t/t3407-rebase-confused.sh
diff --git a/sha1_name.c b/sha1_name.c
index 2d727d5..1b980ca 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -239,6 +239,35 @@ static int ambiguous_path(const char *path, int len)
return slash;
}
+static int confused_ref(const char *str)
+{
+ char ch;
+ int seen_non_uppercase = 0;
+
+ /*
+ * People create .git/master by mistake using hand-rolled
+ * scripts and confuse themselves utterly. Make sure this
+ * does not match such a path.
+ */
+ while ((ch = *str++) != '\0') {
+ if (ch == '/')
+ return 0;
+ if (!((ch == '_') ||
+ ('A' <= ch && ch <= 'Z') ||
+ ('0' <= ch && ch <= '9')))
+ seen_non_uppercase = 1;
+ }
+
+ /*
+ * str did not have any slash and we are checking when
+ * it hangs directly underneath .git/; the only valid
+ * cases we currently have are HEAD, ORIG_HEAD, MERGE_HEAD and
+ * FETCH_HEAD. If we saw any non uppercase, non underscore,
+ * we should ignore this string.
+ */
+ return seen_non_uppercase;
+}
+
static const char *ref_fmt[] = {
"%.*s",
"refs/%.*s",
@@ -259,6 +288,9 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)
unsigned char sha1_from_ref[20];
unsigned char *this_result;
+ if ((p == ref_fmt) && confused_ref(str))
+ continue;
+
this_result = refs_found ? sha1_from_ref : sha1;
r = resolve_ref(mkpath(*p, len, str), this_result, 1, NULL);
if (r) {
@@ -283,6 +315,9 @@ int dwim_log(const char *str, int len, unsigned char *sha1, char **log)
char path[PATH_MAX];
const char *ref, *it;
+ if (p == ref_fmt && confused_ref(str))
+ continue;
+
strcpy(path, mkpath(*p, len, str));
ref = resolve_ref(path, hash, 0, NULL);
if (!ref)
diff --git a/t/t3407-rebase-confused.sh b/t/t3407-rebase-confused.sh
new file mode 100755
index 0000000..5254da6
--- /dev/null
+++ b/t/t3407-rebase-confused.sh
@@ -0,0 +1,45 @@
+#!/bin/sh
+
+test_description="Keithp's .git/master problem
+
+ 5---6 side
+ /
+ 1---2---3---4 master
+
+"
+
+. ./test-lib.sh
+
+build () {
+ echo "$1" >"$1" && git add "$1" && test_tick && git commit -m "$1"
+}
+
+test_expect_success setup '
+
+ build one &&
+ build two &&
+ git branch side &&
+ build three &&
+ git tag anchor &&
+ build four &&
+ git-checkout side &&
+ build five &&
+ build six &&
+ git update-ref master anchor &&
+ git tag -d anchor
+
+'
+
+test_expect_success rebase '
+
+ git rebase master
+
+'
+
+test_expect_success 'everybody is still there' '
+
+ test 6 = $(git log --pretty=oneline HEAD | wc -l)
+
+'
+
+test_done
--
1.5.3.1.879.g4d83f
^ permalink raw reply related
* Re: PATCH to add a button to perform a meld on the current file
From: Johannes Schindelin @ 2007-09-07 11:25 UTC (permalink / raw)
To: Pierre Marc Dumuid; +Cc: git
In-Reply-To: <46E0D79E.3080606@adelaide.edu.au>
Hi,
On Fri, 7 Sep 2007, Pierre Marc Dumuid wrote:
> Here's a dodgy [not that good] patch to perform a GUI comparison on a
> file. It is dodgy because it assumes cogito is installed, and you want
> to use meld, and it doesn't remove the temporary files.
cogito is phased out.
> Not expecting this to go into main branch, but I find it handy for my
> own purposes nether-the-less.
Just in case you want to get it in, here are some comments (made harder by
the fact that you did not follow Documentation/SubmittingPatches)...
> --- /usr/bin/gitk 2007-08-06 07:55:41.000000000 +0930
> +++ /home/pmdumuid/bin/gitkpmd 2007-09-07 14:09:28.000000000 +0930
You might want to consider using format-patch next time ;-)
> @@ -4564,6 +4566,19 @@
> }
> }
>
> +proc doguidiff {} {
> + global cflist sha1string
> +
> + set taglist [$cflist tag ranges highlight]
> + set from [lindex $taglist 0]
> + set to [lindex $taglist 1]
> +
> + set fname [$cflist get $from $to]
> + exec cg-admin-cat -r $sha1string^ $fname > .gitk_diffolder
> + exec cg-admin-cat -r $sha1string $fname > .gitk_diffnewer
This can be be achieved by "git cat-file -t blob $sha1string^:$fname", and
likewise for $sha1string.
+ exec meld .gitk_diffolder .gitk_diffnewer &
+}
Hmm. If you allow it to block, you might have more chances to clean up
the temporary files...
Also, it would be nice to have it configurable which tool you use, a la
git-mergetool.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Wincent Colaiuta @ 2007-09-07 11:30 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Dmitry Kakurin, Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <46E0EEC6.4020004@op5.se>
El 7/9/2007, a las 8:25, Andreas Ericsson escribió:
> Nono, hand-optimized assembly is the best choice for speed. C is just
> a little more portable ;-)
Funny thing is, GCC almost certainly produces better-optimized
assembly than most programmers could... ;-)
Cheers,
Wincent
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Wincent Colaiuta @ 2007-09-07 11:36 UTC (permalink / raw)
To: David Kastrup; +Cc: Walter Bright, git
In-Reply-To: <85k5r27wkv.fsf@lola.goethe.zz>
El 7/9/2007, a las 9:40, David Kastrup escribió:
> A design is perfect not when there is no longer anything you can add
> to it, but if there is no longer anything you can take away.
Il semble que la perfection soit atteinte non quand il n'y a plus
rien à ajouter, mais quand il n'y a plus rien à retrancher.
Perfection is achieved, not when there is nothing more to add, but
when there is nothing left to take away.
Ch. III: L'Avion, p. 60
<http://en.wikiquote.org/wiki/Exupery>
^ permalink raw reply
* Re: [PATCH] git-svn: remove --first-parent, add --upstream
From: Peter Baumann @ 2007-09-07 11:51 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Eric Wong, Junio C Hamano, git
In-Reply-To: <8c5c35580709070313l4b815ddbg70be8fb0aef4eefd@mail.gmail.com>
On Fri, Sep 07, 2007 at 12:13:23PM +0200, Lars Hjemli wrote:
> On 9/7/07, Peter Baumann <waste.manager@gmx.de> wrote:
> > lets reset 'trunk' to its state before the merge and
> > 'branch1' to the merge commit, before fixing the bug in 'branch1'.
> >
> > a-b-c-d-e trunk
> > \ \
> > \ -x-y m branch1
>
> Yeah, this would certainly not be handled correctly by dcommit using
> --first-parent (but it could be handled by (a correct implementation
> of) --upstream).
>
> Thanks for the example, I had a feeling something like this could
> occur. So I guess I'll have another go at --upstream this weekend.
>
> [btw: could you please stop messing with 'Mail-Followup-To:'? When
> replying to your mail, I don't want everyone _except_ you in the 'To:'
> header...]
>
Sorry, I wasn't aware of that.
I had a 'subscribe git@vger.kernel.org' in my muttrc and just pressed 'g'
for group reply. Reading the docs suggested to 'set followup_to=no' (as
I did before sending this message). Per default it is set to 'yes'.
Could anyone more experienced with mutt correct me if this was the wrong
fix for this problem (or even point me to the right documentation)?
-Peter
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Wincent Colaiuta @ 2007-09-07 11:52 UTC (permalink / raw)
To: Walter Bright; +Cc: git
In-Reply-To: <fbr2iv$ugg$1@sea.gmane.org>
El 7/9/2007, a las 10:36, Walter Bright escribió:
> Wincent Colaiuta wrote:
>> Git is all about speed, and C is the best choice for speed,
>> especially in context of Git's workload.
>
> I can appreciate that. I originally got into writing compilers
> because my game (Empire) ran too slowly and I thought the existing
> compilers could be dramatically improved.
>
> And technically, yes, you can write code in C that is >= the speed
> of any other language (other than asm). But practically, this isn't
> necessarily so, for the following reasons:
>
> 1) You wind up having to implement the complex, dirty details of
> things yourself. The consequences of this are:
>
> a) you pick a simpler algorithm (which is likely less efficient
> - I run across bubble sorts all the time in code)
>
> b) once you implement, tune, and squeeze all the bugs out of
> those complex, dirty details, you're reluctant to change it. You're
> reluctant to try a different algorithm to see if it's faster. I've
> seen this effect a lot in my own code. (I translated a large body
> of my own C++ code that I'd spent months tuning to D, and quickly
> managed to get significantly more speed out of it, because it was
> much simpler to try out different algorithms/data structures.)
While I accept that this is generally true, I think Git is somewhat
of a special case. From a design perspective the data structures and
algorithms are remarkably simple -- therein lies its elegance. I
think it's precisely the kind of problem that can be tackled well
with a close-to-the-metal language like C.
> 2) Garbage collection has an interesting and counterintuitive
> consequence. If you compare n malloc/free's with n gcnew/
> collections, the malloc/free will come out faster, and you conclude
> that gc is slow. But that misses one huge speed advantage of gc -
> you can do FAR fewer allocations! For example, I've done a lot of
> string manipulating programs in C. The basic problem is keeping
> track of who owns each string. This is done by, when in doubt, make
> a copy of the string.
>
> But if you have gc, you don't worry about who owns the string. You
> just make another pointer to it. D takes this a step further with
> the concept of array slicing, where one creates windows on existing
> arrays, or windows on windows on windows, and no allocations are
> ever done. It's just pointer fiddling.
This mirrors my experience in desktop application development.
Despite GC being "slower" the app actually runs faster and a lot of
nasty problems (shared resources, locking etc) just magically go
away. Development is easier too.
But once again I think Git falls into a special category where the
design makes the "hassle" of developing in C worth it.
Wincent
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Andreas Ericsson @ 2007-09-07 11:54 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, Dmitry Kakurin, Linus Torvalds, Matthieu Moy,
Git
In-Reply-To: <Pine.LNX.4.64.0709071155570.28586@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 7 Sep 2007, Andreas Ericsson wrote:
>
>> Wincent Colaiuta wrote:
>>> El 7/9/2007, a las 2:21, Dmitry Kakurin escribi?:
>>>
>>>> I just wanted to get a sense of how many people share this "Git should
>>>> be in pure C" doctrine.
>>> Count me as one of them. Git is all about speed, and C is the best choice
>>> for speed, especially in context of Git's workload.
>>>
>> Nono, hand-optimized assembly is the best choice for speed. C is just
>> a little more portable ;-)
>
> I have a buck here that says that you cannot hand-optimise assembly (on
> modern processors at least) as good as even gcc.
>
http://www.gelato.unsw.edu.au/archives/git/0504/1746.html
I win. Donate $1 to FSF next time you get the opportunity ;-)
Hand-optimized asm is faster because the optimizer in the compiler is a
general-purpose one that has to guess and make assumptions about the code
and its input to make the correct decisions. While it gets things right
in as many as 80% of the cases, there's still the 20% where it doesn't.
A human can, with sufficient research and effort, make the same optimizations
where they are correct but avoid the 20% erroneous ones.
If the compiler gets it wrong inside your innermost loop, it might be worth
shaving those extra 0.0001 seconds off of each iteration, because in the long
run, world-wide, it might save several weeks worth of CPU-time every day.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Configure mutt to be used in git and lkml mailing lists (was: Re: [PATCH] git-svn: remove --first-parent, add --upstream)
From: Fernando J. Pereda @ 2007-09-07 12:08 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <20070907115130.GA1547@xp.machine.xx>
[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]
On Fri, Sep 07, 2007 at 01:51:30PM +0200, Peter Baumann wrote:
> > [btw: could you please stop messing with 'Mail-Followup-To:'? When
> > replying to your mail, I don't want everyone _except_ you in the 'To:'
> > header...]
> >
>
> Sorry, I wasn't aware of that.
>
> I had a 'subscribe git@vger.kernel.org' in my muttrc and just pressed 'g'
> for group reply. Reading the docs suggested to 'set followup_to=no' (as
> I did before sending this message). Per default it is set to 'yes'.
>
> Could anyone more experienced with mutt correct me if this was the wrong
> fix for this problem (or even point me to the right documentation)?
>
[I'm sending this to the list too so it ends up in the archives. I cut
the rest of the people from the To: list because this is not directly
relevant to them.]
Just don't use 'subscribe list' and mutt won't mess up with
mail-followup-to. Instead of using 'l' to reply-to-list keep using 'g'
to reply to everyone involved in the subthread and everything should be
fine :>
- ferdy
--
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Wincent Colaiuta @ 2007-09-07 12:33 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Dmitry Kakurin, Linus Torvalds, Matthieu Moy,
Git
In-Reply-To: <46E13C0F.8040203@op5.se>
El 7/9/2007, a las 13:54, Andreas Ericsson escribió:
> Johannes Schindelin wrote:
>> Hi,
>> On Fri, 7 Sep 2007, Andreas Ericsson wrote:
>>> Wincent Colaiuta wrote:
>>>> El 7/9/2007, a las 2:21, Dmitry Kakurin escribi?:
>>>>
>>>>> I just wanted to get a sense of how many people share this "Git
>>>>> should
>>>>> be in pure C" doctrine.
>>>> Count me as one of them. Git is all about speed, and C is the
>>>> best choice
>>>> for speed, especially in context of Git's workload.
>>>>
>>> Nono, hand-optimized assembly is the best choice for speed. C is
>>> just
>>> a little more portable ;-)
>> I have a buck here that says that you cannot hand-optimise
>> assembly (on modern processors at least) as good as even gcc.
>
>
> http://www.gelato.unsw.edu.au/archives/git/0504/1746.html
>
> I win. Donate $1 to FSF next time you get the opportunity ;-)
Well, you picked a very specific algorithm amenable to that kind of
optimization: small, manageable, with a minimal and well-defined
performance critical section that could be written in assembly. Note
how a good chunk of the implementation was still in C. At most I'd
give you 75 cents for that one. ;-)
Wincent
^ permalink raw reply
* Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Johannes Sixt @ 2007-09-07 12:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Keith Packard, Git Mailing List
In-Reply-To: <7vd4wu67qs.fsf_-_@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> But he has a stray .git/master file,
> perhaps created by hand by mistake (it would be very interesting
> to find how that file got there in the first place),
It is easy to get one there if, in a brave moment, you try
git update-ref master $some_other_ref
instead of the correct
git update-ref refs/heads/master $some_other_ref
-- Hannes
^ permalink raw reply
* Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Pierre Habouzit @ 2007-09-07 12:42 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Keith Packard, Git Mailing List
In-Reply-To: <46E145BF.4070403@eudaptics.com>
[-- Attachment #1: Type: text/plain, Size: 1235 bytes --]
On Fri, Sep 07, 2007 at 12:36:15PM +0000, Johannes Sixt wrote:
> Junio C Hamano schrieb:
> >But he has a stray .git/master file,
> >perhaps created by hand by mistake (it would be very interesting
> >to find how that file got there in the first place),
>
> It is easy to get one there if, in a brave moment, you try
>
> git update-ref master $some_other_ref
>
> instead of the correct
>
> git update-ref refs/heads/master $some_other_ref
I was about to say the same :)
I'd have added though that maybe update-ref should print a warning for
the references that do not match the restriction Junio added. This could
be done using the function Junio proposed un update_ref() in refs.c
note that it's a sane thing to do anyways, I would not bet a lot of
money on what happens if you ask git to:
git update-ref $foo $sha
for foo in (completely random :P): index config packed-refs ...
If a tool needs a new reference namespace, it can create a
subdirectory under refs/ so it does not really causes harm IMHO.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] git-gui/Makefile: Replace libdir with gitgui_libdir
From: Dmitry V. Levin @ 2007-09-07 12:44 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20070907050148.GA18160@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]
On Fri, Sep 07, 2007 at 01:01:48AM -0400, Shawn O. Pearce wrote:
> "Dmitry V. Levin" <ldv@altlinux.org> wrote:
> > > "Dmitry V. Levin" <ldv@altlinux.org> wrote:
> > > > On GNU/Linux, libdir is used to mean "/usr/lib or /usr/lib64"
> > > > depending on architecture. Different libdir meaning breaks
> > > > idiomatic expressions like rpm specfile "make libdir=%_libdir".
> >
> > The idea is that git-gui's libdir is not a traditional arch-dependent
> > libdir's subdirectory, but rather arch-independent datadir's subdirectory.
> > That is, I see no reason to call it libdir even in standalone project.
>
> Call it datadir then? I see you point, and now agree with you.
I'm not sure that "datadir" is better choice than current "libdir".
First, from git-gui point of view, files placed in git-gui/lib/ are
rather library files than data files.
Second, if top-level makefile will define "datadir", original issue will
raise again.
That's why I suggested to add some git-gui specific component to git-gui's
libdir variable name.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Karl Hasselström @ 2007-09-07 12:55 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Andreas Ericsson, Johannes Schindelin, Dmitry Kakurin,
Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <E4A6490A-ABA9-4383-978E-C7F2E4BC9C23@wincent.com>
On 2007-09-07 14:33:42 +0200, Wincent Colaiuta wrote:
> Well, you picked a very specific algorithm amenable to that kind of
> optimization: small, manageable, with a minimal and well-defined
> performance critical section that could be written in assembly. Note
> how a good chunk of the implementation was still in C.
And this is of course exactly the kind of spot where you _would_ use
assembly in the real world. 99.99% of code is better written in C than
assembler, but there is that 0.01% where hand-coded assembler is a
better choice.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Andreas Ericsson @ 2007-09-07 13:58 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Johannes Schindelin, Dmitry Kakurin, Matthieu Moy, Git,
Linus Torvalds
In-Reply-To: <E4A6490A-ABA9-4383-978E-C7F2E4BC9C23@wincent.com>
Wincent Colaiuta wrote:
> El 7/9/2007, a las 13:54, Andreas Ericsson escribió:
>
>> Johannes Schindelin wrote:
>>> Hi,
>>> On Fri, 7 Sep 2007, Andreas Ericsson wrote:
>>>> Wincent Colaiuta wrote:
>>>>> El 7/9/2007, a las 2:21, Dmitry Kakurin escribi?:
>>>>>
>>>>>> I just wanted to get a sense of how many people share this "Git
>>>>>> should
>>>>>> be in pure C" doctrine.
>>>>> Count me as one of them. Git is all about speed, and C is the best
>>>>> choice
>>>>> for speed, especially in context of Git's workload.
>>>>>
>>>> Nono, hand-optimized assembly is the best choice for speed. C is just
>>>> a little more portable ;-)
>>> I have a buck here that says that you cannot hand-optimise assembly
>>> (on modern processors at least) as good as even gcc.
>>
>>
>> http://www.gelato.unsw.edu.au/archives/git/0504/1746.html
>>
>> I win. Donate $1 to FSF next time you get the opportunity ;-)
>
> Well, you picked a very specific algorithm amenable to that kind of
> optimization: small, manageable, with a minimal and well-defined
> performance critical section that could be written in assembly. Note how
> a good chunk of the implementation was still in C. At most I'd give you
> 75 cents for that one. ;-)
>
Yes, but that's what I said in the original email as well. C is just so
much more pleasant to write in that the only place you'd (sanely) use
asm is in exactly these tight loops, where the code is likely to be used
and reused until the algorithm it describes is no longer a viable option
for doing what it was originally designed to do.
It still proves the point though, as surely as n+1 > n for any value of n:
Hand-optimized assembly is faster than compiler-optimized C code.
It might be harder to do properly on some architectures than others (RISC
comes to mind), but it's still possible.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Wincent Colaiuta @ 2007-09-07 14:13 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Dmitry Kakurin, Matthieu Moy, Git,
Linus Torvalds
In-Reply-To: <46E1590A.4060504@op5.se>
El 7/9/2007, a las 15:58, Andreas Ericsson escribió:
> Yes, but that's what I said in the original email as well. C is
> just so
> much more pleasant to write in that the only place you'd (sanely) use
> asm is in exactly these tight loops, where the code is likely to be
> used
> and reused until the algorithm it describes is no longer a viable
> option
> for doing what it was originally designed to do.
>
> It still proves the point though, as surely as n+1 > n for any
> value of n:
> Hand-optimized assembly is faster than compiler-optimized C code.
In a theoretical ideal world, yes; no one would argue that C is
faster than fine-tuned assembly.
But in the *real world* rewriting Git in assembly would be like
painting a house using a single horse hair instead of a paint brush
or roller. Your SHA-1 example is a perfect example of where you
benefit from doing a tiny embellished detail using the single hair
(assembly) and leave all the rest in C.
In the real world and not the theoretical ideal world, it's not just
about the diminishing returns you get from writing more and more of a
code base in assembly instead of just the performance-critical
bottlenecks; it's that you're more likely to make subtle mistakes or
even make things slower. GCC does a remarkable job of optimizing in a
huge number of use cases, and best of all, it does it for free.
Personal opinion, of course, but that's the way I think it is.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] git-rebase: support --whitespace=<option>
From: J. Bruce Fields @ 2007-09-07 14:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
Pass --whitespace=<option> to git-apply. Since git-apply and git-am
expect this, I'm always surprised when I try to give it to git-rebase
and it doesn't work.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
Documentation/git-rebase.txt | 9 +++++++--
git-rebase.sh | 5 ++++-
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 61b1810..0858fa8 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -8,8 +8,9 @@ git-rebase - Forward-port local commits to the updated upstream head
SYNOPSIS
--------
[verse]
-'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge] [-C<n>]
- [-p | --preserve-merges] [--onto <newbase>] <upstream> [<branch>]
+'git-rebase' [-i | --interactive] [-v | --verbose] [-m | --merge]
+ [-C<n>] [ --whitespace=<option>] [-p | --preserve-merges]
+ [--onto <newbase>] <upstream> [<branch>]
'git-rebase' --continue | --skip | --abort
DESCRIPTION
@@ -209,6 +210,10 @@ OPTIONS
context exist they all must match. By default no context is
ever ignored.
+--whitespace=<nowarn|warn|error|error-all|strip>::
+ This flag is passed to the `git-apply` program
+ (see gitlink:git-apply[1]) that applies the patch.
+
-i, \--interactive::
Make a list of the commits which are about to be rebased. Let the
user edit that list before rebasing. This mode can also be used to
diff --git a/git-rebase.sh b/git-rebase.sh
index 3bd66b0..52c686f 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -216,8 +216,11 @@ do
-v|--verbose)
verbose=t
;;
+ --whitespace=*)
+ git_am_opt="$git_am_opt $1"
+ ;;
-C*)
- git_am_opt=$1
+ git_am_opt="$git_am_opt $1"
shift
;;
-*)
--
1.5.3
^ 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