* Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Nicolas Pitre @ 2007-09-07 16:29 UTC (permalink / raw)
To: Keith Packard; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <1189181313.30308.97.camel@koto.keithp.com>
On Fri, 7 Sep 2007, Keith Packard wrote:
> On Fri, 2007-09-07 at 04:21 -0700, Junio C Hamano wrote:
>
> > 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.
>
> It seems to me that instead of introducing an incompatible (but probably
> useful) change, a sensible option would be to have the ambiguous
> reference be an error instead of a warning. One shouldn't be encouraged
> to use names in .git that conflict with stuff in refs/heads anyway.
I agree. IMHO the sensible thing to do is to always warn, and error out
by default. I see no advantage for core.warnAmbiguousRefs=false other
than allow the user to shoot himself in the foot someday. Instead, we
should have core.allowAmbiguousRefs set to off by default.
Nicolas
^ permalink raw reply
* Re: [PATCH] basic threaded delta search
From: Nicolas Pitre @ 2007-09-07 16:19 UTC (permalink / raw)
To: Martin Koegler; +Cc: Junio C Hamano, git
In-Reply-To: <20070907061105.GA1379@auto.tuwien.ac.at>
On Fri, 7 Sep 2007, Martin Koegler wrote:
> On Thu, Sep 06, 2007 at 10:48:06AM -0400, Nicolas Pitre wrote:
> > On Thu, 6 Sep 2007, Junio C Hamano wrote:
> > > Also how would this interact with the LRU
> > > delta base window we discussed a week or two ago?
> >
> > This is completely orthogonal.
>
> Maybe we should adjust the split point of the the object list so, that
> objects with the same name hash are processed by one thread, as the LRU
> could provide the most benefit for these objects.
>
> I think of something like (totally untested):
> for (i = 0; i < NR_THREADS; i++) {
> unsigned sublist_size = list_size / (NR_THREADS - i);
> + while (sublist_size < list_size && list[0]->hash == list[1]->hash)
> + sublist_size++;
I guess you mean list[sublist_size-1]->hash == list[sublist_size]->hash.
But yeah that is a good idea.
Nicolas
^ permalink raw reply
* [RFC] svnimport/cvsimport: force creation of tags that already exist.
From: Michael Smith @ 2007-09-07 15:42 UTC (permalink / raw)
To: git
Hi all,
git-svnimport was changed recently to use git-tag to make tags (47ee8ed2).
I've had to add the "-f" option to import a repository where a tag was
moved. I think git-cvsimport would have the same problem.
I understand moving tags is frowned upon in Git. I don't know how common
the practise is in Subversion and CVS, or whether it makes sense to
make the import scripts force tag creation by default.
Mike
---
git-cvsimport.perl | 2 +-
git-svnimport.perl | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index ba23eb8..2954fb8 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -779,7 +779,7 @@ sub commit {
$xtag =~ tr/_/\./ if ( $opt_u );
$xtag =~ s/[\/]/$opt_s/g;
- system('git-tag', $xtag, $cid) == 0
+ system('git-tag', '-f', $xtag, $cid) == 0
or die "Cannot create tag $xtag: $!\n";
print "Created tag '$xtag' on '$branch'\n" if $opt_v;
diff --git a/git-svnimport.perl b/git-svnimport.perl
index 8c17fb5..d3ad5b9 100755
--- a/git-svnimport.perl
+++ b/git-svnimport.perl
@@ -873,7 +873,7 @@ sub commit {
$dest =~ tr/_/\./ if $opt_u;
- system('git-tag', $dest, $cid) == 0
+ system('git-tag', '-f', $dest, $cid) == 0
or die "Cannot create tag $dest: $!\n";
print "Created tag '$dest' on '$branch'\n" if $opt_v;
--
1.5.2.1
^ permalink raw reply related
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 16:09 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Andreas Ericsson, Wincent Colaiuta, Dmitry Kakurin,
Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <Pine.LNX.4.64.0709071155570.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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.
That assumes that the original task can even expressed well in C.
Multiple precision arithmetic, for example, requires access to the
carry bit. You can code around this, for example by writing something
like
unsigned a,b,carry;
[...]
carry = (a+b) < a;
but the problem is that those are ad-hoc idioms with a variety of
possibilities, and thus the compilers are not made to recognize them.
Another thing is mixed-precision multiplications and divisions: those
are _natural_ operations on a normal CPU, but have no representation
in assembly language.
As a consequence, most high performance multiple-precision packages
contain assembly language in some form or other.
gcc's assembly language template are excellent in that they actually
cooperate nicely with the optimizer, so the optimizer can do all the
address calculations and register assignments and opcode reorderings,
and then the actual operations that are not expressible in C can be
done by the programmer.
But anyway, I have worked as a graphics driver programmer for some
amount of time, and bit-stuffing memory-mapped areas with data was
still something where hand assembly was best.
I have also done BIOS terminal emulators, and being able to write
something like
ld b,whatever
myloop:
push bc
push hl
call nextchar
pop hl
pop bc
ld (hl),a
inc hl
djnz myloop
in order to suspend the terminal driver until the application comes up
with the next `whatever' output characters in an escape sequence is
_wagonloads_ more maintainable than using a state machine or whatever
else for distributing material delivered into the driver.
But this requires that nextchar can do something like
nextchar: ld (driverstack),sp
ld sp,(appstack)
ret
and the entrypoint, in contrast, does
outchar: ld (appstack),sp
ld sp,(driverstack)
ret
Cheap and expedient. You just need to set up a small stack, and
presto: coroutines, at absolutely negligible cost. I know that there
are some "portable" coroutine implementations that use setjmp/longjmp
in a rather horrific way, but those are way more unnatural.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Keith Packard @ 2007-09-07 16:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: keithp, Git Mailing List
In-Reply-To: <7vd4wu67qs.fsf_-_@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 818 bytes --]
On Fri, 2007-09-07 at 04:21 -0700, Junio C Hamano wrote:
> 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.
It seems to me that instead of introducing an incompatible (but probably
useful) change, a sensible option would be to have the ambiguous
reference be an error instead of a warning. One shouldn't be encouraged
to use names in .git that conflict with stuff in refs/heads anyway.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Keith Packard @ 2007-09-07 16:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: keithp, Junio C Hamano, Git Mailing List
In-Reply-To: <46E145BF.4070403@eudaptics.com>
[-- Attachment #1: Type: text/plain, Size: 311 bytes --]
On Fri, 2007-09-07 at 14:36 +0200, Johannes Sixt wrote:
> git update-ref master $some_other_ref
I'm sure that's how it was created; I was using update-ref on a regular
basis for a few weeks with this repository before the 1.5 new world
order for remotes came about.
--
keith.packard@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Button added to performs a GUI diff
From: Pierre Marc Dumuid @ 2007-09-07 15:07 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 99 bytes --]
Here is an updated version of the previous patch to handle the various
GUI merging tools.
Pierre
[-- Attachment #2: gitk_0001-Button-added-to-performs-a-GUI-diff.patch --]
[-- Type: text/x-patch, Size: 2411 bytes --]
>From bd43cca7aa88282455b6bbe6e2f9d8134da1029c Mon Sep 17 00:00:00 2001
From: Pierre Marc Dumuid <pierre.dumuid@adelaide.edu.au>
Date: Sat, 8 Sep 2007 00:32:10 +0930
Subject: [PATCH] Button added to performs a GUI diff
Signed-off-by: Pierre Marc Dumuid <pierre.dumuid@adelaide.edu.au>
---
gitk | 46 +++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index 300fdce..b8b0b2e 100755
--- a/gitk
+++ b/gitk
@@ -737,7 +737,9 @@ proc makewindow {} {
-command changediffdisp -variable diffelide -value {1 0}
label .bleft.mid.labeldiffcontext -text " Lines of context: " \
-font $uifont
- pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left
+ button .bleft.top.guidiff -text "GUI diff" -command doguidiff \
+ -font $uifont
+ pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new .bleft.top.guidiff -side left
spinbox .bleft.mid.diffcontext -width 5 -font $textfont \
-from 1 -increment 1 -to 10000000 \
-validate all -validatecommand "diffcontextvalidate %P" \
@@ -5332,6 +5334,48 @@ proc incrsearch {name ix op} {
}
}
+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]
+
+ if {[catch {set merge_tool [exec git-config merge.tool]} err]} {
+ error_popup "Sorry, 'merge.tool' not defined in git-config"
+ return
+ }
+
+ if {[catch {exec git cat-file -p $sha1string^:$fname > .gitk_diffolder} err]
+ || [catch {exec git cat-file -p $sha1string:$fname > .gitk_diffnewer} err]} {
+ error_popup "Invalid file selected for comparison"
+ return
+ }
+
+ switch -regexp $merge_tool {
+ "kdiff3" {
+ exec kdiff3 --L1 "$fname (Older)" --L2 "$fname (Newer)" .gitk_diffolder .gitk_diffnewer &
+ }
+ "meld|opendiff|vimdiff|xxdiff" {
+ exec $merge_tool .gitk_diffolder .gitk_diffnewer &
+ }
+ "tkdiff" {
+ exec $merge_tool -L "$fname (Older)" -L "$fname (Newer)" .gitk_diffolder .gitk_diffnewer &
+ }
+ "vimdiff" {
+ exec $merge_tool .gitk_diffolder .gitk_diffnewer
+ }
+ "emerge" {
+ exec emacs -f emerge-files-command .gitk_diffolder .gitk_diffnewer &
+ }
+ default {
+ show_error {} "No merge.tool defined."
+ }
+ }
+}
+
proc dosearch {} {
global sstring ctext searchstring searchdirn
--
1.5.2.4
^ permalink raw reply related
* [PATCH] git-rebase: fix -C option
From: J. Bruce Fields @ 2007-09-07 14:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, J. Bruce Fields
In-Reply-To: <11891748512757-git-send-email-bfields@citi.umich.edu>
The extra shift here causes failure to parse any commandline including
the -C option.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
---
git-rebase.sh | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 52c686f..c9942f2 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -221,7 +221,6 @@ do
;;
-C*)
git_am_opt="$git_am_opt $1"
- shift
;;
-*)
usage
--
1.5.3
^ permalink raw reply related
* [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
* 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
* 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: 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: [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: [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] 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: [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
* 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: 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
* 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: [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: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: [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: 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
* [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: 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
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