* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: John 'Z-Bo' Zabroski @ 2007-09-08 0:56 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LFD.0.999.0709070203200.5626@evo.linux-foundation.org>
Linus Torvalds <torvalds <at> linux-foundation.org> writes:
>
> And if you want a fancier language, C++ is absolutely the worst one to
> choose. If you want real high-level, pick one that has true high-level
> features like garbage collection or a good system integration, rather than
> something that lacks both the sparseness and straightforwardness of C,
> *and* doesn't even have the high-level bindings to important concepts.
>
> IOW, C++ is in that inconvenient spot where it doesn't help make things
> simple enough to be truly usable for prototyping or simple GUI
> programming, and yet isn't the lean system programming language that C is
> that actively encourags you to use simple and direct constructs.
>
> Linus
>
I want code that is Correct, Explicit, Fast, and in that order.
I'm 23 years old and learned C++ when I was 13. Back then, my compiler didn't
even support "bleeding edge" C++ language features like namespaces. I'm not a
C++ expert, and I don't have the ego to call myself a superb programmer. The
largest program I've written is 10K SLOC in C. Yet, I'd like to participate in
this discussion, if that is OKay =)
I do think I am capable of an honest critique of the downside of C++:
_Problems_ _With_ _C++_
*size*
On my bookshelf, most recent editions of the canonical C++ _books_:
Accelerated C++: Practical Programming by Example (336 pages)
The C++ Standard Template Library: A Tutorial and Reference (832 pages)
Effective C++: 50 Specific Ways to Improve Your Programs and Design (288
pages)
More Effective C++: 35 New Ways to Improve Your Programs and Designs
(336 pages)
Exceptional C++: 47 Engineering Puzzles, Programming Problems, and
Solutions (240 pages)
More Exceptional C++: 40 New Engineering Puzzles, Programming Problems,
and Solutions (304 pages)
The C++ Programming Language (1030 pages)
Modern C++ Design: Generic Programming and Design Patterns Applied (352
pages)
C++ Templates: The Complete Guide (552 pages)
Altogether, that is 3918 pages. K&R, the canonical C _book_, is 272 pages.
Becoming a C++ language lawyer is much harder than becoming a C language
lawyer. Language lawyers know "how not to hang oneself" while programming in
the language. I don't know how many of these titles are translated to other
languages, however, I am sure the *effort* required to translate all of them is
significant. Open source is more successful if there is a lingua franca for
programming, and that is C. Now, it may move away from C over time, but it will
*never* be C++ because it's encyclopedic.
*hidden complexity*
(1) it's hard to say what code will compile down to. viz., constructors can
be elided, but there is no fitness warranty; profiling your compiler to find out
whether it is elided is tedious and "searching for secrets" that should be
_explicit_
(2) people don't understand static polymorphism and compile-time dispatch;
people are used to objects sending messages dynamically (run-time dispatch)
(3) coercion
(4) networks of objects are not explicitly laid out, hiding quadratically
complex patterns of communication between objects
(5) data structure and data flow come before algorithms. Sometimes, data
structure dictates data flow (ad-hoc networks of objects); sometimes, data flow
dictates data structure (one of life's most disagreeable tasks - waiting in line
- is characterized as FIFO). This, I feel, is the most important point, because
the first rule of programming is to figure out what you want to say before you
figure out how to say it. In C++, ad-hoc networks of objects with cyclic
message paths are all too easy to create [see (4)] which means _code_ _is_ _not_
_explicit_ and as a result _code_ _is_ _not_ _fast_.
*transfer semantics on objects are not robust*
this ties into (1) in hidden complexity
the code author needs to specify a lot of boilerplate to achieve desired
transfer semantics on objects. Similarly, the code audience, be it reviewer,
maintainer or merger, needs to read a lot of boilerplate to understand how
objects get moved around in memory. Moreover, most of these concepts are
intuitively declarative in nature, such as a parent object/child object relation.
*poor re-use of effort*
"code re-use" is a misnomer; when programmers speak of code-reuse they mean
re-use of effort. There is no benefit to polymorphism if effort cannot be
consolidated easily.
*C++ Standard iffy*
Some things just disappear quickly for *frantic* reasons (strstream was
removed for aesthetics), indicating not enough foresight into what is important.
I do not want to pick a language where I have to worry about features in it's
"standard library" becoming deprecated mainly for aesthetics. As Dijkstra
preached, programming is _not_ supposed to be a frantic exercise.
*usually, better options*
See C++??: A Critique of C++ and Programing and Language Trends in the 1990s
by Ian Joyner http://web.mac.com/joynerian/iWeb/Ian%20Joyner/CPPCritique.pdf
(Somewhat outdated, but many of the points are intrinsic and will forever be
relevant). You can add to the list of better options D 1.0.
^ permalink raw reply
* .git/info/exclude w/ CFLF fails in cygwin
From: Jing Xue @ 2007-09-08 1:01 UTC (permalink / raw)
To: git
(1.5.3.1 in cygwin, Win XP)
I have cygwin configured to operate in the DOS/text mode, which means
cygwin translates LF to CRLF when writing a file, and CRLF to LF when
reading. Unfortunately cygwin's fstat() implementation doesn't take the
mode into account when reporting stat.st_size, presumably for the sake
of performance, while read() does actually do the conversion.
That causes the function add_excludes_from_file_1() in dir.c to reject a
.git/info/exclude file with CRLF ending, because the size actually read
is not the same as the size reported by fstat().
The simplest fix I have found is to explicitly open the exclude file in
binary mode, because the rest of the exclude file parsing code actually
deals with CRLF quite fine.
I would submit a patch but I am not sure if this is the appropriate fix.
By the way, parsing .git/config with CRLF in the same environment works
fine because the code reads the file by byte and doesn't do any size
validation.
Any thoughts?
--
Jing Xue
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Dmitry Kakurin @ 2007-09-08 0:37 UTC (permalink / raw)
To: David Kastrup; +Cc: Andreas Ericsson, Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <85sl5q1570.fsf@lola.goethe.zz>
On 9/7/07, David Kastrup <dak@gnu.org> wrote:
> Just compiling under C++, with no source changes, is likely to impact
> performance and compile time rather badly
This in fact is a very specific statement. Would you care to back it
up with facts?
--
- Dmitry
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Dmitry Kakurin @ 2007-09-08 0:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <Pine.LNX.4.64.0709071119510.28586@racer.site>
On 9/7/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 6 Sep 2007, Dmitry Kakurin wrote:
>
> > Anyway I don't mean to start a religious C vs. C++ war.
>
> You have a very strange way of not meaning to start a C vs. C++ war.
I honestly didn't. I didn't even think it's possible. In the
environment of mainstream commercial software development the last war
on this subj was over 8-10 years ago.
Even wars like "do we use exceptions/templates/stl" are pretty much
over. Now days it's "do we use Boost", or "do we use template
metaprogramming". But even more often it's Java/C# vs. C++.
That's why I was wondering how come C was chosen for Git.
> > It's a matter of beliefs and as such pointless.
>
> No, it's not. As has been shown by some very good _arguments_. Once you
> have facts to back up your claims, it is not any belief any longer.
Well I've heard *opinions* and anecdotal evidence. No facts though.
And it's not surprising. There could be no hard facts in such a
matter. It always boils down to "most of all, I want my software to be
X" where X is different for different people (fast,maintainable,quick
to market, scalable, beautiful, etc ... to name a few).
With different values of X any debate is pointless. And X is exactly
the matter of believes.
Anyway my curiosity is satisfied (thru the roof so to speak) and I
think it's enough on the subj. It has reminded me of good old times
though.
--
- Dmitry
^ permalink raw reply
* Re: how to access working tree from .git dir?
From: Junio C Hamano @ 2007-09-07 23:42 UTC (permalink / raw)
To: Josh England; +Cc: Git Mailing List
In-Reply-To: <1189204498.15140.4.camel@beauty>
Josh England <jjengla@comcast.net> writes:
> On Fri, 2007-09-07 at 15:12 -0700, Junio C Hamano wrote:
>> Josh England <jjengla@comcast.net> writes:
>>
>> > OK. Fair enough. Maybe it would be good to note in git-sh-setup.sh that
>> > many of the supplied functions will not work when called from within
>> > $GIT_DIR.
>>
>> Sorry, "supplied functions"? Care to clarify with a patch?
>
> I guess really just the cd_to_topdir() function. It will silently fail
> when run from within $GIT_DIR.
Ah, I see what you meant.
I think you probably are supposed to check with is_bare_repository
or something before calling that, as asking to cd to toplevel
implies you know there is such a thing as toplevel ;-)
^ permalink raw reply
* [PATCH] diff-delta.c: pack the index structure
From: David Kastrup @ 2007-09-07 23:38 UTC (permalink / raw)
To: git
In normal use cases, the performance wins are not overly impressive:
we get something like 5-10% due to the slightly better locality of
memory accesses using the packed structure.
However, since the data structure for index entries saves 33% of
memory on 32-bit platforms and 40% on 64-bit platforms, the behavior
when memory gets limited should be nicer.
This is a rather well-contained change. One obvious improvement would
be sorting the elements in one bucket according to their hash, then
using binary probing to find the elements with the right hash value.
As it stands, the output should be strictly the same as previously
unless one uses the option for limiting the amount of used memory, in
which case the created packs might be better.
Signed-off-by: David Kastrup <dak@gnu.org>
---
diff-delta.c | 62 +++++++++++++++++++++++++++++++++++++++++++---------------
1 files changed, 46 insertions(+), 16 deletions(-)
diff --git a/diff-delta.c b/diff-delta.c
index 0dde2f2..cf0136f 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -115,9 +115,13 @@ static const unsigned int U[256] = {
struct index_entry {
const unsigned char *ptr;
unsigned int val;
- struct index_entry *next;
};
+struct unpacked_index_entry {
+ struct index_entry entry;
+ struct unpacked_index_entry *next;
+};
+
struct delta_index {
unsigned long memsize;
const void *src_buf;
@@ -131,7 +135,8 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
unsigned int i, hsize, hmask, entries, prev_val, *hash_count;
const unsigned char *data, *buffer = buf;
struct delta_index *index;
- struct index_entry *entry, **hash;
+ struct unpacked_index_entry *entry, **hash;
+ struct index_entry *aentry, **ahash;
void *mem;
unsigned long memsize;
@@ -148,28 +153,21 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
hmask = hsize - 1;
/* allocate lookup index */
- memsize = sizeof(*index) +
- sizeof(*hash) * hsize +
+ memsize = sizeof(*hash) * hsize +
sizeof(*entry) * entries;
mem = malloc(memsize);
if (!mem)
return NULL;
- index = mem;
- mem = index + 1;
hash = mem;
mem = hash + hsize;
entry = mem;
- index->memsize = memsize;
- index->src_buf = buf;
- index->src_size = bufsize;
- index->hash_mask = hmask;
memset(hash, 0, hsize * sizeof(*hash));
/* allocate an array to count hash entries */
hash_count = calloc(hsize, sizeof(*hash_count));
if (!hash_count) {
- free(index);
+ free(hash);
return NULL;
}
@@ -183,12 +181,13 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
val = ((val << 8) | data[i]) ^ T[val >> RABIN_SHIFT];
if (val == prev_val) {
/* keep the lowest of consecutive identical blocks */
- entry[-1].ptr = data + RABIN_WINDOW;
+ entry[-1].entry.ptr = data + RABIN_WINDOW;
+ --entries;
} else {
prev_val = val;
i = val & hmask;
- entry->ptr = data + RABIN_WINDOW;
- entry->val = val;
+ entry->entry.ptr = data + RABIN_WINDOW;
+ entry->entry.val = val;
entry->next = hash[i];
hash[i] = entry++;
hash_count[i]++;
@@ -212,15 +211,46 @@ struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
continue;
entry = hash[i];
do {
- struct index_entry *keep = entry;
+ struct unpacked_index_entry *keep = entry;
int skip = hash_count[i] / HASH_LIMIT;
do {
+ --entries;
entry = entry->next;
} while(--skip && entry);
+ ++entries;
keep->next = entry;
} while(entry);
}
free(hash_count);
+ memsize = sizeof(*index)
+ +sizeof(*ahash) * (hsize+1) +
+ +sizeof(*aentry) * entries;
+ mem=malloc(memsize);
+
+ if (!mem) {
+ free(hash);
+ return NULL;
+ }
+
+ index = mem;
+ index->memsize = memsize;
+ index->src_buf = buf;
+ index->src_size = bufsize;
+ index->hash_mask = hmask;
+
+ mem = index+1;
+ ahash = mem;
+ mem = ahash + (hsize+1);
+ aentry = mem;
+
+ for (i=0; i<hsize; i++) {
+ ahash[i] = aentry;
+ for (entry=hash[i]; entry; entry=entry->next)
+ *aentry++ = entry->entry;
+ }
+ ahash[hsize] = aentry;
+ assert(aentry-(struct index_entry *)mem == entries);
+ free(hash);
return index;
}
@@ -302,7 +332,7 @@ create_delta(const struct delta_index *index,
val ^= U[data[-RABIN_WINDOW]];
val = ((val << 8) | *data) ^ T[val >> RABIN_SHIFT];
i = val & index->hash_mask;
- for (entry = index->hash[i]; entry; entry = entry->next) {
+ for (entry = index->hash[i]; entry<index->hash[i+1]; entry++) {
const unsigned char *ref = entry->ptr;
const unsigned char *src = data;
unsigned int ref_size = ref_top - ref;
--
1.5.3.GIT
^ permalink raw reply related
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Walter Bright @ 2007-09-07 23:16 UTC (permalink / raw)
To: git
In-Reply-To: <851wda2pbo.fsf@lola.goethe.zz>
David Kastrup wrote:
> The problem is a toy problem: in real applications,
Necessarily, to make an example suitable for a n.g. post, I ruthlessly
cut down the size of it. This can have the inadvertent effect of making
it appear trivial.
> you'll need to
> access several data structures using the same index, and you'll need
> to be able to assign index values to temporary variables and so on.
The index is available:
foreach (index, value; array)
{
writefln("array[%s] = %s", index, value);
}
and it isn't necessary to worry about what the correct type for index
is, as it is inferred.
> So being able to hide the type of an index in one very specific
> application (looping through a single array completely)
foreach'ing over a subset (i.e. slice) of an array:
foreach (value; array[5 .. $])
... loop from 5 to the end ...
> at one place is not going to buy you much.
Experience with foreach in real code shows that the for loop is what
becomes a rarity. Simple as it is, foreach is one of the best liked
improvements D has. And I speak as one who has written so many for loops
that spewing out:
for (int i = 0; i < 10; i++)
is a 'finger' macro for me, i.e. my fingers blit it out without even
thinking about it.
> Anyway, D is pretty much irrelevant as a perspective for git, so you
> should take it to a language advocacy group.
I wished to answer your specific comments in this post.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Walter Bright @ 2007-09-07 22:54 UTC (permalink / raw)
To: git
In-Reply-To: <20070907205604.GC23483@artemis.corp>
Pierre Habouzit wrote:
> Sure, but it does not works on amd64 properly (and it's the
> architecture I care about) and is not ready for the current gcc (4.2,
> only 4.1 builds) and so on. It's not as stable as DMD is. It does not
> lags too much version-wise, it lags in maturity. But well, youth has a
> cure: time :)
Yes, and the more people use it, the better it will get. These are all
environmental problems, not technical limitations of the language.
^ permalink raw reply
* Re: how to access working tree from .git dir?
From: Josh England @ 2007-09-07 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vveam15w9.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-09-07 at 15:12 -0700, Junio C Hamano wrote:
> Josh England <jjengla@comcast.net> writes:
>
> > OK. Fair enough. Maybe it would be good to note in git-sh-setup.sh that
> > many of the supplied functions will not work when called from within
> > $GIT_DIR.
>
> Sorry, "supplied functions"? Care to clarify with a patch?
I guess really just the cd_to_topdir() function. It will silently fail
when run from within $GIT_DIR.
-JE
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: David Kastrup @ 2007-09-07 22:28 UTC (permalink / raw)
To: Dmitry Kakurin; +Cc: Andreas Ericsson, Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <a1bbc6950709071517n7e7e99ffl3dd351092e7f19d6@mail.gmail.com>
"Dmitry Kakurin" <dmitry.kakurin@gmail.com> writes:
> On 9/6/07, Andreas Ericsson <ae@op5.se> wrote:
>> They already have, but every now and then someone comes along and suggest
>> a complete rewrite in some other language. So far we've had Java (there's
>> always one...), Python and now C++.
>
> Since this "complete rewrite" was mentioned in multiple emails I'd
> like to rectify that:
> What I'm offering (for Git) is to use C++ as a "better C".
> Don't change any existing *working* code, but start introducing simple
> C++ constructs in the new code.
You are aware that the Linux kernel was kept compilable under g++ for
a while in its history? You'll need more than vague words to erase
the memories from that experiment...
Just compiling under C++, with no source changes, is likely to impact
performance and compile time rather badly, not to mention portability
(you need the C++ runtime, for one thing).
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Dmitry Kakurin @ 2007-09-07 22:17 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, Matthieu Moy, Git
In-Reply-To: <46E0F04D.7040101@op5.se>
On 9/6/07, Andreas Ericsson <ae@op5.se> wrote:
> They already have, but every now and then someone comes along and suggest
> a complete rewrite in some other language. So far we've had Java (there's
> always one...), Python and now C++.
Since this "complete rewrite" was mentioned in multiple emails I'd
like to rectify that:
What I'm offering (for Git) is to use C++ as a "better C".
Don't change any existing *working* code, but start introducing simple
C++ constructs in the new code.
Git is simple enough to not require any high-level abstractions. But
some utility classes could make code much simpler.
And BTW, I don't even like C++ that much :-), I just like it much
better than C. I've been saying that C++ is a legacy language for
quite some time now. But we will use it for many years to come because
the size of this legacy code is huge, so there will be plenty of C++
developers available (to contribute to Git :-).
And C++ is the only way to move with existing C codebase.
--
- Dmitry
^ permalink raw reply
* Re: how to access working tree from .git dir?
From: Junio C Hamano @ 2007-09-07 22:12 UTC (permalink / raw)
To: Josh England; +Cc: Git Mailing List
In-Reply-To: <1189203064.15140.2.camel@beauty>
Josh England <jjengla@comcast.net> writes:
> OK. Fair enough. Maybe it would be good to note in git-sh-setup.sh that
> many of the supplied functions will not work when called from within
> $GIT_DIR.
Sorry, "supplied functions"? Care to clarify with a patch?
^ permalink raw reply
* Re: how to access working tree from .git dir?
From: Josh England @ 2007-09-07 22:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vhcm62lru.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-09-07 at 14:44 -0700, Junio C Hamano wrote:
> Josh England <jjengla@comcast.net> writes:
>
> > ... there doesn't seem to be a
> > good way to access the top of the working tree from within the GIT_DIR.
> > Since I now know that post-receive has a CWD in .git, I could just use
> > `pwd`/../ , but I was hoping for a better (read: consistent between
> > hooks) solution.
>
> I do not think it is a bad thing for _your_ script to have the
> knowledge that in _your_ repositories everywhere, the top of the
> work tree is $GIT_DIR/.. and there is no repository that lacks a
> work tree. Obviously that would not work for people with bare
> repositories, but they would not be using _your_ script in their
> bare repositories, so that is Ok.
OK. Fair enough. Maybe it would be good to note in git-sh-setup.sh that
many of the supplied functions will not work when called from within
$GIT_DIR.
-JE
^ permalink raw reply
* Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Junio C Hamano @ 2007-09-07 22:08 UTC (permalink / raw)
To: Carl Worth; +Cc: Nicolas Pitre, Keith Packard, Git Mailing List
In-Reply-To: <87r6lab0rw.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> On Fri, 07 Sep 2007 13:32:30 -0700, Junio C Hamano wrote:
>> So I am all for making an ambiguous refname an error in 1.5.4.
>
> If you do, then please also make it an error to create an ambiguous
> refname as well.
Yeah, didn't I also suggest that already?
^ permalink raw reply
* Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Carl Worth @ 2007-09-07 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Keith Packard, Git Mailing List
In-Reply-To: <7vejha43oh.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 468 bytes --]
On Fri, 07 Sep 2007 13:32:30 -0700, Junio C Hamano wrote:
> So I am all for making an ambiguous refname an error in 1.5.4.
If you do, then please also make it an error to create an ambiguous
refname as well.
For example, look at how late the warning comes out in this case, and
how changing it to an error at that point would not help anything:
$ git branch tmp
$ ...
$ git tag tmp # No warning here!
$ git show tmp
warning: refname 'tmp' is ambiguous.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: checkout and rm
From: Junio C Hamano @ 2007-09-07 22:00 UTC (permalink / raw)
To: Jeff Jenkins; +Cc: git
In-Reply-To: <4F2CF06E-CCC6-4597-A1BF-663BC36B9A94@ShopWiki.com>
Jeff Jenkins <Jeff@ShopWiki.com> writes:
> With stash in 1.5.3 the only reason I
> can think of to allow working directory changes to propagate is gone
This reasoning is utterly wrong.
We often begin exploring a solution while on one branch (perhaps
'master'), starting with small changes in the work tree, and
then realize that it needs to be worked on in a separate branch:
$ edit some work tree files
$ git branch new-topic
$ git checkout new-topic
Or maybe we would realize that the fix we started to work on
while on 'master' also applies to 'maint', and do the checkout
without creating a new branch:
$ edit some work tree files
$ git checkout maint
In either case, it is a _good_ thing that you can take your
local changes with you when you switch branches, without extra
stash/unstash sequence, and I do not think this is going to
change.
About the "lost remove", I think it is related to the fact that
we try to be usable in a sparsely checked out work tree, and
during a two-way merge (aka "switching branches") we consider a
missing file equivalent to an unmodified file and this might be
a bug in the logic to implement it there. I haven't checked
this conjecture and won't have time now to do the digging myself
(you're welcome to do the digging yourself in the meantime). It
may turn out to be a trivial change, but I dunno at this moment.
^ permalink raw reply
* Re: how to access working tree from .git dir?
From: Junio C Hamano @ 2007-09-07 21:44 UTC (permalink / raw)
To: Josh England; +Cc: Git Mailing List
In-Reply-To: <1189200421.12525.8.camel@beauty>
Josh England <jjengla@comcast.net> writes:
> ... there doesn't seem to be a
> good way to access the top of the working tree from within the GIT_DIR.
> Since I now know that post-receive has a CWD in .git, I could just use
> `pwd`/../ , but I was hoping for a better (read: consistent between
> hooks) solution.
I do not think it is a bad thing for _your_ script to have the
knowledge that in _your_ repositories everywhere, the top of the
work tree is $GIT_DIR/.. and there is no repository that lacks a
work tree. Obviously that would not work for people with bare
repositories, but they would not be using _your_ script in their
bare repositories, so that is Ok.
You can also configure core.worktree in $GIT_DIR/config and use
that from the hook script, I presume, although I haven't done it
(and do not see a need to do so) myself yet.
^ permalink raw reply
* [PATCH] (cvs|svn)import: Ask git-tag to overwrite old tags.
From: Michael Smith @ 2007-09-07 21:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzlzy2o46.fsf@gitster.siamese.dyndns.org>
If the tag was moved in CVS or SVN history, it will be moved in the
imported history as well. Tag history is not tracked.
---
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.3.1.20.gb860
^ permalink raw reply related
* Re: how to access working tree from .git dir?
From: Josh England @ 2007-09-07 21:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v642m436q.fsf@gitster.siamese.dyndns.org>
On Fri, 2007-09-07 at 13:43 -0700, Junio C Hamano wrote:
> "Josh England" <jjengla@sandia.gov> writes:
>
> > In messsing around with hooks, I've discovered that not all hooks are
> > run in the same environment. In particular, the current working
> > directory in the post-receive hook (maybe others as well) is the GIT_DIR
> > (.git) directory, instead of the root of the working tree (as in
> > pre-commit).
>
> It is not even "instead of"; that's the only sane thing to do
> for post-receive, which is in response to git-push and usually
> used for a bare repository, i.e. without any work tree.
I thought there was probably a sane reason for it. That is perfectly
acceptable, but the problem still exists that there doesn't seem to be a
good way to access the top of the working tree from within the GIT_DIR.
Since I now know that post-receive has a CWD in .git, I could just use
`pwd`/../ , but I was hoping for a better (read: consistent between
hooks) solution.
-JE
^ permalink raw reply
* Re: [PATCH] introduce config core.binaryCheckFirstBytes for xdiff-interface
From: Junio C Hamano @ 2007-09-07 21:19 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20070907191421.5526.qmail@f74fa18bc10c8f.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> 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,
If the user has to set this to suit git better for a particular
project, I think the same effort is better spent on setting up
the attribute for that file so that git does not have to guess
the type, no?
^ permalink raw reply
* Re: [PATCH] git-clone: better error message if curl program is missing
From: Junio C Hamano @ 2007-09-07 21:19 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20070907171400.28590.qmail@d780fac1e27de6.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> 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
Perhaps we should die at this point so that...
> Cannot get remote repository information.
> Perhaps git-update-server-info needs to be run there?
the user does not have to see this.
In other words, instead of this:
> 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"
> }
something like this, perhaps:
http_fetch () {
# $1 = remote, $2 = local
curl -nsfL $curl_extra_args "$1" >"$2" || exit
}
Then the shell would say "curl: command not found" and we would
stop.
I am just hestating to use "type" there (yeah, I know mergetool
has one but that one is not as close to the core of the workflow
as git-fetch is).
BTW, isn't it a packaging bug not to depend git-fetch on curl?
^ permalink raw reply
* Re: [PATCH] HEAD, ORIG_HEAD and FETCH_HEAD are really special.
From: Pierre Habouzit @ 2007-09-07 21:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Keith Packard, Git Mailing List
In-Reply-To: <7vabry43cg.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]
On Fri, Sep 07, 2007 at 08:39:43PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > 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
>
> I would even suggest making it into an error, even if we do not
> error out on the reading side (being liberal when reading but
> more strict when creating, that is).
>
> That confused_ref() needs to be tightened further, by the way.
> It is called only when we are considering to tack the user
> string immediately below $GIT_DIR/ so the only valid cases are
> (1) the string begins with "refs/", or (2) the string is all
> uppercase (or underscore), especially without slash. The one in
> the proposed patch is not strict enough and does not enforce the
> former.
I reckon I didn't checked what the function did in detail, just the
code layout :) And I agree an error is event better, I just don't have
enough knowledge of the scripts that used refs in git for a long time
that such a change could break. I mean, I only use git since the 1.2
(maybe even 1.3) series :)
I'm always all for refusing dangerous layouts rather than trying too
hard to support cumbersome things that are 99% of the times issues :)
--
·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: Pierre Habouzit @ 2007-09-07 20:56 UTC (permalink / raw)
To: Walter Bright; +Cc: git
In-Reply-To: <fbsd0g$gt6$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]
On Fri, Sep 07, 2007 at 08:40:56PM +0000, Walter Bright wrote:
> Pierre Habouzit wrote:
> >And for that bit-fields are
> >a really really fast and simple way to describe things.
>
> I should point out that inline functions are inlined, and there is no
> speed difference in the result.
I know that, and that's why I said I was totally fine with the
bitfield notation to be only syntactic sugar on a template thingy if
that's the simplest way to have that it's OKay.
> > 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.
>
> I'm not following this. To copy a union, you just copy it with the
> assignment operator:
>
> U a, b;
> a = b; // copies all the bit fields, too!
That was the point indeed. But if you don't have bitfields, you can't
do the union. And if the bitfield is just syntactic sugar, it may be
unpossible to have such a union. But I may be wrong.
> >Right now, for D, only
> >gdc exists, it lags behind dmd quite a lot afaict, and there is no other
> >toolchain helpers yet.
>
> GDC was just released for D 1.020, which is behind D 1.021, but 1.021 was
> released just a couple days ago <g>.
Sure, but it does not works on amd64 properly (and it's the
architecture I care about) and is not ready for the current gcc (4.2,
only 4.1 builds) and so on. It's not as stable as DMD is. It does not
lags too much version-wise, it lags in maturity. But well, youth has a
cure: time :)
--
·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] svnimport/cvsimport: force creation of tags that already exist.
From: Junio C Hamano @ 2007-09-07 20:54 UTC (permalink / raw)
To: Michael Smith; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709071125090.6203@juice.ott.cti.com>
Michael Smith <msmith@cbnco.com> writes:
> 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.
I think the patch itself makes sense. If for some reason the
importer detects that the CVS or SVN history moved a tag, we
either:
(1) have a way to keep track of the versions of the tag; or
(2) allow it and make it "last one wins" semantics; or
(3) ignore it and make it "first one wins" semantics.
Erroring out complaining that the tag cannot be created, as the
current code does, does not make any sense.
The patch needs to be accompanied with a better commit log
description. I am guessing that with your change the semantics
would become (2) above (assuming that cvsps or whoever reads the
history of the other side gives events in chronological order),
but you should not force readers of your commit log message to
guess.
^ permalink raw reply
* Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
From: Walter Bright @ 2007-09-07 20:49 UTC (permalink / raw)
To: git
In-Reply-To: <85wsv22ry8.fsf@lola.goethe.zz>
David Kastrup wrote:
> 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.
I agree. It's one of those things that probably sounded like a good idea
at the time. The consequences were not foreseen. All languages have a
few of these (C++ has the infamous use of < > for template arguments).
^ 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