* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Pierre Habouzit @ 2007-09-07 19:59 UTC (permalink / raw)
To: David Kastrup; +Cc: Walter Bright, git
In-Reply-To: <85odge2r0w.fsf@lola.goethe.zz>
[-- Attachment #1: Type: text/plain, Size: 1435 bytes --]
On Fri, Sep 07, 2007 at 07:51:11PM +0000, David Kastrup wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> [bit fields]
>
> > Really, I feel this is a big lack, for a language that aims at
> > simplicity, conciseness _and_ correctness.
> >
> > OK, maybe I'm biased, I work with networks protocols all day long, so
> > I often need bitfields, but still, a lot of people deal with network
> > protocols, it's not a niche.
>
> And strictly speaking, C bitfields are completely useless for that
> purpose since the compiler is free to use whatever method he wants for
> allocating bit fields. So if you want to write a portable program,
> you are back to making the masks yourself.
The point is (1) D is not C, (2) we all know that linux e.g. does that
in many places using the fact that it knows how the supported compilers
(gcc icc tcc maybe some other) do their packing.
The discussion is about D. D solves the infamous problem with longs
not having the same size everywhere, I don't see why it couldn't solve
the bitfield issue either.
> Where bit fields work reliably is when you are not interchanging data
> with other applications, but just laying out your internals.
Thank you for the _C_ lesson.
--
·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: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 19:51 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Walter Bright, git
In-Reply-To: <20070907194115.GA23483@artemis.corp>
Pierre Habouzit <madcoder@debian.org> writes:
[bit fields]
> Really, I feel this is a big lack, for a language that aims at
> simplicity, conciseness _and_ correctness.
>
> OK, maybe I'm biased, I work with networks protocols all day long, so
> I often need bitfields, but still, a lot of people deal with network
> protocols, it's not a niche.
And strictly speaking, C bitfields are completely useless for that
purpose since the compiler is free to use whatever method he wants for
allocating bit fields. So if you want to write a portable program,
you are back to making the masks yourself.
Where bit fields work reliably is when you are not interchanging data
with other applications, but just laying out your internals.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Pierre Habouzit @ 2007-09-07 19:41 UTC (permalink / raw)
To: Walter Bright; +Cc: git
In-Reply-To: <fbs79k$tac$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 5595 bytes --]
On Fri, Sep 07, 2007 at 07:03:24PM +0000, Walter Bright wrote:
> Pierre Habouzit wrote:
> > Well, to me D has two significant drawbacks to be "ready to use". The
> >first one is that it doesn't has bit-fields. I often deal with
> >bit-fields
> >on structures that have a _lot_ of instances in my program, and the
> >bit-field is chosen for code readability _and_ structure size
> >efficiency.
> >I know you pretend that using masks manually often generates better
> >code. But in my case, speed does not matter _that_ much. I mean it does,
> >but not that this micro-level as access to the bit-field is not my
> >inner-loop.
>
> I'm surprised this is such an important issue. Others have mentioned it,
> but regard it as a minor thing. Interestingly, the htod program (which
> converts C .h files to D import files) will convert bit fields to inline
> functions, giving equivalent functionality.
Well htod does that, but it's very impractical to write them from
scratch. Especially if you want to benefit from the fact that padding
and integer sizes are very well defined to map e.g. structs onto a raw
stream, avoiding deserialization and so on. And for that bit-fields are
a really really fast and simple way to describe things.
I mean, take your classical example of the foreach loop. Your whole
point is that it's way shorter, and safer. And now you are saying that
people should instead of sth like:
struct my_struct {
unsigned some_field : 2;
unsigned has_this_property : 1;
unsigned is_in_this_state : 1;
unsigned priority_level : 2;
...
}
people should write (IIRC it works since ->some_field = 2 calls
->some_field(2) if the member does not exists, or maybe it's
set_some_field, it's not very relevant anyway):
struct my_struct {
unsigned some_field() {
return this->real_field >> 30;
}
void some_field(unsigned value) {
this->real_field |= (value & 3) << 30;
}
...
private:
unsigned real_field;
}
Please it has to be a joke: there is 42 ways for people to write it
wrong (wrong shifts, wrong masks, and so on), it's horribly obfuscated,
hence needs a lot of comments, whereas the bitfield is 90% self
documented, and the syntax is _very_ clear, you cannot beat that. I
would be absolutely fine with it being syntactical sugar for some kind
of template call though.
Not to mention that the usual C idiom:
union {
unsigned flags;
struct {
// many bitfields
};
};
Would need an explicit copy_flags(const my_struct foo) function to
work. Not pretty, not straightforward.
Really, I feel this is a big lack, for a language that aims at
simplicity, conciseness _and_ correctness.
OK, maybe I'm biased, I work with networks protocols all day long, so
I often need bitfields, but still, a lot of people deal with network
protocols, it's not a niche.
> > The other second issue I have, is that there is no way to do:
> > import (C) "foo.h"
> > And this is a big no-go (maybe not for git, but as a general issue)
> >because it impedes the use of external libraries with a C interface a
> >_lot_. E.g. I'd really like to use it to use some GNU libc extensions,
> >but I can't because it has too many dependencies (some async getaddrinfo
> >interface, that need me to import all the signal events and so on
> >extensions in the libc, with bitfields, wich send us back to the first
> >point).
>
> D does come with htod, which converts C .h files to D files.
Last time I checked it was only available on windows, and closed
source, both are an impediment for many people. It's definitely clear
that gcc being opensource and available on so many platforms helped to
make C what it is today. Lacking portable and free (as in speech) tools
are an impediment to the succes of a language. Right now, for D, only
gdc exists, it lags behind dmd quite a lot afaict, and there is no other
toolchain helpers yet.
> It's not possible to do a perfect job (because of macros), but it
> comes pretty darned close. The reason htod gets so close is because it
> is actually a real C compiler front end, not a perl or regex string
> processing hack.
>
> Because it (may) require a little hand tweaking of the results (again,
> because C headers may include awful things like:
> #define BEGIN {
> #define print printf(
> ), it's a separate program rather than built-in.
Yeah I'm fine with that, but sadly it's not available everywhere like
I said.
> > I also have a third, but non critical issue, I absolutely don't like
> >phobos :)
>
> You're not the only one <g>. But I'll add that access to the standard C
> runtime library *is* a part of D, so at some level it can't be worse than
> C. There's also another runtime library available, Tango, which is very
> popular.
I completely agree, and I knew about Tango, and anyways, I'm so used
to C, and D has so few to bring to my code style when I deal with low
level system functions, that I'm totally fine with std.c.* anyways :)
For the record I wasn't suggesting to rewrite git in D at all. I just
happened to see your post, and being very interested in where D is going
because I feel it's an excellent langage, and saw an opportunity to
mention a few quirks I feel it has, so, well, I answered :)
--
·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: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 19:40 UTC (permalink / raw)
To: Walter Bright; +Cc: git
In-Reply-To: <fbs8es$1cd$1@sea.gmane.org>
Walter Bright <boost@digitalmars.com> writes:
> On my project, one. But I've seen this problem repeatedly in other
> projects that had multiple developers. For example, I used to use
> version 1 of an assembler. It was itself written entirely in
> assembler. It ran *incredibly* slowly on large asm files. But it was
> written in assembler, which is very fast, so how could that be?
>
> Turns out, the symbol table used internally was a linear one. A
> linear symbol table is easy to implement, but doesn't scale well at
> all.
Well, my first system was a Z80 computer with an editor/assembler in
ROM (4kb). At one time I tried figuring out the size requirements of
symbols. It was two bytes for each symbol. Namely the value. The
"symbol table" was located behind the source code. Whenever this
marvel of technology encountered a label, it searched the source code
from the beginning for the definition of the label, keeping count of
all label definitions in between. When it found the definition, the
count corresponded to the position in the symbol table.
So compilation times were O(ns), with n the number of symbol uses and
s the size of the source code.
Implementing in a higher language would not have helped: memory
efficiency was what dictated this layout. Given that the whole
available memory was perhaps 50kB, assembly language modules could not
get so large that scale issues were deadly. But the assembly times
did get annoying sometimes.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 19:31 UTC (permalink / raw)
To: Walter Bright; +Cc: git
In-Reply-To: <fbs79k$tac$1@sea.gmane.org>
Walter Bright <boost@digitalmars.com> writes:
> There are a lot of people hard at work on D to make it more stable
> and increase the breadth and depth of tools available. I am fully
> aware that there may be non-technical issues to using D in a project
> like git, like availability of other D programmers, tradition, etc.,
> but in this thread I'm concerned mainly with technical issues.
>
> P.S. I'm also NOT suggesting that git be converted to D. Translating
> a working, debugged, 80,000 line codebase from one language to
> another is usually a fool's errand.
In my opinion there is basically one area which C has botched up
seriously in order to be useful as a general purpose language, and
that is conflating pointers and arrays, and allowing pointer
arithmetic. The consequences are absolutely awful with regard to
compilers being able to optimize, and it is pretty much the primary
reason that Fortran is still quite in use for numerical work.
C has no usable two-dimensional (never mind higher dimensions) array
concept that would allow passing multidimensional arrays of
runtime-determined size into functions. Period.
Add to that the pointer aliasing problems affecting compilers, and C
is useless for serious portable readable numerical work.
Fortran libraries like blas and lapack are ubiquitous after decades
because the language can deal with multiple-dimension arrays sensibly,
and could do so in the sixties already.
C99 helps a bit. But messing around with restrict pointers and
similar means that to wring equal performance out of some trivial code
piece (or permitting the compiler to do so without having to take
aliasing into account) is a lot of work and leads to ugly and
inscrutable code.
That's the one thing that has seriously hampered C: the lack of a true
array type on its own, decoupled from pointers. It does not need to
carry its dimensions with it or other
hide-the-implementation-from-the-programmer niceties: C is, after all,
a low-level language, and Fortran did not suffer from not having array
dimensions packed into the arrays as well.
But that's water down the drawbridge. This single major deficiency is
not anything that would hamper git development.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Walter Bright @ 2007-09-07 19:25 UTC (permalink / raw)
To: git
In-Reply-To: <FEA805F3-A6BA-4C76-B2C7-E28C00FDD801@wincent.com>
Wincent Colaiuta wrote:
> But once again I think Git falls into a special category where the
> design makes the "hassle" of developing in C worth it.
That may very well be true. I've never looked at the source code for
git, so I'm not in any position to judge it. Nor do I suggest
translating a debugged, working, 80,000 line project into another language.
My comments here are in more general terms.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Walter Bright @ 2007-09-07 19:23 UTC (permalink / raw)
To: git
In-Reply-To: <46E11CE1.4030209@op5.se>
Andreas Ericsson wrote:
> Walter Bright wrote:
>> 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.)
>>
>
> I haven't seen this in the development of git, although to be fair, you
> didn't mention the number of developers that were simultaneously working
> on your project.
On my project, one. But I've seen this problem repeatedly in other
projects that had multiple developers. For example, I used to use
version 1 of an assembler. It was itself written entirely in assembler.
It ran *incredibly* slowly on large asm files. But it was written in
assembler, which is very fast, so how could that be?
Turns out, the symbol table used internally was a linear one. A linear
symbol table is easy to implement, but doesn't scale well at all. A
linear symbol table was implemented because it was just harder to do
more advanced symbol table algorithms in assembler. In this case, a
higher level language re-implementation made the assembler much faster,
even though that implementation was SLOWER in every detail. It was
faster overall, because it was easier to develop faster algorithms.
> If it was you alone, I can imagine you were reluctant to
> change it just to see if something is faster.
My point was that when I reimplemented it in D, the cost of changing the
algorithms got much lower, so I was much more tempted to muck around
trying out different ones. The result was I found faster ones.
> Opensource projects with many contributors (git, linux) work differently,
> since one or a few among the plethora of authors will almost always be
> a true expert at the problem being solved.
That is a nice advantage. I don't think many projects can rely on having
the best in the business working on them, though <g>.
> The point is that, given enough developers, *someone* is bound to
> find an algorithm that works so well that it's no longer worth
> investing time to even discuss if anything else would work better,
> either because it moves the performance bottleneck to somewhere else
> (where further speedups would no longer produce humanly measurable
> improvements), or because the action seems instantanous to the user
> (further improvements simply aren't worth it, because no valuable
> resource will be saved from it).
Sure, but I suggest that few projects reach this maxima. Case in point:
ld, the gnu linker. It's terribly slow. To see how slow it is, compare
it to optlink (the 15 years old one that comes with D for Windows). So I
don't believe there is anything inherent about linking that should make
ld so slow. There's some huge leverage possible in speeding up ld
(spreading out that saved time among all the gnu developers).
So while git may have reached a maxima in performance, I don't think
this principle is applicable in general, even for very widely used open
source projects that would profit greatly from improved performance.
------
Walter Bright
http://www.digitalmars.com C, C++, D programming language compilers
http://www.astoriaseminar.com Extraordinary C++
^ permalink raw reply
* [PATCH] introduce config core.binaryCheckFirstBytes for xdiff-interface
From: Gerrit Pape @ 2007-09-07 19:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
xdiff-interface uses a hardcoded value of 8000 bytes to check from
the top of data whether to handle it as binary content. If a NULL
character appears after the first 8000 bytes, git won't notice,
which for example breaks the git format-patch | git am pipeline in
git rebase, as reported by Jamey Sharp through
http://bugs.debian.org/436182
This patch makes the hardcoded value configurable, so that users can
adjust the behavior when tracking binary files of huge sizes, e.g.
pdf's, in a repository.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
Documentation/config.txt | 6 ++++++
cache.h | 1 +
config.c | 8 ++++++++
environment.c | 1 +
xdiff-interface.c | 5 ++---
5 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 866e053..6c450ee 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -275,6 +275,12 @@ You probably do not need to adjust this value.
+
Common unit suffixes of 'k', 'm', or 'g' are supported.
+core.binaryCheckFirstBytes::
+ Number of bytes of the top of data that should be checked to
+ decide whether the data must be handled as binary content, or
+ can be interpreted as text. The default is 8000, when set to
+ zero, all available data is checked.
+
core.excludesfile::
In addition to '.gitignore' (per-directory) and
'.git/info/exclude', git looks into this file for patterns
diff --git a/cache.h b/cache.h
index 70abbd5..a9ca846 100644
--- a/cache.h
+++ b/cache.h
@@ -313,6 +313,7 @@ extern size_t packed_git_window_size;
extern size_t packed_git_limit;
extern size_t delta_base_cache_limit;
extern int auto_crlf;
+extern int binary_first_bytes;
#define GIT_REPO_VERSION 0
extern int repository_format_version;
diff --git a/config.c b/config.c
index dc3148d..892b2ff 100644
--- a/config.c
+++ b/config.c
@@ -395,6 +395,14 @@ int git_default_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.binarycheckfirstbytes")) {
+ int bytes = git_config_int(var, value);
+ if (bytes < 0)
+ die("bad value for core.binaryCheckFirstBytes %d", bytes);
+ binary_first_bytes = bytes;
+ return 0;
+ }
+
if (!strcmp(var, "user.name")) {
strlcpy(git_default_name, value, sizeof(git_default_name));
return 0;
diff --git a/environment.c b/environment.c
index b5a6c69..dd072b9 100644
--- a/environment.c
+++ b/environment.c
@@ -35,6 +35,7 @@ int pager_in_use;
int pager_use_color = 1;
char *editor_program;
int auto_crlf = 0; /* 1: both ways, -1: only when adding git objects */
+int binary_first_bytes = 8000;
/* This is set by setup_git_dir_gently() and/or git_default_config() */
char *git_work_tree_cfg;
diff --git a/xdiff-interface.c b/xdiff-interface.c
index be866d1..dba0232 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -122,11 +122,10 @@ int read_mmfile(mmfile_t *ptr, const char *filename)
return 0;
}
-#define FIRST_FEW_BYTES 8000
int buffer_is_binary(const char *ptr, unsigned long size)
{
- if (FIRST_FEW_BYTES < size)
- size = FIRST_FEW_BYTES;
+ if (binary_first_bytes && (binary_first_bytes < size))
+ size = binary_first_bytes;
return !!memchr(ptr, 0, size);
}
--
1.5.3.1
^ permalink raw reply related
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Walter Bright @ 2007-09-07 19:03 UTC (permalink / raw)
To: git
In-Reply-To: <20070907094120.GA27754@artemis.corp>
Pierre Habouzit wrote:
> Well, to me D has two significant drawbacks to be "ready to use". The
> first one is that it doesn't has bit-fields. I often deal with bit-fields
> on structures that have a _lot_ of instances in my program, and the
> bit-field is chosen for code readability _and_ structure size efficiency.
> I know you pretend that using masks manually often generates better
> code. But in my case, speed does not matter _that_ much. I mean it does,
> but not that this micro-level as access to the bit-field is not my
> inner-loop.
I'm surprised this is such an important issue. Others have mentioned it,
but regard it as a minor thing. Interestingly, the htod program (which
converts C .h files to D import files) will convert bit fields to inline
functions, giving equivalent functionality.
> The other second issue I have, is that there is no way to do:
> import (C) "foo.h"
>
> And this is a big no-go (maybe not for git, but as a general issue)
> because it impedes the use of external libraries with a C interface a
> _lot_. E.g. I'd really like to use it to use some GNU libc extensions,
> but I can't because it has too many dependencies (some async getaddrinfo
> interface, that need me to import all the signal events and so on
> extensions in the libc, with bitfields, wich send us back to the first
> point).
D does come with htod, which converts C .h files to D files. It's not
possible to do a perfect job (because of macros), but it comes pretty
darned close. The reason htod gets so close is because it is actually a
real C compiler front end, not a perl or regex string processing hack.
Because it (may) require a little hand tweaking of the results (again,
because C headers may include awful things like:
#define BEGIN {
#define print printf(
), it's a separate program rather than built-in.
> I also have a third, but non critical issue, I absolutely don't like
> phobos :)
You're not the only one <g>. But I'll add that access to the standard C
runtime library *is* a part of D, so at some level it can't be worse
than C. There's also another runtime library available, Tango, which is
very popular.
> Though I'm obviously free to chose another library. D has
> definitely many many many real advances over C (like the .init, .size,
> ... and so on fields, known types, and whatever portability nightmare
> the C impose us). In fact I like to use D like I code in C, using
> modules and functions, and very few classes, as few as I can. And even
> (under- ?) using D like this, it is a real pleasure to work with. I'm
> really eager to see gdc be more stable.
There are a lot of people hard at work on D to make it more stable and
increase the breadth and depth of tools available. I am fully aware that
there may be non-technical issues to using D in a project like git, like
availability of other D programmers, tradition, etc., but in this thread
I'm concerned mainly with technical issues.
P.S. I'm also NOT suggesting that git be converted to D. Translating a
working, debugged, 80,000 line codebase from one language to another is
usually a fool's errand.
Thanks for taking the time to post your thoughts.
-----------
Walter Bright
http://www.digitalmars.com C, C++, D programming language compilers
http://www.astoriaseminar.com Extraordinary C++
^ permalink raw reply
* Re: [PATCH] git-svn: remove --first-parent, add --upstream
From: Eric Wong @ 2007-09-07 18:37 UTC (permalink / raw)
To: Peter Baumann; +Cc: Lars Hjemli, Junio C Hamano, git
In-Reply-To: <20070907115130.GA1547@xp.machine.xx>
Peter Baumann <waste.manager@gmx.de> wrote:
> On Fri, Sep 07, 2007 at 12:13:23PM +0200, Lars Hjemli 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'.
I don't have any "subscribe <address>" lines in my muttrc nor do I
have any followup_to settings in it. It's just default, and 'g' has
always managed to work fine.
> 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)?
man 5 muttrc
However, whatever you did seems to have worked as replying to this
email didn't drop your name from this.
--
Eric Wong
^ permalink raw reply
* [PATCH] git-gui: lib/index.tcl: handle files with % in the filename properly
From: Gerrit Pape @ 2007-09-07 17:16 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
Steps to reproduce the bug:
$ mkdir repo && cd repo && git init
Initialized empty Git repository in .git/
$ touch 'foo%3Fsuite'
$ git-gui
Then click on the 'foo%3Fsuite' icon to include it in a changeset, a
popup comes with:
'Error: bad field specifier "F"'
Vincent Danjean noticed the problem and also suggested the fix, reported
through
http://bugs.debian.org/441167
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
lib/index.tcl | 18 ++++++++++++------
1 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/lib/index.tcl b/lib/index.tcl
index b3f5e17..78e2101 100644
--- a/lib/index.tcl
+++ b/lib/index.tcl
@@ -13,7 +13,8 @@ proc update_indexinfo {msg pathList after} {
if {$batch > 25} {set batch 25}
ui_status [format \
- "$msg... %i/%i files (%.2f%%)" \
+ "%s... %i/%i files (%.2f%%)" \
+ $msg \
$update_index_cp \
$totalCnt \
0.0]
@@ -68,7 +69,8 @@ proc write_update_indexinfo {fd pathList totalCnt batch msg after} {
}
ui_status [format \
- "$msg... %i/%i files (%.2f%%)" \
+ "%s... %i/%i files (%.2f%%)" \
+ $msg \
$update_index_cp \
$totalCnt \
[expr {100.0 * $update_index_cp / $totalCnt}]]
@@ -86,7 +88,8 @@ proc update_index {msg pathList after} {
if {$batch > 25} {set batch 25}
ui_status [format \
- "$msg... %i/%i files (%.2f%%)" \
+ "%s... %i/%i files (%.2f%%)" \
+ $msg \
$update_index_cp \
$totalCnt \
0.0]
@@ -145,7 +148,8 @@ proc write_update_index {fd pathList totalCnt batch msg after} {
}
ui_status [format \
- "$msg... %i/%i files (%.2f%%)" \
+ "%s... %i/%i files (%.2f%%)" \
+ $msg \
$update_index_cp \
$totalCnt \
[expr {100.0 * $update_index_cp / $totalCnt}]]
@@ -163,7 +167,8 @@ proc checkout_index {msg pathList after} {
if {$batch > 25} {set batch 25}
ui_status [format \
- "$msg... %i/%i files (%.2f%%)" \
+ "%s... %i/%i files (%.2f%%)" \
+ $msg
$update_index_cp \
$totalCnt \
0.0]
@@ -218,7 +223,8 @@ proc write_checkout_index {fd pathList totalCnt batch msg after} {
}
ui_status [format \
- "$msg... %i/%i files (%.2f%%)" \
+ "%s... %i/%i files (%.2f%%)" \
+ $msg \
$update_index_cp \
$totalCnt \
[expr {100.0 * $update_index_cp / $totalCnt}]]
--
1.5.3.1
^ permalink raw reply related
* [PATCH] git-clone: better error message if curl program is missing
From: Gerrit Pape @ 2007-09-07 17:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
If the curl program is not available, and git clone is started to clone a
repository through http, this is the output
Initialized empty Git repository in /tmp/puppet/.git/
/usr/bin/git-clone: line 37: curl: command not found
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?
This patch improves the error message by testing for availability of the
curl program before running it, the error output now is
Initialized empty Git repository in /tmp/puppet/.git/
The curl program is not available
Adrian Bridgett noticed this and reported through
http://bugs.debian.org/440976
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
git-clone.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 18003ab..834371d 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -34,6 +34,8 @@ fi
http_fetch () {
# $1 = Remote, $2 = Local
+ type curl >/dev/null 2>&1 ||
+ die "The curl program is not available"
curl -nsfL $curl_extra_args "$1" >"$2"
}
--
1.5.3.1
^ permalink raw reply related
* [PATCH] Documentation / grammer nit
From: Mike Ralphson @ 2007-09-07 16:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Mike Ralphson
If we're counting, a smaller number is 'fewer' not 'less'
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
---
Documentation/git-clone.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 227f092..253f4f0 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -68,7 +68,7 @@ OPTIONS
automatically setup .git/objects/info/alternates to
obtain objects from the reference repository. Using
an already existing repository as an alternate will
- require less objects to be copied from the repository
+ require fewer objects to be copied from the repository
being cloned, reducing network and local storage costs.
--quiet::
--
1.5.3.1.19.gb5ef6-dirty
######################################################################
This is an e-mail from Abacus Group plc.
Its contents, including any attachments, are confidential to the
intended recipient at the e-mail address to which it has been
addressed. If you are not the intended recipient you must not use,
disclose, distribute, copy, or print this e-mail.
If you receive this e-mail in error, please notify the sender by reply
e-mail and delete and destroy the message.
All intellectual property rights and materials contained within this
e-mail are the property of Abacus Group PLC.
Abacus Group PLC monitors e-mails to ensure its systems operate
effectively and to minimise the risk of viruses. Whilst it has taken
reasonable steps to scan this email, it does not accept liability for
any virus that may be contained in it.
Visit us online at www.abacus-group.co.uk
English Reg No. 2278260 - Abacus Group plc
######################################################################
^ permalink raw reply related
* Re: git-svn 1.5.3 does not understand grafts?
From: Joakim Tjernlund @ 2007-09-07 16:52 UTC (permalink / raw)
To: git
In-Reply-To: <1189183276.14841.10.camel@gentoo-jocke.transmode.se>
On Fri, 2007-09-07 at 18:41 +0200, Joakim Tjernlund wrote:
> svnadmin create /usr/local/src/TM/svn-tst/7720-svn/
> svn mkdir file:///usr/local/src/TM/svn-tst/7720-svn/trunk -m "Add trunk dir"
> svn mkdir file:///usr/local/src/TM/svn-tst/7720-svn/trunk/swp -m "Add swp dir"
>
> In my git repo I do
> git-svn init file:///usr/local/src/TM/svn-tst/7720-svn/trunk/swp
> git-svn fetch
> git branch svn remotes/git-svn
> #make remotes/git-svn parent to the initial commit in my git tree
> graftid=`git-show-ref -s svn`
> echo da783cce390ce013b19f1d308ea6813269c6a6b5 $graftid > .git/info/grafts
> #da783... is the initial commit in my git tree.
> git-svn dcommit
>
> fails with:
> Committing to file:///usr/local/src/TM/svn-tst/7720-svn/trunk/swp ...
> Commit da783cce390ce013b19f1d308ea6813269c6a6b5
> has no parent commit, and therefore nothing to diff against.
> You should be working from a repository originally created by git-svn
>
>
> Jocke
Using filter-branch helps, but git-svn isn't too happy:
git-svn init file:///usr/local/src/TM/svn-tst/7720-svn/trunk/swp
git-svn fetch
git branch svn remotes/git-svn
#make remotes/git-svn parent to the initial commit in my git tree
graftid=`git-show-ref -s svn`
echo da783cce390ce013b19f1d308ea6813269c6a6b5 $graftid > .git/info/grafts
#da783... is the initial commit in my git tree.
git filter-branch $graftid..HEAD
git-svn dcommit
Now I get alot of complaints, but it commits to svn.
It takes forever though:
r3 = 55a489bd4f66dd1f641a4676359d7b8911dc7d83 (git-svn)
W: HEAD and refs/remotes/git-svn differ, using rebase:
:100644 100644 f85ae11af7715a224015582724cb2bab87ec914a
7dc27f2dc58f6dd46cff79d5d762e630febfd419 M Makefile :100644 100644
4fa08aee7d4cd193cb161115cc079e7c50326e23
0246a89da64f08b0b48f7aa16886bbb2b12df237 M adc.c :100644 100644
84eba702cce3a9e4f125162f77f3ea52ae45aebc
78347f1f40f7526142bcc5db0708f50dd6150c0a M adc.h :100644 100644
890dfe7abdac0aa03eeca24572d98e3953db69d7
c2367a52e99af1f036dfc1de442f08cb187a58ab M bmi.c :100644 100644
92ae3ce7c8c0b3a664dc4ace8ce29b9ac7fd2d9b
40fb9b886e3a51189e662d54cbdbb968e244aa53 M bmi.h :100644 100644
a21005f15af34cd17e6acd8f1de974e3d82af0f4
ba2c2c4b19bbbfdabae6d3a9980132c4e1e1c07c M cdrbug.c :100644 100644
5a299761b62ca83fc22d30086b9a082c4de23ee4
3f885b0d8b7c29e7970997ed608df12e23d78644 M config.c :100644 100644
8a0a8ed90e50d18a9865fa2f5e644ca083a8b783
a2153ef48a59ffdf5a84ca6b93106c98dcb27a9c M control.c :100644 100644
760b828d8e55f6314d313e176578546e3d76b22b
143b44923e1f40d89fa9e87a30dd63abc48cea57 M database.c :100644 100644
e7cab9865317c1ab4cbe8ecb47b5fda7c0eddcd8
ff519b51ae5428b93504f124ea1f24452b69fa94 M database.h :100644 100644
a28219bc7b5bc692242639fae0e5b54cfaec7bc3
78c8df626c1cf9c989f127f96161850f92cd4588 M defines.h :100644 100644
21e68f9a09a2618493eed4f4c1796293db78c828
68659b3a1bc25a90b103824e089c7c6126f5367b M eeprom.c :100644
100644 3095638b3f28d5b8e04be1c660fc37bf82e034c2
7ea0835e82aa230f1834b9977ec6a634c400e244 M eeprom.h :100644 000000
8f7368e29d7ba3dbe34c8e6ad7a3738b68dd1d78
0000000000000000000000000000000000000000 D fpga.c :100644 000000
2dded257891ada8228f684e9be213b86b6c1fda5
0000000000000000000000000000000000000000 D fpga.h :100644 100644
97ccea82dd35a7d5973199511d7a9127981f74d3
3758a9334cf04bb670ae2563ad5f2b95af257f3b M fwrev.h :100644 100644
cd80946581062ead075ba6047d51ae2605e4cc14
2ef670ea229b62bc1b10d087ab2bd3850f08e91a M glitch.c :100644 100644
d14716ec4351b610dbac81637623a9ca3a8e8902
9e1789933635a5b9e2c562a3c69a973e07b31b7b M i2cmux.c :100644 100644
6551153cf879ba87d73aa53aa6b768867b026842
4a2813b41231461ab4b316829f9e59ac36498813 M i2cmux.h :100644 100644
2967bc6e21ab9581a47266966867ded04d8076f1
5294b80cbad8d7501fa8c415a0b7b0e1a3343262 M led.c :100644 100644
9b8016b9c3f13a5fb4446a1f31d1d2311ece32df
2014113eaff9c22f4efd347031d3b7651aa78648 M led.h :100644 100644
e4d50a5a735105187304f0458cde9102c64aa163
faba2f86b6f86f944ce4995ec5cab2edea0d3bb6 M lvd.c :100644 100644
aa86ba2a2c313ca688700e75a4353a4d66846b54
bbc2a887b404a06d28ee77c5343278f3a309371f M main.c :100644 100644
d0f5f5f6538924cfe757e8cdb328f4d7bf9858bd
25e10d528df873425cf32b366c42c01a84367459 M memmap.c :100644 100644
9bdc8d928ce77ed2f529a0709a3f54a882c37b8b
086b7fc9dd915e43f21e94e963a18184669d361d M optosfp.c :000000 100644
0000000000000000000000000000000000000000
bb8184467f03194f7aa8cc964a5dfe37603539e3 A pld.c :000000 100644
0000000000000000000000000000000000000000
405486a29ca8be8212bc307017404ebbed904fe0 A pld.h :100644 100644
b361784c0b617bdceac5e297e0c3dbb96b2a3dae
869bf82b2e8b710150abf88ca34a9e12378f1415 M protocol.c :100644
100644 988233f538e9df6c681b2f60a19279567ca2536d
55d9627846575f5f63d907a6dd07979040c64552 M protocol.h :100644
100644 b43a0c32977e11ad6ccbe9704ce8fdace8914e4d
7872778d025990cdc014d6ca907a3cf9e75050b1 M shell.c :100644 100644
0134ff4ca1a1f8b8d760eb4e367057dbb88b68ed
cda0e129d5fc1390dd7d1e1dd5b9695651c5dcdd M spi.c :100644 100644
3ea874f32fa1eab87f4d2261a922dc293f379947
24e1be7f8bfe9570464260b6d210cbf7771edaab M task.c :100644 100644
ca1f966200e5f7126fe0b61a768a5e4b1d49bc94
87a516572095292add8b1b19687a624c38ad205f M trans.c :100644 100644
b298cc58873100e5e74f53d2a3f62028caba8951
853c18b6c42f9d463f14eede3b84ed700b00dcd5 M transceiver.cFirst,
rewinding head to replay your work on top of it...
HEAD is now at 55a489b... Initial import of 7700, sws100034.
I get alot similar messages until it is finished.
Jocke
^ permalink raw reply
* git-svn: Branching clarifications
From: Russ Brown @ 2007-09-07 16:47 UTC (permalink / raw)
To: git
I have a few questions about how/when to use git branches when using
git-svn (I'm a tad confused...)
Say I've initialised and fetched a git repo involving trunk and one
branch (say branch1) from an svn repository.
If I do git branch -a, I see similar to the following:
* master
branch1
trunk
(branch1 and trunk are in red for me, which I figure means they're
remotely tracked or something like that?)
OK, so that's telling me that I currently have master checked out into
my working copy. My question is: where did master come from? Is it a
local branch of trunk?
Moving on, say I want to work on branch1. Can I simply issue git
checkout branch1? If I do so I get this:
$ git branch -a
* (no branch)
master
branch1
trunk
Which is a bit scary. It seems my working copy is orphaned...
OK, so let's assume I'm supposed to create a local branch of each remote
branch I want to work on. So:
$ git branch local/branch1 branch1
$ git checkout local/branch1
$ git-branch -a
* local/branch1
master
branch1
trunk
Am I supposed to have used --track when creating this branch? What are
the implications for specifying or not specifying that flag when using
git-svn?
So I do some editing on this branch, commit and dcommit. The changes
appear as expected in the repo.
At this point if I checkout master, the contents look like
local/branch1, which isn't what I'd suspected (that it would be a branch
of trunk). What does master represent?
So I checkout local/trunk, and create a new file, commit and dcommit.
Umm, it's been committed to branch1 on the repo: not trunk,
So I figure I'm quite obviously doing something wrong here. Could
someone give me a hand and tell me what it is I'm getting wrong?
Thanks!
--
Russ
^ permalink raw reply
* git-svn 1.5.3 does not understand grafts?
From: Joakim Tjernlund @ 2007-09-07 16:41 UTC (permalink / raw)
To: git
svnadmin create /usr/local/src/TM/svn-tst/7720-svn/
svn mkdir file:///usr/local/src/TM/svn-tst/7720-svn/trunk -m "Add trunk dir"
svn mkdir file:///usr/local/src/TM/svn-tst/7720-svn/trunk/swp -m "Add swp dir"
In my git repo I do
git-svn init file:///usr/local/src/TM/svn-tst/7720-svn/trunk/swp
git-svn fetch
git branch svn remotes/git-svn
#make remotes/git-svn parent to the initial commit in my git tree
graftid=`git-show-ref -s svn`
echo da783cce390ce013b19f1d308ea6813269c6a6b5 $graftid > .git/info/grafts
#da783... is the initial commit in my git tree.
git-svn dcommit
fails with:
Committing to file:///usr/local/src/TM/svn-tst/7720-svn/trunk/swp ...
Commit da783cce390ce013b19f1d308ea6813269c6a6b5
has no parent commit, and therefore nothing to diff against.
You should be working from a repository originally created by git-svn
Jocke
^ permalink raw reply
* 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
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