* [PATCH 2/2] Correct some sizeof(size_t) != sizeof(unsigned long) typing errors
From: Shawn O. Pearce @ 2007-10-21 5:25 UTC (permalink / raw)
To: git
On at least one system I've used recently sizeof(size_t) == 4
and sizeof(unsigned long) == 8. Trying to pass a pointer to an 8
byte value into strbuf_detach() causes problems as the function is
expecting an address for a 4 byte result location. Writing only 4
bytes here will leave the other 4 bytes unitialized and may cause
problems when the caller evalutes the result.
I am introducing strbuf_detach_ul() as a variant that takes its
size as an unsigned long rather than as a size_t. This approach is
shorter than fixing all of the callers to use their own temporary
size_t value for the call.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
builtin-apply.c | 2 +-
builtin-archive.c | 2 +-
diff.c | 4 ++--
entry.c | 2 +-
strbuf.h | 8 +++++++-
test-delta.c | 3 ++-
6 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 05c6bc3..022f916 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -1955,7 +1955,7 @@ static int apply_data(struct patch *patch, struct stat *st, struct cache_entry *
if (apply_fragments(&buf, patch) < 0)
return -1; /* note with --reject this succeeds. */
- patch->result = strbuf_detach(&buf, &patch->resultsize);
+ patch->result = strbuf_detach_ul(&buf, &patch->resultsize);
if (0 < patch->is_delete && patch->resultsize)
return error("removal patch leaves file contents");
diff --git a/builtin-archive.c b/builtin-archive.c
index 04385de..46d5de0 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -153,7 +153,7 @@ void *sha1_file_to_archive(const char *path, const unsigned char *sha1,
strbuf_attach(&buf, buffer, *sizep, *sizep + 1);
convert_to_working_tree(path, buf.buf, buf.len, &buf);
convert_to_archive(path, buf.buf, buf.len, &buf, commit);
- buffer = strbuf_detach(&buf, sizep);
+ buffer = strbuf_detach_ul(&buf, sizep);
}
return buffer;
diff --git a/diff.c b/diff.c
index 6648e01..6fd0c0a 100644
--- a/diff.c
+++ b/diff.c
@@ -1519,7 +1519,7 @@ static int populate_from_stdin(struct diff_filespec *s)
strerror(errno));
s->should_munmap = 0;
- s->data = strbuf_detach(&buf, &s->size);
+ s->data = strbuf_detach_ul(&buf, &s->size);
s->should_free = 1;
return 0;
}
@@ -1611,7 +1611,7 @@ int diff_populate_filespec(struct diff_filespec *s, int size_only)
if (convert_to_git(s->path, s->data, s->size, &buf)) {
munmap(s->data, s->size);
s->should_munmap = 0;
- s->data = strbuf_detach(&buf, &s->size);
+ s->data = strbuf_detach_ul(&buf, &s->size);
s->should_free = 1;
}
}
diff --git a/entry.c b/entry.c
index 98f5f6d..d36a0bb 100644
--- a/entry.c
+++ b/entry.c
@@ -120,7 +120,7 @@ static int write_entry(struct cache_entry *ce, char *path, const struct checkout
strbuf_init(&buf, 0);
if (convert_to_working_tree(ce->name, new, size, &buf)) {
free(new);
- new = strbuf_detach(&buf, &size);
+ new = strbuf_detach_ul(&buf, &size);
}
if (to_tempfile) {
diff --git a/strbuf.h b/strbuf.h
index 9b9e861..d6d6bd0 100644
--- a/strbuf.h
+++ b/strbuf.h
@@ -52,7 +52,13 @@ struct strbuf {
/*----- strbuf life cycle -----*/
extern void strbuf_init(struct strbuf *, size_t);
extern void strbuf_release(struct strbuf *);
-extern char *strbuf_detach(struct strbuf *, size_t *);
+extern char *strbuf_detach(struct strbuf *, unsigned long *);
+static inline char *strbuf_detach_ul(struct strbuf *a, unsigned long *n) {
+ size_t len;
+ char *res = strbuf_detach(a, &len);
+ *n = len;
+ return res;
+}
extern void strbuf_attach(struct strbuf *, void *, size_t, size_t);
static inline void strbuf_swap(struct strbuf *a, struct strbuf *b) {
struct strbuf tmp = *a;
diff --git a/test-delta.c b/test-delta.c
index 3d885ff..018e7dc 100644
--- a/test-delta.c
+++ b/test-delta.c
@@ -20,7 +20,8 @@ int main(int argc, char *argv[])
int fd;
struct stat st;
void *from_buf, *data_buf, *out_buf;
- unsigned long from_size, data_size, out_size;
+ unsigned long from_size, data_size;
+ size_t out_size;
if (argc != 5 || (strcmp(argv[1], "-d") && strcmp(argv[1], "-p"))) {
fprintf(stderr, "Usage: %s\n", usage_str);
--
1.5.3.4.1270.g2fe543
^ permalink raw reply related
* [PATCH] Define compat version of mkdtemp for systems lacking it
From: Shawn O. Pearce @ 2007-10-21 5:30 UTC (permalink / raw)
To: git
Solaris 9 doesn't have mkdtemp() so we need to emulate it for the
rsync transport implementation. Since Solaris 9 is lacking this
function we can also reasonably assume it is not available on
Solaris 8 either. The new Makfile definition NO_MKDTEMP can be
set to enable the git compat version.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
On top of 'next' so that the db/fetch-pack series will actually
build on Solaris 9.
Makefile | 8 ++++++++
compat/mkdtemp.c | 8 ++++++++
git-compat-util.h | 5 +++++
3 files changed, 21 insertions(+), 0 deletions(-)
create mode 100644 compat/mkdtemp.c
diff --git a/Makefile b/Makefile
index bb4873d..6287418 100644
--- a/Makefile
+++ b/Makefile
@@ -38,6 +38,8 @@ all::
#
# Define NO_SETENV if you don't have setenv in the C library.
#
+# Define NO_MKDTEMP if you don't have mkdtemp in the C library.
+#
# Define NO_SYMLINK_HEAD if you never want .git/HEAD to be a symbolic link.
# Enable it on Windows. By default, symrefs are still used.
#
@@ -414,12 +416,14 @@ ifeq ($(uname_S),SunOS)
NEEDS_LIBICONV = YesPlease
NO_UNSETENV = YesPlease
NO_SETENV = YesPlease
+ NO_MKDTEMP = YesPlease
NO_C99_FORMAT = YesPlease
NO_STRTOUMAX = YesPlease
endif
ifeq ($(uname_R),5.9)
NO_UNSETENV = YesPlease
NO_SETENV = YesPlease
+ NO_MKDTEMP = YesPlease
NO_C99_FORMAT = YesPlease
NO_STRTOUMAX = YesPlease
endif
@@ -610,6 +614,10 @@ ifdef NO_SETENV
COMPAT_CFLAGS += -DNO_SETENV
COMPAT_OBJS += compat/setenv.o
endif
+ifdef NO_MKDTEMP
+ COMPAT_CFLAGS += -DNO_MKDTEMP
+ COMPAT_OBJS += compat/mkdtemp.o
+endif
ifdef NO_UNSETENV
COMPAT_CFLAGS += -DNO_UNSETENV
COMPAT_OBJS += compat/unsetenv.o
diff --git a/compat/mkdtemp.c b/compat/mkdtemp.c
new file mode 100644
index 0000000..34d4b49
--- /dev/null
+++ b/compat/mkdtemp.c
@@ -0,0 +1,8 @@
+#include "../git-compat-util.h"
+
+char *gitmkdtemp(char *template)
+{
+ if (!mktemp(template) || mkdir(template, 0700))
+ return NULL;
+ return template;
+}
diff --git a/git-compat-util.h b/git-compat-util.h
index f23d934..474f1d1 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -147,6 +147,11 @@ extern ssize_t git_pread(int fd, void *buf, size_t count, off_t offset);
extern int gitsetenv(const char *, const char *, int);
#endif
+#ifdef NO_MKDTEMP
+#define mkdtemp gitmkdtemp
+extern char *gitmkdtemp(char *);
+#endif
+
#ifdef NO_UNSETENV
#define unsetenv gitunsetenv
extern void gitunsetenv(const char *);
--
1.5.3.4.1270.g2fe543
^ permalink raw reply related
* Re: [BUG] git-mv submodule failure
From: Yin Ping @ 2007-10-21 5:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710202223590.25221@racer.site>
>
> But of course .gitmodules is unaffected. But it should be changed, too.
>
IMHO, changing .gitmodules is what the 'git-submodule mv' should do,
and 'git-mv' should only rename the module directory
> Ciao,
> Dscho
>
>
--
franky
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Dmitry Potapov @ 2007-10-21 6:08 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Steffen Prohaska, Federico Mena Quintero, Johannes Schindelin,
Jakub Narebski, git
In-Reply-To: <4719E69B.3020906@op5.se>
On Sat, Oct 20, 2007 at 01:29:31PM +0200, Andreas Ericsson wrote:
> Steffen Prohaska wrote:
> >
> >plumbing: should be hidden from the 'normal' user. Porcelain
> > should be sufficient for every standard task.
> >
>
> Agreed. /usr/libexec/git/ seems to me to be the ideal spot for
> it.
/usr/libexec is against the Filesystem Hierarchy Standard (FHS).
It is better to use /usr/lib/git/ for that.
Dmitry
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Yin Ping @ 2007-10-21 6:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jeff King, Johannes Schindelin, Jari Aalto, git
In-Reply-To: <20071021032953.GC14735@spearce.org>
On 10/21/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Jeff King <peff@peff.net> wrote:
> > On Sat, Oct 20, 2007 at 10:06:53PM -0400, Shawn O. Pearce wrote:
> >
> > > I actually had to do `git config alias.upsh push` just to keep
> > > myself from screaming every time I made a small typo and Git gave
> > > me a screenful of "helpful reminders".
> >
> > Yeah, somebody should really work on bash completion...
>
> $ git pu<TAB><TAB>
> pull push
>
> By the time I type out "pus" and hit tab I've already typed out
> the name "push ". Except I frequently find myself getting the
> u before the p, which can't complete. Of course with the above
> alias in place "git u<TAB>" completes out uniquely to "git push "
> (between bash completion and the alias expansion).
>
> But that alias isn't there for my bash tab completion. Its there
> exactly because otherwise "git upsh" gives me 31 lines of useless
> (to me) output without it.
>
My way to resolve this is to define some alias begenning with 'gt' for
frequently used commands, such as 'gtps -> git-push, gtpl ->
git-pull, gtco->git-checkout, gtci->git-commit, gtbr->git-branch'.
so that when i type 'gt<TAB>', only commands that i frequently use are
listed.
--
franky
^ permalink raw reply
* How to run git-gui always in English?
From: Steffen Prohaska @ 2007-10-21 6:47 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
There are a lot of efforts going on to localize git-gui,
including technical terms like "push". Personally I don't
understand what this should be useful for. The command is called
"git push"s. So, why should it be named differently in the gui.
Anyway, I can switch it off, right? So here's my question.
How can I switch msysgit's git-gui to English, independently of
the language selected for Windows? I recognized that git-gui
adjusts to the 'language selection' of Windows. How can I
disable this? I want git-gui to always display English. Nothing
else, never! I can't help people who use a different language
in the gui, because I'll not understand what they are talking
about and they'll not understand me.
Can I set an option in git-gui's option menu? I haven't
found one.
Steffen
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Shawn O. Pearce @ 2007-10-21 6:52 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <CCAD0DE0-65D4-4FEC-B02F-658010FECD04@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> There are a lot of efforts going on to localize git-gui,
> including technical terms like "push". Personally I don't
> understand what this should be useful for. The command is called
> "git push"s. So, why should it be named differently in the gui.
>
> Anyway, I can switch it off, right? So here's my question.
>
> How can I switch msysgit's git-gui to English, independently of
> the language selected for Windows? I recognized that git-gui
> adjusts to the 'language selection' of Windows. How can I
> disable this? I want git-gui to always display English. Nothing
> else, never! I can't help people who use a different language
> in the gui, because I'll not understand what they are talking
> about and they'll not understand me.
>
> Can I set an option in git-gui's option menu? I haven't
> found one.
Yea, we don't have a UI to let you set what language the UI should
appear in. Partly because once the UI is up we'd have to restart
the entire process to change the strings its using. And partly
because nobody has asked for this before.
I think that if you set LANG=en before you start git-gui it will
take on English, and so will all of the standard dialogs that we
"borrow" from wish.
--
Shawn.
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Steffen Prohaska @ 2007-10-21 7:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <20071021065230.GE14735@spearce.org>
On Oct 21, 2007, at 8:52 AM, Shawn O. Pearce wrote:
> Steffen Prohaska <prohaska@zib.de> wrote:
>
>> How can I switch msysgit's git-gui to English, independently of
>> the language selected for Windows? I recognized that git-gui
>> adjusts to the 'language selection' of Windows. How can I
>> disable this? I want git-gui to always display English. Nothing
>> else, never! I can't help people who use a different language
>> in the gui, because I'll not understand what they are talking
>> about and they'll not understand me.
>>
>> Can I set an option in git-gui's option menu? I haven't
>> found one.
>>
>
> Yea, we don't have a UI to let you set what language the UI should
> appear in. Partly because once the UI is up we'd have to restart
> the entire process to change the strings its using. And partly
> because nobody has asked for this before.
>
> I think that if you set LANG=en before you start git-gui it will
> take on English, and so will all of the standard dialogs that we
> "borrow" from wish.
Hmm. I have no shell. I run git-gui from the Windows Start Menu.
It directly runs wish to execute the Windows git-gui wrapper:
--- SNIP ---
#!/bin/sh
# Tcl ignores the next line -*- tcl -*- \
exec wish "$0" -- "$@"
if { $argc >=2 && [lindex $argv 0] == "--working-dir" } {
cd [lindex $argv 1]
set argv [lrange $argv 2 end]
incr argc -2
}
set gitguidir [file dirname [info script]]
regsub -all ";" $gitguidir "\\;" gitguidir
set env(PATH) "$gitguidir;$env(PATH)"
unset gitguidir
source [file join [file dirname [info script]] git-gui.tcl]
--- SNIP ---
Do we have a chance before we source the real git-gui.tcl?
Maybe we could "set env(LANG)" based on "git config gui.lang"?
Or is it already too late because we needed to restart wish?
Steffen
^ permalink raw reply
* Re: How to run git-gui always in English?
From: Shawn O. Pearce @ 2007-10-21 7:15 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Git Mailing List
In-Reply-To: <C65193EE-A45D-49ED-8831-1A006421A915@zib.de>
Steffen Prohaska <prohaska@zib.de> wrote:
> On Oct 21, 2007, at 8:52 AM, Shawn O. Pearce wrote:
> >
> >I think that if you set LANG=en before you start git-gui it will
> >take on English, and so will all of the standard dialogs that we
> >"borrow" from wish.
>
> Do we have a chance before we source the real git-gui.tcl?
> Maybe we could "set env(LANG)" based on "git config gui.lang"?
> Or is it already too late because we needed to restart wish?
Hmm. Really quick testing here shows that we just need to make sure
env(LANG) is set before we do the msgcat::mcload call in git-gui.sh
line 104.
If we're going to use a `git config gui.lang` thing then we can
probably just make a msgcat::mclocale call on line 103 just before we
load our message file. Unfortunately this is before we have located
git so technically git-gui doesn't know how to run git-config and
thus cannot get to gui.lang. :-|
Hmm. Looking at this further we may be able to insert the mclocale
call at two locations; one at line 864 before we open the repository
wizard, and again at line 1802, just before we start to initialize
our UI. This does mean that for really serious errors (e.g. "No
git in PATH") we'll be using your native OS language.
--
Shawn.
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Andreas Ericsson @ 2007-10-21 7:17 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jakub Narebski, Steffen Prohaska, Federico Mena Quintero, git
In-Reply-To: <Pine.LNX.4.64.0710210031130.25221@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Sun, 21 Oct 2007, Jakub Narebski wrote:
>
>> On 10/20/07, Steffen Prohaska <prohaska@zib.de> wrote:
>>
>>> Maybe we could group commands into more categories?
>>>
>>> plumbing: should be hidden from the 'normal' user. Porcelain
>>> should be sufficient for every standard task.
>> The problem is division between what is porcelain and what is plumbing.
>> Some commands are right on border (git-fsck, git-update-index,
>> git-rev-parse comes to mind).
>
> Sorry, but my impression from the latest mails was that the commands are
> fine. What is lacking is a nice, _small_ collection of recommended
> workflows. And when we have agreed on such a set of workflows, we
> optimize the hell out of them. Only this time it is not performance, but
> user-friendliness.
>
http://www.kernel.org/pub/software/scm/git/docs/everyday.html would be a
good starting point, I think.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* .gittattributes handling has deficiencies
From: Steffen Prohaska @ 2007-10-21 8:48 UTC (permalink / raw)
Cc: git, Steffen Prohaska
If a .gitattributes is in the work tree and we checkout a
different head, the .gitattributes of the head we are switching
to must have precedence. Files are expected to be converted as
configured in the .gitattributes that is available in the head
we're switching to.
This adds a test case revealing deficiencies of the current
handling of .gitattributes.
At a first glance, I saw two possible resolutions:
1) .gitattributes from the index has precedence. It's unclear
how merging can be handled appropriately.
2) .gitattributes are handled as a special file. Checkout is a
two pass process. In the first pass only the special file
.gitattributes is checked out. In th second pass the remaining
files are added. Maybe this gives a perspective how to handle
merges.
But actually the issue is much harder to solve.
Here is what needs to be done: Whenever the attributes of a file
change the file must be freshly checked out according to the
attributes of the head we switch to. The file itself does not
necessarily change between the two commits. A fresh checkout is
already needed if only .gitattributes change.
But this is really hard to solve. We would need to compare
attributes before and after for _all_ files that have attributes
in one of the two commits and check if they changed. If so, we
need to do a fresh checkout according to the new attributes.
Maybe the gitattributes of a file should be part of the per-file
flags in the index. Thus we could verify if the flags changed and
if so, adjust the work tree accordig to the new flags. I'm
lacking a deeper insight into the git internals. Therefore, I
can't really say if the index is the right place. But it looks
to me as if changing an attribute should be treated similar to a
changing sha1, as far as the work tree is concerned.
So, I need some help.
Steffen
---
t/t0020-crlf.sh | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index 62bc4bb..5d7e033 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -371,6 +371,29 @@ test_expect_success 'in-tree .gitattributes (4)' '
}
'
+test_expect_success 'in-tree .gitattributes (5)' '
+
+ git reset --hard master &&
+ echo >.gitattributes &&
+ git add .gitattributes &&
+ git commit -m "empty .gitattributes" &&
+ rm -rf tmp one dir .gitattributes patch.file three &&
+ git reset --hard master &&
+ git checkout master^ &&
+
+ if remove_cr one >/dev/null
+ then
+ echo "Eh? one should not have CRLF"
+ false
+ else
+ : happy
+ fi &&
+ remove_cr three >/dev/null || {
+ echo "Eh? three should still have CRLF"
+ false
+ }
+'
+
test_expect_success 'invalid .gitattributes (must not crash)' '
echo "three +crlf" >>.gitattributes &&
--
1.5.3.mingw.1.138.g7bf9d
^ permalink raw reply related
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Wincent Colaiuta @ 2007-10-21 8:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Jari Aalto, git
In-Reply-To: <20071021020653.GA14735@spearce.org>
El 21/10/2007, a las 4:06, Shawn O. Pearce escribió:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>> On Sat, 20 Oct 2007, Jari Aalto wrote:
>>>>
>>>>> - commented out call to list_common_cmds_help()
>>
>> Well, I'm almost sure of the opposite. One of the big results of
>> the Git
>> Survey was that git is still not user-friendly enough. Your patch
>> would
>> only make this issue worse.
>
> Actually I think Jari's patch helps for the reason originally
> stated in the message (less output when you make a small typo).
> Though I agree that the commented out code should just be removed.
>
> I actually had to do `git config alias.upsh push` just to keep
> myself from screaming every time I made a small typo and Git gave
> me a screenful of "helpful reminders".
If you want to go really user friendly, how about a check against the
list of known commands using a shortest-edit distance algorithm?
Unknown command: 'upsh': did you mean 'push'?
Type 'git help' for usage.
Here's just one of many articles introducing the shortest-edit idea,
as popularized by Google:
<http://norvig.com/spell-correct.html>
What do you think?
Cheers,
Wincent
^ permalink raw reply
* Re: Announcement of Git wikibook
From: Wincent Colaiuta @ 2007-10-21 9:10 UTC (permalink / raw)
To: Steven Walter
Cc: Johannes Schindelin, Ciprian Dorin Craciun, Steffen Prohaska,
Evan Carroll, git
In-Reply-To: <20071021030927.GA19450@dervierte>
El 21/10/2007, a las 5:09, Steven Walter escribió:
> On Sat, Oct 20, 2007 at 10:34:34PM +0100, Johannes Schindelin wrote:
>> I am torn. On one side I like the Wiki approach. On the other
>> hand, the
>> Wiki will get less review by git oldtimers, whereas the patches to
>> user-manual are usually reviewed as thoroughly as the code patches.
>
> No offense, but review by old timers can be both a blessing and a
> curse.
> Well, it's not the "review" that is so much a problem as the
> "editorial
> control." In my opinion (and I believe this is what the original
> poster
> was saying), the official Git User Manual focuses more on technical
> issues and less on introducing git to a new user.
But it's not an "intro", it's a user manual. That means it's supposed
to be a comprehensive, in-depth treatment of just about everything.
The technical content is a good thing; it's supposed to be the
document you turn to when you want to move beyond superficial use to
genuine, in-depth understanding.
There are other documents with the goal of "introducing git to the
new user", grouped together here:
<http://git.or.cz/course/index.html>
And also under the "Documentation" heading on the Git home page:
<http://git.or.cz/>
Those are probably the articles that should be worked on and
augmented if you care about introducing things to a newbie.
Cheers,
Wincent
^ permalink raw reply
* Re: .gittattributes handling has deficiencies
From: david @ 2007-10-21 9:19 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <1192956535617-git-send-email-prohaska@zib.de>
On Sun, 21 Oct 2007, Steffen Prohaska wrote:
> If a .gitattributes is in the work tree and we checkout a
> different head, the .gitattributes of the head we are switching
> to must have precedence. Files are expected to be converted as
> configured in the .gitattributes that is available in the head
> we're switching to.
>
> This adds a test case revealing deficiencies of the current
> handling of .gitattributes.
>
> At a first glance, I saw two possible resolutions:
> 1) .gitattributes from the index has precedence. It's unclear
> how merging can be handled appropriately.
> 2) .gitattributes are handled as a special file. Checkout is a
> two pass process. In the first pass only the special file
> .gitattributes is checked out. In th second pass the remaining
> files are added. Maybe this gives a perspective how to handle
> merges.
>
> But actually the issue is much harder to solve.
>
> Here is what needs to be done: Whenever the attributes of a file
> change the file must be freshly checked out according to the
> attributes of the head we switch to.
this is the same problem that we would have with the extended file
attributes, in the discussion for those it was suggested that I refrence
the file from the index rather then from the file system to avoid needing
to do two passes.
> The file itself does not
> necessarily change between the two commits. A fresh checkout is
> already needed if only .gitattributes change.
>
> But this is really hard to solve. We would need to compare
> attributes before and after for _all_ files that have attributes
> in one of the two commits and check if they changed. If so, we
> need to do a fresh checkout according to the new attributes.
if you know that you will get the new .gitattributes if it changes, setup
a post-checkout hook to checkout everything if it has changed. it's far
from ideal, but it should be a good, safe, first approximation.
you shouldn't need to check all files of all attributes, only on any that
match the lines that get changed. the hook for this is exactly the type of
thing that I was talking about in the metastore thread.
> Maybe the gitattributes of a file should be part of the per-file
> flags in the index. Thus we could verify if the flags changed and
> if so, adjust the work tree accordig to the new flags. I'm
> lacking a deeper insight into the git internals. Therefore, I
> can't really say if the index is the right place. But it looks
> to me as if changing an attribute should be treated similar to a
> changing sha1, as far as the work tree is concerned.
the problem with this is that each attribute ends up needing it's own
flag, which severely limits extending things (see the discussions on file
permissions for examples). it's also much harder to manipulate them then
in a file.
David Lang
> So, I need some help.
> Steffen
>
> ---
> t/t0020-crlf.sh | 23 +++++++++++++++++++++++
> 1 files changed, 23 insertions(+), 0 deletions(-)
>
> diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
> index 62bc4bb..5d7e033 100755
> --- a/t/t0020-crlf.sh
> +++ b/t/t0020-crlf.sh
> @@ -371,6 +371,29 @@ test_expect_success 'in-tree .gitattributes (4)' '
> }
> '
>
> +test_expect_success 'in-tree .gitattributes (5)' '
> +
> + git reset --hard master &&
> + echo >.gitattributes &&
> + git add .gitattributes &&
> + git commit -m "empty .gitattributes" &&
> + rm -rf tmp one dir .gitattributes patch.file three &&
> + git reset --hard master &&
> + git checkout master^ &&
> +
> + if remove_cr one >/dev/null
> + then
> + echo "Eh? one should not have CRLF"
> + false
> + else
> + : happy
> + fi &&
> + remove_cr three >/dev/null || {
> + echo "Eh? three should still have CRLF"
> + false
> + }
> +'
> +
> test_expect_success 'invalid .gitattributes (must not crash)' '
>
> echo "three +crlf" >>.gitattributes &&
>
^ permalink raw reply
* Re: [PATCH 2/2] Correct some sizeof(size_t) != sizeof(unsigned long) typing errors
From: René Scharfe @ 2007-10-21 9:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071021052537.GB31927@spearce.org>
Fix size_t vs. unsigned long pointer mismatch warnings introduced
with the addition of strbuf_detach().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Shawn O. Pearce schrieb:
> On at least one system I've used recently sizeof(size_t) == 4
> and sizeof(unsigned long) == 8. Trying to pass a pointer to an 8
> byte value into strbuf_detach() causes problems as the function is
> expecting an address for a 4 byte result location. Writing only 4
> bytes here will leave the other 4 bytes unitialized and may cause
> problems when the caller evalutes the result.
>
> I am introducing strbuf_detach_ul() as a variant that takes its
> size as an unsigned long rather than as a size_t. This approach is
> shorter than fixing all of the callers to use their own temporary
> size_t value for the call.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> builtin-apply.c | 2 +-
> builtin-archive.c | 2 +-
> diff.c | 4 ++--
> entry.c | 2 +-
> strbuf.h | 8 +++++++-
> test-delta.c | 3 ++-
> 6 files changed, 14 insertions(+), 7 deletions(-)
I have a feeling this is going in then wrong direction. Shouldn't
we rather use size_t everywhere? malloc() takes a size_t, and it's
the basis of strbuf and also of the file content functions.
The following patch is shorter, though it adds one more line than
your's. The result is slightly uglier, but it's a good reminder to
use size_t in more places.
That said, I realize that converting read_sha1_file() et al. would
be quite painful. Maybe too painful?
builtin-apply.c | 2 +-
builtin-archive.c | 4 +++-
diff.c | 8 ++++++--
entry.c | 4 +++-
4 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 047a60d..541a6f4 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -152,7 +152,7 @@ struct patch {
unsigned int is_rename:1;
struct fragment *fragments;
char *result;
- unsigned long resultsize;
+ size_t resultsize;
char old_sha1_prefix[41];
char new_sha1_prefix[41];
struct patch *next;
diff --git a/builtin-archive.c b/builtin-archive.c
index 04385de..6f29c2f 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -148,12 +148,14 @@ void *sha1_file_to_archive(const char *path, const unsigned char *sha1,
buffer = read_sha1_file(sha1, type, sizep);
if (buffer && S_ISREG(mode)) {
struct strbuf buf;
+ size_t size = 0;
strbuf_init(&buf, 0);
strbuf_attach(&buf, buffer, *sizep, *sizep + 1);
convert_to_working_tree(path, buf.buf, buf.len, &buf);
convert_to_archive(path, buf.buf, buf.len, &buf, commit);
- buffer = strbuf_detach(&buf, sizep);
+ buffer = strbuf_detach(&buf, &size);
+ *sizep = size;
}
return buffer;
diff --git a/diff.c b/diff.c
index 0bd7e24..df82ed6 100644
--- a/diff.c
+++ b/diff.c
@@ -1512,6 +1512,7 @@ static int reuse_worktree_file(const char *name, const unsigned char *sha1, int
static int populate_from_stdin(struct diff_filespec *s)
{
struct strbuf buf;
+ size_t size = 0;
strbuf_init(&buf, 0);
if (strbuf_read(&buf, 0, 0) < 0)
@@ -1519,7 +1520,8 @@ static int populate_from_stdin(struct diff_filespec *s)
strerror(errno));
s->should_munmap = 0;
- s->data = strbuf_detach(&buf, &s->size);
+ s->data = strbuf_detach(&buf, &size);
+ s->size = size;
s->should_free = 1;
return 0;
}
@@ -1609,9 +1611,11 @@ int diff_populate_filespec(struct diff_filespec *s, int size_only)
*/
strbuf_init(&buf, 0);
if (convert_to_git(s->path, s->data, s->size, &buf)) {
+ size_t size = 0;
munmap(s->data, s->size);
s->should_munmap = 0;
- s->data = strbuf_detach(&buf, &s->size);
+ s->data = strbuf_detach(&buf, &size);
+ s->size = size;
s->should_free = 1;
}
}
diff --git a/entry.c b/entry.c
index 98f5f6d..cfadc6a 100644
--- a/entry.c
+++ b/entry.c
@@ -119,8 +119,10 @@ static int write_entry(struct cache_entry *ce, char *path, const struct checkout
*/
strbuf_init(&buf, 0);
if (convert_to_working_tree(ce->name, new, size, &buf)) {
+ size_t newsize = 0;
free(new);
- new = strbuf_detach(&buf, &size);
+ new = strbuf_detach(&buf, &newsize);
+ size = newsize;
}
if (to_tempfile) {
^ permalink raw reply related
* Re: [PATCH] git-cherry-pick: improve description of -x.
From: Ralf Wildenhues @ 2007-10-21 9:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Frank Lichtenheld, git
In-Reply-To: <20071020031917.GR14735@spearce.org>
Reword the first sentence of the description of -x, in order to
make it easier to read and understand.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
---
* Shawn O. Pearce wrote on Sat, Oct 20, 2007 at 05:19:17AM CEST:
> Frank Lichtenheld <frank@lichtenheld.de> wrote:
> > On Fri, Oct 19, 2007 at 07:41:34PM +0200, Ralf Wildenhues wrote:
> > >
> > > Is that by design (because there were conflicts) or an omission?
> > > In case of the former, maybe the description of -x should mention this.
> >
> > git commit currently doesn't know that you commit a cherry-pick. The -c
> > only says to use the commit message of the original commit. So this is
> > currently by design.
>
> Ralf, can you submit an updated version of this patch that describes
> the current behavior better, given the "by design" remark above
> from Frank?
Here it goes. Still makes me wonder whether that is the ideal mode of
operation or not.
FWIW, I think the previous passive voice wording was correct English,
but here's a rewrite using mostly active voice (sound nicer anyway).
Cheers,
Ralf
Documentation/git-cherry-pick.txt | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt b/Documentation/git-cherry-pick.txt
index 47b1e8c..76a2edf 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -27,11 +27,12 @@ OPTIONS
message prior committing.
-x::
- Cause the command to append which commit was
- cherry-picked after the original commit message when
- making a commit. Do not use this option if you are
- cherry-picking from your private branch because the
- information is useless to the recipient. If on the
+ When recording the commit, append to the original commit
+ message a note that indicates which commit this change
+ was cherry-picked from. Append the note only for cherry
+ picks without conflicts. Do not use this option if
+ you are cherry-picking from your private branch because
+ the information is useless to the recipient. If on the
other hand you are cherry-picking between two publicly
visible branches (e.g. backporting a fix to a
maintenance branch for an older release from a
--
1.5.3.1.153.g89df5
^ permalink raw reply related
* Re: [BUG] git-mv submodule failure
From: Johannes Schindelin @ 2007-10-21 10:02 UTC (permalink / raw)
To: Yin Ping; +Cc: git
In-Reply-To: <46dff0320710202248v56af5cb0gcf7dacb32848eca3@mail.gmail.com>
Hi,
On Sun, 21 Oct 2007, Yin Ping wrote:
> > But of course .gitmodules is unaffected. But it should be changed, too.
>
> IMHO, changing .gitmodules is what the 'git-submodule mv' should do, and
> 'git-mv' should only rename the module directory
No. If you "git mv" a submodule, it makes absolutely no sense to leave
.gitmodules as is.
Ciao,
Dscho
^ permalink raw reply
* Re: Announcement of Git wikibook
From: Steffen Prohaska @ 2007-10-21 10:06 UTC (permalink / raw)
To: Wincent Colaiuta
Cc: Steven Walter, Johannes Schindelin, Ciprian Dorin Craciun,
Evan Carroll, git
In-Reply-To: <F430333B-B29B-4992-9474-0E87006CBA77@wincent.com>
On Oct 21, 2007, at 11:10 AM, Wincent Colaiuta wrote:
> El 21/10/2007, a las 5:09, Steven Walter escribió:
>
>> On Sat, Oct 20, 2007 at 10:34:34PM +0100, Johannes Schindelin wrote:
>>> I am torn. On one side I like the Wiki approach. On the other
>>> hand, the
>>> Wiki will get less review by git oldtimers, whereas the patches to
>>> user-manual are usually reviewed as thoroughly as the code patches.
>>
>> No offense, but review by old timers can be both a blessing and a
>> curse.
>> Well, it's not the "review" that is so much a problem as the
>> "editorial
>> control." In my opinion (and I believe this is what the original
>> poster
>> was saying), the official Git User Manual focuses more on technical
>> issues and less on introducing git to a new user.
>
> But it's not an "intro", it's a user manual. That means it's
> supposed to be a comprehensive, in-depth treatment of just about
> everything. The technical content is a good thing; it's supposed to
> be the document you turn to when you want to move beyond
> superficial use to genuine, in-depth understanding.
But it could also have introductory parts and parts decribing
specific workflows.
Something similar to svnbook or cvsbook would be perfect. I
believe a reasonable goal is that you'll get all need if you
search gitbook with google.
Steffen
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option
From: Jan Hudec @ 2007-10-21 10:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jari Aalto, git
In-Reply-To: <20071021033318.GD14735@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 564 bytes --]
On Sat, Oct 20, 2007 at 23:33:18 -0400, Shawn O. Pearce wrote:
> Jari Aalto <jari.aalto@cante.net> wrote:
> > - Remove out call to list_common_cmds_help()
>
> Even if the list is against this change (which I'm in favor of)...
I didn't get the impression that the _whole_ list is against. I think that
the rather longish list should only be shown for 'git help' and when no
command was specified (but that is handled by implying help, so this change
does not apply to that case), so I am in favor of this.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: .gittattributes handling has deficiencies
From: Steffen Prohaska @ 2007-10-21 10:27 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710210204580.4818@asgard>
On Oct 21, 2007, at 11:19 AM, david@lang.hm wrote:
>> But this is really hard to solve. We would need to compare
>> attributes before and after for _all_ files that have attributes
>> in one of the two commits and check if they changed. If so, we
>> need to do a fresh checkout according to the new attributes.
>
> if you know that you will get the new .gitattributes if it changes,
> setup a post-checkout hook to checkout everything if it has
> changed. it's far from ideal, but it should be a good, safe, first
> approximation.
That's not good enough. I'll stop using .gitattributes. I
need to teach >40 devs how to use git on Windows. I only use
features that work flawlessly. .gitattributes doesn't. It bit
me twice now.
Luckily, core.autocrlf works if you set it before the first
checkout and never change it. This seems sufficient for me if
all files that have mixed line endings are fixed right away.
Steffen
^ permalink raw reply
* Re: [PATCH 2/2] Correct some sizeof(size_t) != sizeof(unsigned long) typing errors
From: Pierre Habouzit @ 2007-10-21 10:31 UTC (permalink / raw)
To: René Scharfe; +Cc: Shawn O. Pearce, git
In-Reply-To: <471B1AA5.8070009@lsrfire.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 958 bytes --]
On Sun, Oct 21, 2007 at 09:23:49AM +0000, René Scharfe wrote:
> > Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> > ---
> > builtin-apply.c | 2 +-
> > builtin-archive.c | 2 +-
> > diff.c | 4 ++--
> > entry.c | 2 +-
> > strbuf.h | 8 +++++++-
> > test-delta.c | 3 ++-
> > 6 files changed, 14 insertions(+), 7 deletions(-)
>
> I have a feeling this is going in then wrong direction. Shouldn't
> we rather use size_t everywhere? malloc() takes a size_t, and it's
> the basis of strbuf and also of the file content functions.
I agree, Junio was working on a patch that generalized use of size_t's
when unsigned long where used and size_t meant, I suppose he didn't had
the time to push it.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH-resent] gitk: fix in procedure drawcommits
From: Rocco Rutte @ 2007-10-21 12:12 UTC (permalink / raw)
To: Michele Ballabio; +Cc: Paul Mackerras, git, Shawn O. Pearce
In-Reply-To: <200710201802.48111.barra_cuda@katamail.com>
[ No need to Cc: me as I'm on the git list, too ]
Hi,
* Michele Ballabio [07-10-20 18:02:47 +0200] wrote:
>Uh-oh. I think I just found the issue. That's probably a bug
>somewhere in the import (either fast-export or fast-import or
>the original repo, I don't know), so I'm not sure if gitk
>should be patched, but since the resulting repo seems correct
>as far as git is concerned (i.e. git fsck --full --strict
>doesn't complain), I guess something should be done.
>Here is the culprit (or so I think). One of the guilty commits is:
> commit a3b4383d69e0754346578c85ba8ff7c05bd88705
> tree 1bf99cd22abe97c59f8c0b7ad6b8244f0854b8af
> parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> parent 6d919fccf603aba995035fa0fb507aa2bd3bf0ae
> author Brendan Cully <brendan@kublai.com> 1179646159 -0700
> committer Brendan Cully <brendan@kublai.com> 1179646159 -0700
> Forget SMTP password if authentication fails.
> Thanks to Gregory Shapiro for the initial patch (I've moved the reset
> from smtp_auth_sasl up to smtp_auth, and used the account API
> instead of twiddling account bits by hand). Closes #2872.
Oh. Yes, this is a bug in the python scripts that get merges quite
wrong. I didn't notice that earlier as git doesn't complain and the
contents of the repo turns out as identical.
I'll push fixes (e.g. packed refs support) to the fast-export repo in
Monday. With these changes, the mutt repo as well hg-crew (which has far
more merges than the mutt repo) seem to work correctly (no identical
parents and identical contents).
Thanks for tracking it down.
Still I think fast-import could warn or error out if its gets such
content which doesn't really make sense...
Rocco
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Andreas Ericsson @ 2007-10-21 12:42 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Shawn O. Pearce, Johannes Schindelin, Jari Aalto, git
In-Reply-To: <ED3FFB7A-861F-47E4-97EA-D7A05552FC2C@wincent.com>
Wincent Colaiuta wrote:
> El 21/10/2007, a las 4:06, Shawn O. Pearce escribió:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>>> On Sat, 20 Oct 2007, Jari Aalto wrote:
>>>>>
>>>>>> - commented out call to list_common_cmds_help()
>>>
>>> Well, I'm almost sure of the opposite. One of the big results of the
>>> Git
>>> Survey was that git is still not user-friendly enough. Your patch would
>>> only make this issue worse.
>>
>> Actually I think Jari's patch helps for the reason originally
>> stated in the message (less output when you make a small typo).
>> Though I agree that the commented out code should just be removed.
>>
>> I actually had to do `git config alias.upsh push` just to keep
>> myself from screaming every time I made a small typo and Git gave
>> me a screenful of "helpful reminders".
>
> If you want to go really user friendly, how about a check against the
> list of known commands using a shortest-edit distance algorithm?
>
http://en.wikipedia.org/wiki/Levenshtein_distance
Implementing the algorithm doesn't seem terribly difficult.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* gitk still interested in translations?
From: Christian Stimming @ 2007-10-21 12:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Junio C Hamano
In-Reply-To: <18090.44123.905869.974967@cargo.ozlabs.ibm.com>
Hi Paul,
in July I submitted patches to add the necessary framework for UI
translations/i18n to the gitk tool [1] [2], and I'd also volunteer to provide
a full German translation. As you pointed out [3], this would require some
decisions on integration and installation places, which according to Junios
reply [4] didn't seem too difficult.
What is the progress on your i18n plans in gitk? None of the patches had been
applied to gitk, have they? If you say you *are* interested, I'd be happy to
provide an up-to-date patch against gitk.git @ kernel.org for #1 Makefile
rules, #2 msgcat integration, and most importantly #3 message markup.
Christian
[1] http://marc.info/?l=git&m=118554802809395&w=2
[2] http://marc.info/?l=git&m=118554865029767&w=2
[3] http://marc.info/?l=git&m=118559040716553&w=2
[4] http://marc.info/?l=git&m=118559853016496&w=2
Am Samstag, 28. Juli 2007 04:39 schrieb Paul Mackerras:
> Christian Stimming writes:
> > Similar to the discussion in git-gui, all user-visible strings are
> > passed through the [mc ...] procedure to have them translated by msgcat.
> >
> > Signed-off-by: Christian Stimming <stimming@tuhh.de>
> > ---
> > @Paul: Are you interested in applying this? If yes, I'd happily
>
> Yes, it doesn't look too bad. The patch seemed to be line-wrapped and
> whitespace-damaged, though.
>
> > provide the Makefile rules for string extraction and translation
> > catalog updates, but I'd like to hear a proposal or decision on where
> > to place them. Should the po files for translation go into the po/
> > subdirectory? And then a proposal/decision of where to install the
> > compiled .msg catalogs will be necessary.
>
> Yes indeed. Junio?
>
> Is it possible to include the translations, or at least the more
> common translations, in the Tcl code itself? So far I have managed to
> have gitk be self-contained, in that it doesn't need any external data
> files, which simplifies installation and is a useful attribute in some
> situations.
>
> Also I would want to be sure that gitk wouldn't crash or fail to
> function if it can't find its message catalogs.
>
> Paul.
^ permalink raw reply
* Re: [PATCH] On error, do not list all commands, but point to --help option.
From: Jan Hudec @ 2007-10-21 13:13 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Wincent Colaiuta, Shawn O. Pearce, Johannes Schindelin,
Jari Aalto, git
In-Reply-To: <471B4931.5040102@op5.se>
[-- Attachment #1: Type: text/plain, Size: 1771 bytes --]
On Sun, Oct 21, 2007 at 14:42:25 +0200, Andreas Ericsson wrote:
> Wincent Colaiuta wrote:
>> El 21/10/2007, a las 4:06, Shawn O. Pearce escribió:
>>> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>>>> On Sat, 20 Oct 2007, Jari Aalto wrote:
>>>>>>
>>>>>>> - commented out call to list_common_cmds_help()
>>>>
>>>> Well, I'm almost sure of the opposite. One of the big results of the
>>>> Git
>>>> Survey was that git is still not user-friendly enough. Your patch would
>>>> only make this issue worse.
>>>
>>> Actually I think Jari's patch helps for the reason originally
>>> stated in the message (less output when you make a small typo).
>>> Though I agree that the commented out code should just be removed.
>>>
>>> I actually had to do `git config alias.upsh push` just to keep
>>> myself from screaming every time I made a small typo and Git gave
>>> me a screenful of "helpful reminders".
>> If you want to go really user friendly, how about a check against the list
>> of known commands using a shortest-edit distance algorithm?
>
> http://en.wikipedia.org/wiki/Levenshtein_distance
>
> Implementing the algorithm doesn't seem terribly difficult.
That's not the correct algorithm (you need to consider transpozitions, so you
need at least http://en.wikipedia.org/wiki/Damerau-Levenshtein_distance, but
I would not think that's the easier, or faster, way to do it. Though this
would have to be benchmarked -- calculating the edit distance is quadratic,
while generating the list of possibilities (and seeing whether they exist) is
linear, but with large constant. So the question is, whether we have few
enough commands that the quadratic calculation might be faster.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ 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