* Re: [PATCH] diff: resurrect the traditional empty "diff --git" behaviour
From: Junio C Hamano @ 2007-09-03 8:36 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Steven Grimm, git, Michael S. Tsirkin, Jeff King
In-Reply-To: <vpqveasmaqo.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> I'd rather avoid talking about plumbing in the documentation of
> porcelain, so I'd say "silently refreshes the index's stat
> information".
Sounds like a much better wording.
^ permalink raw reply
* Re: [StGIT PATCH 4/4] Add optional logging of subprocess execution
From: Catalin Marinas @ 2007-09-03 8:36 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20070829111102.GA29980@diana.vm.bytemark.co.uk>
On 29/08/07, Karl Hasselström <kha@treskal.com> wrote:
> Any chance we can drop Python 2.3 support any time soon, by the way?
> I've confined all the ickyness to one place, but it would still be
> good to get rid of it (not to mention being able to use sets and
> generator expressions).
Unless there is no objection, I'm actually OK with this. Feel free to
break the 2.3 support from now on. I'll add a note stating the minimum
versions for Python and GIT in the 0.14 release.
--
Catalin
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: Junio C Hamano @ 2007-09-03 8:35 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Sean, David Kastrup, git
In-Reply-To: <46DBC1EE.3020009@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
>> Ok, should I then do that single change, cut 1.5.3.1 with it and
>> ping you?
>
> Sounds good to me.
Thanks, and sorry for the trouble. I am building one on k.org,
and after placing the result in the RPMS/x86-64 and running the
yummy script, I'll ping you again. If it installs fine for you,
I'll boot my wife's machine to do i386 as well, but it is
getting a bit late now, so it might have to be tomorrow.
-- >8 -- snipsnap -- >8 -- clipcrap -- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Sun, 2 Sep 2007 15:16:44 -0700
Subject: [PATCH] GIT 1.5.3.1: obsolete git-p4 in RPM spec file.
HPA noticed that yum does not like the newer git RPM set; it turns out
that we do not ship git-p4 anymore but existing installations do not
realize the package is gone if we do not tell anything about it.
David Kastrup suggests using Obsoletes in the spec file of the new
RPM to replace the old package, so here is a try.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git.spec.in | 1 +
Documentation/RelNotes-1.5.3.1.txt | 10 ++++++++++
Documentation/git.txt | 5 ++++-
GIT-VERSION-GEN | 2 +-
RelNotes | 2 +-
5 files changed, 17 insertions(+), 3 deletions(-)
create mode 100644 Documentation/RelNotes-1.5.3.1.txt
diff --git a/git.spec.in b/git.spec.in
index fe7b3d8..bdb293d 100644
--- a/git.spec.in
+++ b/git.spec.in
@@ -25,6 +25,7 @@ This is a dummy package which brings in all subpackages.
Summary: Core git tools
Group: Development/Tools
Requires: zlib >= 1.2, rsync, curl, less, openssh-clients, expat
+Obsoletes: git-p4
%description core
Git is a fast, scalable, distributed revision control system with an
unusually rich command set that provides both high-level operations
diff --git a/Documentation/RelNotes-1.5.3.1.txt b/Documentation/RelNotes-1.5.3.1.txt
new file mode 100644
index 0000000..7ff546c
--- /dev/null
+++ b/Documentation/RelNotes-1.5.3.1.txt
@@ -0,0 +1,10 @@
+GIT v1.5.3.1 Release Notes
+==========================
+
+Fixes since v1.5.3
+------------------
+
+This is solely to fix the generated RPM's dependencies. We used
+to have git-p4 package but we do not anymore. As suggested on
+the mailing list, this release makes git-core "Obsolete" git-p4,
+so that yum update would not complain.
diff --git a/Documentation/git.txt b/Documentation/git.txt
index ceca892..6f7db29 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -43,7 +43,10 @@ unreleased) version of git, that is available from 'master'
branch of the `git.git` repository.
Documentation for older releases are available here:
-* link:v1.5.2.5/git.html[documentation for release 1.5.2.5]
+* link:v1.5.3/git.html[documentation for release 1.5.3]
+
+* release notes for
+ link:RelNotes-1.5.3.1.txt[1.5.3.1].
* release notes for
link:RelNotes-1.5.2.5.txt[1.5.2.5],
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index 3c0032c..3835fb3 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -1,7 +1,7 @@
#!/bin/sh
GVF=GIT-VERSION-FILE
-DEF_VER=v1.5.3.GIT
+DEF_VER=v1.5.3.1.GIT
LF='
'
diff --git a/RelNotes b/RelNotes
index 0de5e66..ea8f800 120000
--- a/RelNotes
+++ b/RelNotes
@@ -1 +1 @@
-Documentation/RelNotes-1.5.3.txt
\ No newline at end of file
+Documentation/RelNotes-1.5.3.1.txt
\ No newline at end of file
--
1.5.3
^ permalink raw reply related
* Re: [StGIT PATCH 4/4] Add optional logging of subprocess execution
From: Catalin Marinas @ 2007-09-03 8:34 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20070829171621.GA2214@diana.vm.bytemark.co.uk>
On 29/08/07, Karl Hasselström <kha@treskal.com> wrote:
> On 2007-08-29 13:11:02 +0200, Karl Hasselström wrote:
>
> > On 2007-08-29 11:50:11 +0100, Catalin Marinas wrote:
> >
> > > Any objection to calling this variable STGIT_SUBPROCESS_LOG? We
> > > already have STGIT_DEBUG_LEVEL (used in stgit.main). I can do it
> > > in my tree before pushing as I already merged your branches.
> >
> > No, no objection at all. I was simply too lazy to actually check
> > what the existing naming convention was, and misremembered.
>
> You changed it in the code, but forgot to change it in the commit
> message. :-P
I changed it on my office PC and the locale setup breaks your name
encoding :-). I tried to avoid it.
--
Catalin
^ permalink raw reply
* Re: StGIT experimental branches updated
From: Catalin Marinas @ 2007-09-03 8:29 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20070903002029.GA31957@diana.vm.bytemark.co.uk>
On 03/09/07, Karl Hasselström <kha@treskal.com> wrote:
> I've added the three patches I just sent out. That's all, since no one
> else seems to be working. :-)
It's Monday (and morning) :-). Thanks, I merged the 'safe' branch
> Plus, I've renamed the branches to "safe" and "experimental", since
> that's what they're all about.
It makes more sense.
BTW, would an extension to 'stg import' to import patches from mailing
lists (NNTP or maybe just mbox) directly be useful? There is support
for mbox importing anyway and it would need a procmail filter to
generate the mbox and just a regex filtering in 'import' to apply the
StGIT patches only.
--
Catalin
^ permalink raw reply
* Re: Stats in Git
From: Matthieu Moy @ 2007-09-03 8:19 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Git Mailing List
In-Reply-To: <46DACD93.9000509@trolltech.com>
Marius Storm-Olsen <marius@trolltech.com> writes:
> However, while look at that whole stat'ing situation in git, I saw
> that doing 'git status' actually stats all the files _thrice_!
> Yup, that's not 1 time, or 2 times, but actually 3(!) times before
> 'git status' is content!
My experiments show 2 stats only:
$ strace -f git status |& grep -e execve -e foo
[...]
[pid 22492] execve("/home/moy/local/usr//bin/git", ["git", "update-index", "-q", "--unmerged", "--refresh"], [/* 50 vars */]) = 0
[pid 22492] lstat64("foo", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
[pid 22493] execve("/home/moy/local/usr//bin/git", ["git", "runstatus"], [/* 49 vars */]) = 0
[pid 22493] lstat64("foo", {st_mode=S_IFREG|0755, st_size=0, ...}) = 0
[...]
Once for "git update-index --refresh" and once more for "git
runstatus". Obviously, a builtin with one tree traversal only would
provide a good speedup.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] Teach "git remote" a mirror mode
From: Junio C Hamano @ 2007-09-03 8:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709022101290.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When using the "--mirror" option to "git remote add", the refs will not
> be stored in the refs/remotes/ namespace, but in the same location as
> on the remote side.
Thanks. With this and the "git remote rm" I think we would be
in much better shape. Another thing that would be needed
further before we can rewriting git-clone would be the "guessing
where HEAD points at" and we would be in a very good shape.
I notice you did not add any tests, though...
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: H. Peter Anvin @ 2007-09-03 8:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sean, David Kastrup, git, linux-kernel
In-Reply-To: <7vr6lgmao5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
>
>> Sean wrote:
>>> Given the comment from David, I suspect your patch is all
>>> that's needed; hopefully Peter can give it a quick test.
>> It sounds like it; I don't know how to test it other than placing in
>> the repository and try to upgrade. It can't be any worse, so I don't
>> see any harm in just doing it.
>
> Ok, should I then do that single change, cut 1.5.3.1 with it and
> ping you?
Sounds good to me.
-hpa
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: Junio C Hamano @ 2007-09-03 8:10 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Sean, David Kastrup, git, linux-kernel
In-Reply-To: <46DBBD00.5090308@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Sean wrote:
>>
>> Given the comment from David, I suspect your patch is all
>> that's needed; hopefully Peter can give it a quick test.
>
> It sounds like it; I don't know how to test it other than placing in
> the repository and try to upgrade. It can't be any worse, so I don't
> see any harm in just doing it.
Ok, should I then do that single change, cut 1.5.3.1 with it and
ping you?
^ permalink raw reply
* Re: [PATCH] diff: resurrect the traditional empty "diff --git" behaviour
From: Matthieu Moy @ 2007-09-03 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Grimm, git, Michael S. Tsirkin, Jeff King
In-Reply-To: <7vir6vw4x2.fsf@gitster.siamese.dyndns.org>
I fully agree with the two patches (that's what I've been arguing for
hours last time we talked about it, so no big surprise ;-) ).
One documentation nitpick :
Junio C Hamano <gitster@pobox.com> writes:
> +diff.autorefreshindex::
> + When using `git diff` to compare with work tree
> + files, do not consider stat-only change as changed.
> + Instead, silently run `git update-index --refresh`
I'd rather avoid talking about plumbing in the documentation of
porcelain, so I'd say "silently refreshes the index's stat
information".
But I'm arguably wrong on that point, I let you decide.
Thanks,
--
Matthieu
^ permalink raw reply
* Re: [PATCH] send-email: Add support for SSL and SMTP-AUTH
From: Junio C Hamano @ 2007-09-03 7:58 UTC (permalink / raw)
To: Douglas Stockwell; +Cc: gitster, git
In-Reply-To: <11887563853329-git-send-email-doug@11011.net>
Douglas Stockwell <doug@11011.net> writes:
> Allows username and password to be given using --smtp-user
> and --smtp-pass. SSL use is flagged by --smtp-ssl. These are
> backed by corresponding defaults in the git configuration file.
>
> This implements Junio's 'mail identity' suggestion in a slightly
> more generalised manner. --identity=$identity, backed by
> sendemail.identity indicates that the configuration subsection
> [sendemail "$identity"] should take priority over the [sendemail]
> section for all configuration values.
Even better than what I suggested, doing a lot more with the
same identity mechanism. I think it often is the case that
"when I work on this project, I send e-mail as this user to talk
with that server to send e-mail, and that server happens to talk
smtps so use that", and a single "identity" setting is a good
way to capture that. Very nice.
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Marius Storm-Olsen @ 2007-09-03 7:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List, Johannes Schindelin, Johannes Sixt
In-Reply-To: <46DBBC1E.4010407@eudaptics.com>
[-- Attachment #1: Type: text/plain, Size: 423 bytes --]
Johannes Sixt said the following on 03.09.2007 09:47:
> Marius Storm-Olsen schrieb:
>> This gives us a significant speedup when adding, committing and
>> stat'ing files. (Also, since Windows doesn't really handle
>> symlinks, it's fine that stat just uses lstat)
>
> Unfortunately, the patch fails t0010-racy-git.sh. I suspect the
> filetime conversion:
Ok, I'll try to get to it later today.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: H. Peter Anvin @ 2007-09-03 7:51 UTC (permalink / raw)
To: Sean; +Cc: Junio C Hamano, David Kastrup, git, linux-kernel
In-Reply-To: <20070902191644.29d46cd2.seanlkml@sympatico.ca>
Sean wrote:
>
> Given the comment from David, I suspect your patch is all
> that's needed; hopefully Peter can give it a quick test.
>
It sounds like it; I don't know how to test it other than placing in the
repository and try to upgrade. It can't be any worse, so I don't see
any harm in just doing it.
-hpa
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Johannes Sixt @ 2007-09-03 7:47 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Git Mailing List, Johannes Schindelin, Johannes Sixt
In-Reply-To: <46DACE0D.5070501@trolltech.com>
Marius Storm-Olsen schrieb:
> This gives us a significant speedup when adding, committing and stat'ing files.
> (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)
Unfortunately, the patch fails t0010-racy-git.sh. I suspect the filetime
conversion:
> -int lstat(const char *file_name, struct stat *buf)
> +static inline time_t filetime_to_time_t(const FILETIME *ft)
> +{
> + long long winTime = ((long long)ft->dwHighDateTime << 32) + ft->dwLowDateTime;
> + winTime -= 116444736000000000LL; /* Windows to Unix Epoch conversion */
> + winTime /= 10000000; /* Nano to seconds resolution */
Shouldn't this be 1000000000 according to your comment? However, even if
I make that change, the test still fails. Could you please look into this?
> + return (time_t)winTime;
> +}
-- Hannes
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.3
From: H. Peter Anvin @ 2007-09-03 7:46 UTC (permalink / raw)
To: Sean; +Cc: David Kastrup, Junio C Hamano, git, linux-kernel
In-Reply-To: <20070902133803.1b46f599.seanlkml@sympatico.ca>
Sean wrote:
> On Sun, 02 Sep 2007 10:57:03 +0100
> "H. Peter Anvin" <hpa@zytor.com> wrote:
>
>> From the looks of it, there is still a git-p4, it just moved to contrib
>> and uses fast-import, so removing its rpm package was probably broken in
>> the first place.
>
> Hi Peter,
>
> Items in contrib aren't officially supported, so it doesn't sound like
> a good idea to offer installs for them. Of course, it might be a good
> idea to promote git-p4 up out of contrib and add it to the spec file.
Well, the old one was out of contrib, too. Maybe it should never have
been packaged up, but it was...
> As things stand now, do you get an error when trying to upgrade Git via
> yum? I'd have thought things would upgrade fine but leave the old git-p4
> rpm hanging around. Either way, the obsoletes line mentioned by David
> sounds like the right solution.
Yes, it gets an error, because all the git RPMs are tied together by
explicit version number and so can only be upgraded as a group.
> As an aside, when I sent the patch removing git-p4import from the spec
> file I mentioned that I had no way to test it and asked for testers.
> Git needs a spec file maintainer so that issues like this can be caught
> before release. Without a maintainer, it should probably be demoted
> to contrib itself.
Well, git on kernel.org (and many other places) critically depends on
rpms being available.
-hpa
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Johannes Sixt @ 2007-09-03 7:07 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Marius Storm-Olsen, Johannes Sixt, git
In-Reply-To: <200709022342.42733.robin.rosenberg.lists@dewire.com>
Robin Rosenberg schrieb:
> $ ln -s Makefile x
> $ cp x y
> $ ls -ld x y
> lrwxrwxrwx 1 me me 8 sep 2 23:36 x -> Makefile
> -rw-r--r-- 1 me me 32164 sep 2 23:36 y
And if I understand the documentation correctly, then
$ mkdir foo && cd foo
$ cat ../x
x: No such file or directory
Right?
The docs say that symlinks without backslash are relative to the current
directory (!!!).
-- Hannes
^ permalink raw reply
* Re: [PATCH] send-email: Add support for SSL and SMTP-AUTH
From: Wincent Colaiuta @ 2007-09-03 6:48 UTC (permalink / raw)
To: Douglas Stockwell; +Cc: gitster, git
In-Reply-To: <11887563853329-git-send-email-doug@11011.net>
El 2/9/2007, a las 20:06, Douglas Stockwell escribió:
> Allows username and password to be given using --smtp-user
> and --smtp-pass. SSL use is flagged by --smtp-ssl. These are
> backed by corresponding defaults in the git configuration file.
>
> This implements Junio's 'mail identity' suggestion in a slightly
> more generalised manner. --identity=$identity, backed by
> sendemail.identity indicates that the configuration subsection
> [sendemail "$identity"] should take priority over the [sendemail]
> section for all configuration values.
This will be really useful to me in my current set-up. I'll test it
here locally and let you know if I can find any problems.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Marius Storm-Olsen @ 2007-09-03 6:15 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <200709022228.00733.robin.rosenberg.lists@dewire.com>
[-- Attachment #1: Type: text/plain, Size: 621 bytes --]
Robin Rosenberg said the following on 02.09.2007 22:27:
> söndag 02 september 2007 skrev Marius Storm-Olsen:
>> (Also, since Windows doesn't really handle symlinks, it's fine that stat just uses lstat)
>
> It does now: See http://msdn2.microsoft.com/en-us/library/aa363866.aspx
Yeah, I know about Vista's improved support for symbolic links.
However, I think we can let that lay for a while, until we decide to
make Git generate proper symlinks on Vista. I don't see it as a 1st
priority at the moment, and we can always add the needed functionality
in a separate stat() function later.
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH] Add a new lstat implementation based on Win32 API, and make stat use that implementation too.
From: Marius Storm-Olsen @ 2007-09-03 6:12 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Sixt, git, Johannes Schindelin
In-Reply-To: <20070902214128.GC2756@steel.home>
[-- Attachment #1: Type: text/plain, Size: 1241 bytes --]
Alex Riesen said the following on 02.09.2007 23:41:
> Marius Storm-Olsen, Sun, Sep 02, 2007 21:31:40 +0200:
>> + buf->st_ino = 0;
>
> You sure about that? Ever wondered why it is not so on everywhere else?
Pretty sure. If you look at Windows' native version of stat, it will
return you st_ino = 0. Or maybe you where referring to something else,
and I just missed your point?
AFAIK, the ino in the index is only to be _really_ sure that nothing
has changed with the file, and we can just skip it on Windows. If in
doubt, try running this on your Windows box:
#include <windows.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
int main(int, char **)
{
wchar_t DirSpec[] = L".\\*";
WIN32_FIND_DATA FindFileData;
HANDLE hFind = FindFirstFile(DirSpec, &FindFileData);
if (hFind == INVALID_HANDLE_VALUE) {
printf ("Crap happened: %u\n", GetLastError());
return -1;
}
struct _stat buf;
while (FindNextFile(hFind, &FindFileData) != 0)
{
if (!_wstat(FindFileData.cFileName, &buf))
printf("file: %S, ino: %u\n", FindFileData.cFileName, buf.st_ino);
}
FindClose(hFind);
return 0;
}
--
.marius
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: strbuf API
From: Johan Herland @ 2007-09-03 5:43 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit
In-Reply-To: <20070902224213.GB431@artemis.corp>
On Monday 03 September 2007, Pierre Habouzit wrote:
>
> I read the recent thread Timo Sirainen raised about string APIs in
> git. ANd I went read the strbuf.[hc] module.
>
> I believe that the choice made in that module are wrong and could be
> made better. I actually use to work with a string buffer API (that
> interested readers can look at on [0]), that work almost the same
> (except for the eof flag, but it's trivial to keep), but have
> two significant differences:
>
> First, and that's the most important one: the buffer is always NUL
> terminated, after its official "len". That means, in terms of strbuf
> API, that "alloc" is always greater or equal to len+1 to be able to
> store the ending NUL[1]. The advantages are obvious: you can pass the
> buffer to any legacy C string function without any fear of read
> overflow. strtol comes to mind, and atm, git has to explicitely use
> strbuf_end to put that ending nul to be able to call legacy
> applications. But once done, the NUL is accounted into the string (aka
> it's in "len") which makes it a non C-string (I mean you cannot append
> any more data in it anymore). So current implementations tries to
> workaround an issue (the non systematical NUL-termination) but IMHO the
> wrong way.
>
> The other shortcoming is that you cannot tell the buffer "Hey, it's
> very likely that you'll end up being _that_ long. That's why, in some
> parts of the code (see write_tar_entry in archive-tar.c e.g.) the
> programmer actually messes with the buffer allocation, outside from the
> strbuf module, which makes it well, useless. In my API, I have a
> "buffer_ensure" call, that is supposed to do that: "please ensure that
> this buffer still has _this_ amount of free and allocated space to put
> more data".
>
>
> So my question is, do people think I raise a valid point
Yes.
> , and would
> patches that would refactor the strbuf module to have those functions,
> and would fix the code that uses strbuf's to interact properly, be
> accepted ?
I don't know. Keep in mind that there is a parallel process (cf. the
continuation of the "Buffer overflows" thread) to evaluate the Bstring
library ( http://bstring.sourceforge.net/ ), and possibly substitute that
for the strbuf "module".
I wouldn't want the work done by you or others to be wasted (depending on
which solution wins out in the end), so I suggest you take a look at
bstring and offer up arguments why your solution would be better for git.
> Also, the efficiency of the buffer module API I use has a lot to do
> with the fact that copying functions, and length tests are inlined in
> the .h, so that the compiler can optimize the ones it already tested 10
> calls before. I'm not sure if this is frowned upon or if it makes sense.
>
>
> [0] http://git.madism.org/?p=pfixtools.git;a=blob;f=buffer.h;hb=HEAD
> http://git.madism.org/?p=pfixtools.git;a=blob;f=buffer.c;hb=HEAD
>
> [1] Of course, ensuring the NUL-termination has a cost, though it's
> often benign, and for performance-critical places where characters
> are copied one by one, it's always possible to use an "unsafe"
> addch (that would not maintain the invariant), and then call an
> equivalent of strbuf_end (that would not append a \0 like it does
> now, but just would fix the invariant that for any strbuf,
> buf->buf[buf->len] == '\0') explicitely. For places where the
> invariant generate negligible cost (like concatenating two paths
> parts with a middle '/' e.g.) then we gain safety without even
> having to think about it.
All the points you raise are valid, but please have in mind that all
programmers write their own string library at some point. (Writing a string
library is right up there with "discovering why 'goto' is bad" and "2nd
system syndrome" on the top list of rites of passage all programmers (need
to) go through. I'm guessing 99% of the people on this list have written
their own string library. Why not 100%? Well, Linus have obviously not,
else we'd be using his already... ;)
I'd like to know how your solution compare with the alternatives (in this
case bstring): What's the performance compared to bstring? How much thought
has been given to the usability of the API? What functionality is covered
(compared to bstring)? In short: Why is your alternative the best for git?
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] git-gui: remove dots in some UI strings
From: Shawn O. Pearce @ 2007-09-03 4:51 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git
In-Reply-To: <200709021443.00144.barra_cuda@katamail.com>
Michele Ballabio <barra_cuda@katamail.com> wrote:
> Dots in a UI string usually mean that a dialog box will
> appear waiting for further input. So this patch removes
> unneeded dots for actions that do not require user's
> input.
Thanks, that's a good usability improvement. I had already merged
the i18n work that everyone has been working on so I adjusted your
patch to apply on top of that series and pushed everything back
out in my master branch.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 00/15] i18n support for git-gui
From: Shawn O. Pearce @ 2007-09-03 4:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0709021738090.28586@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> sorry for the fsckup with the first two patches; both should be attributed
> to Christian Stimming.
>
> For convenience, I also uploaded that patch series (on top of your
> "git-gui: Initialize Tcl's msgcat library for internationalization" in
> your "pu" branch) to the "for-shawn" branch in git-gui-i18n.
That was *much* easier than the small patch bomb. ;-)
I've swallowed this series down and added it to my `master` branch.
I found one bug in the [mc "..."] string definitions and fixed it
(below). I also applied Michele Ballabio's "remove does in some
UI strings" patch on top. Those two changes I'm sure will impact
some of the translated strings. I guess someone needs to run `make
update-po` and ask translators to revise the individual languages?
-->8--
From b86882eda026a0da18472587034250a53e0daf51 Mon Sep 17 00:00:00 2001
From: Shawn O. Pearce <spearce@spearce.org>
Date: Mon, 3 Sep 2007 00:22:19 -0400
Subject: [PATCH] git-gui: Correct stock message for 'Invalid font specified in %s'
This particular message is talking about a specific option in the
configuration file named "gui.$name". This option is not localized
so we cannot localize the "gui." that denotes the section the option
$name is found within. Currently there are no plans to localize the
configuration options for git-gui, but if that were to change in the
future then it would be necessary to localize not only the "gui."
section prefix but also the $name (fontui and fontdiff).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 913ba68..5635eea 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1643,7 +1643,7 @@ proc apply_config {} {
font configure $font $cn $cv
}
} err]} {
- error_popup [append [mc "Invalid font specified in gui.%s:" $name] "\n\n$err"]
+ error_popup [append [mc "Invalid font specified in %s:" "gui.$name"] "\n\n$err"]
}
foreach {cn cv} [font configure $font] {
font configure ${font}bold $cn $cv
--
1.5.3
--
Shawn.
^ permalink raw reply related
* Re: Google Summer of Code 2007 progress report / summary
From: Shawn O. Pearce @ 2007-09-03 3:42 UTC (permalink / raw)
To: git
Cc: Jakub Narebski, Johannes Schindelin, Luiz Fernando N. Capitulino,
Carlos Rica
In-Reply-To: <200709030309.30996.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> How it goes with Google Summer of Code git projects:
> builtinification and libification? Which parts are
> done, which parts are worked on?
Heh. You caught me literally as I was drafting the roundup. ;-)
The 2007 version of Google Summer of Code[*1*] ended on August 20th.
For those who may be new to the list, Git participated this year
in Google Summer of Code with two successful student projects:
Shell script to C builtin conversions
Student: Carlos Rica
Mentor: Johannes Schindelin
Libification
Student: Luiz Capitulino
Mentor: Shawn Pearce
In addition to paying two students to work on Git for the entire
summer Google also donated $1000 USD to our community. As Git has
no legal entity to receive or make use of these funds we directed
the full $1000 donation to the Free Software Foundation.
A good part of Carlos Rica's work is in Git 1.5.3 and brought us a
C based version of git-tag, as well as a comprehensive test suite
for git-tag and its various modes of operation. Additionally Carlos
fixed a few bugs and improved some of the internal code to make a
C based version of git-commit easier to develop. Carlos has more
recently been working on a C based version of git-reset, which will
hopefully be in the next version of Git (1.5.3.1? 1.5.4?).
Luiz Capitulino has found and submitted a few bug fixes to Git
1.5.3, but the majority of his work on creating an application
level library is still unmerged and can be found on repo.or.cz[*2*].
Luiz developed a C and Python log API and announced it on list[*3*]
near the end of July. During August Luiz also worked with Marco
Costalba to modify qgit4 to use Luiz's log API. This work is
currently stalled as Luiz has shifted his attention to expanding
and rebasing the work that Nico and I had done for pack v4 onto
current Git 1.5.3. Luiz also tried to port StGIT to use this new
Python API but determined that StGIT needs more functions than the
API currently offers. It may be interesting if someone picks up
this API work and continues it further.
I would like to thank our two students for their excellent work,
but also Brian Gernhardt, Johannes Schindelin, Martin Langhoff,
Martin Waitz, Petr Baudis, and Sam Vilain for helping us to review
student applications and for volunteering to mentor students.
*1* http://code.google.com/soc/2007/
*2* http://repo.or.cz/w/git/libgit-gsoc.git
*3* http://article.gmane.org/gmane.comp.version-control.git/53433
--
Shawn.
^ permalink raw reply
* Re: [PATCH 0/5] gitweb: Support for arbitrary diffs
From: Junio C Hamano @ 2007-09-03 2:10 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jakub Narebski, git
In-Reply-To: <20070903013330.GR1219@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> To hijack this post a bit, another patch in the queue (the incremental
> blame thingie) introduces blame.js. Do you think that we should keep the
> .js files separate, or instead have one big gitweb.js with everything?
> I'm inclined to the second possibility in order to reduce the number of
> requests, but it comes at a price of slightly worse maintainability.
Is it a possibility to concatenate them at the installation
time, if a single huge file becomes a problem?
^ permalink raw reply
* Re: [PATCH] git-reset.txt: Use uniform HEAD~N notation in all examples
From: Miles Bader @ 2007-09-03 2:03 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <veauqfu0.fsf@cante.net>
Jari Aalto <jari.aalto@cante.net> writes:
> After all, the ^ very differento to what other SCM/VCSs use.
It's something I _constantly_ wished other SCM/VCSs had, as it's far,
far, more usable than the typical absolute rev numbers. It really
should be introduced as early as possible.
-Miles
--
Fast, small, soon; pick any 2.
^ 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