On Sat, Jan 26, 2013 at 10:32 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
This is a repost from here:
http://thread.gmane.org/gmane.comp.version-control.git/211176
which got no response initially. Basically the issue is that read-only
repos (e.g., a CI
On Fri, Jan 6, 2012 at 11:17 AM, Jeff King p...@peff.net wrote:
When we advertise a ref, the first thing we do is parse the
pointed-to object. This gives us two things:
...
The downside is that we are no longer verifying objects that
we advertise by fully parsing them (however, we do still
On Tue, Jan 29, 2013 at 04:54:13PM +1100, Michael Tyson wrote:
I've a readonly git repository that I'm hosting via HTTP (a bare git
repository located within the appropriate directory on the server). I
push to it via my own SSH account (local repository with a remote
pointing to the ssh://
On Sat, Jan 26, 2013 at 10:32:42PM -0800, Junio C Hamano wrote:
Both makes sense to me.
I also wonder if we would be helped by another repack mode that
coalesces small packs into a single one with minimum overhead, and
run that often from gc --auto, so that we do not end up having to
have
[resending as plain text]
If a p4 client is configured to /p/foo which is a symlink
to /vol/bar/projects/foo, then resolving symlink, which
is done by git-p4's chdir will confuse p4: Path
/vol/bar/projects/foo/... is not under client root /p/foo
While AltRoots in p4 client specification can be
This is the cleaned-up version of the commit caching patches I mentioned
here:
http://article.gmane.org/gmane.comp.version-control.git/212329
The basic idea is to generate a cache file that sits alongside a
packfile and contains the timestamp, tree, and parents in a more compact
and
We do not modify the buffer we are asked to write; mark it
with const so that callers with const buffers do not get
unnecessary complaints from the compiler.
Signed-off-by: Jeff King p...@peff.net
---
csum-file.c | 6 +++---
csum-file.h | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
Sometimes it is handy to cut a trailing string off the end
of a strbuf (e.g., a file extension). These helper functions
make it a one-liner.
Signed-off-by: Jeff King p...@peff.net
---
strbuf.c | 11 +++
strbuf.h | 2 ++
2 files changed, 13 insertions(+)
diff --git a/strbuf.c b/strbuf.c
The on-disk packfile format is nicely compact, but it does
not always provide the fastest format for looking up
information. This patch introduces the concept of
metapacks, optional metadata files which can live
alongside packs and represent their data in different ways.
This can allow space-time
When we are doing a commit traversal that does not need to
look at the commit messages themselves (e.g., rev-list,
merge-base, etc), we spend a lot of time accessing,
decompressing, and parsing the commit objects just to find
the parent and timestamp information. We can make a
space-time tradeoff
This is a plumbing command for generating metapack files.
Right now it understands only the commits metapack (and
there is not yet a reader). Eventually we may want to build
this metapack automatically when we generate a new pack.
Let's be conservative for now, though, and let the idea
prove
Now that we have the plumbing in place to generate and read
commit metapacks, we can hook them up to parse_commit to
fill in the traversal information much more quickly.
We only do so if save_commit_buffer is turned off;
otherwise, the callers will expect to be able to read
commit-buffer after
On 01/29/2013 10:15 AM, Jeff King wrote:
Sometimes it is handy to cut a trailing string off the end
of a strbuf (e.g., a file extension). These helper functions
make it a one-liner.
Signed-off-by: Jeff King p...@peff.net
---
strbuf.c | 11 +++
strbuf.h | 2 ++
2 files changed,
On 01/29/2013 10:16 AM, Jeff King wrote:
When we are doing a commit traversal that does not need to
look at the commit messages themselves (e.g., rev-list,
merge-base, etc), we spend a lot of time accessing,
decompressing, and parsing the commit objects just to find
the parent and timestamp
marc.theaimsgroup.com does not exist anymore, so replace it
with a link to the archive on GMane.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
README |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/README b/README
index 49713ea..3aae16a 100644
--- a/README
8f26aa4 (Makefile: remove tracking of TCLTK_PATH, 2012-12-18) removed
/gitk-git/gitk-wish from the toplevel .gitignore, with the intent of
moving it to gitk-git/.gitignore in a later patch. This was never
realized.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
Minor patch, so I
On Sun, Jan 27, 2013 at 1:32 PM, Junio C Hamano gits...@pobox.com wrote:
I also wonder if we would be helped by another repack mode that
coalesces small packs into a single one with minimum overhead, and
run that often from gc --auto, so that we do not end up having to
have 50 packfiles.
On Tue, Jan 29, 2013 at 11:15:34AM +0100, Michael Haggerty wrote:
+void strbuf_chompmem(struct strbuf *sb, const void *data, size_t len)
+{
+ if (sb-len = len !memcmp(data, sb-buf + sb-len - len, len))
+ strbuf_setlen(sb, sb-len - len);
+}
+
+void strbuf_chompstr(struct
On Tue, Jan 29, 2013 at 11:24:45AM +0100, Michael Haggerty wrote:
On 01/29/2013 10:16 AM, Jeff King wrote:
When we are doing a commit traversal that does not need to
look at the commit messages themselves (e.g., rev-list,
merge-base, etc), we spend a lot of time accessing,
decompressing,
John Keeping wrote:
On Mon, Jan 28, 2013 at 01:50:19PM -0800, Junio C Hamano wrote:
What are the situations where a valid user-defined tools is
unavailable, by the way?
The same as a built-in tool: the command isn't available.
Currently I'm extracting the command word using:
cmd=$(eval
On Tue, Jan 29, 2013 at 12:56:58PM +0100, Joachim Schmitz wrote:
John Keeping wrote:
Currently I'm extracting the command word using:
cmd=$(eval -- set -- $(git config mergetool.$tool.cmd); echo
\$1\)
Shouldnt this work?
cmd=$((git config mergetool.$tool.cmd || git config
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Seems like a good thing to do.
t/t7512-status-help.sh | 36 +++
wt-status.c| 58 ++
wt-status.h| 1 +
3 files changed, 68
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
In the spirit of status' in-progress info. I think showing this is
more useful than (no branch). I tend to do git br more often than
git st and this catches my eyes.
builtin/branch.c| 10 +-
I like the idea.
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index b3f6eb9..096ba6f 100755
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before
Duy Nguyen pclo...@gmail.com writes:
On Tue, Jan 29, 2013 at 7:31 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
I like the idea.
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
diff --git a/t/t7512-status-help.sh b/t/t7512-status-help.sh
index b3f6eb9..096ba6f 100755
---
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
- fix bisecting on detached HEAD
- show onto sha-1 for rebase
t/t7512-status-help.sh | 36 ++--
wt-status.c| 91 ++
wt-status.h| 2 ++
3 files
Hi Jed, all,
On 28.01.2013, at 06:19, Jed Brown wrote:
I'm working on an hg remote helper that uses git notes for the sha1
revision, so that git users can more easily refer to specific commits
when communicating with hg users.
For the record, I am also working on that very same thing; it is
Jeff King p...@peff.net wrote:
On Sat, Jan 26, 2013 at 10:32:42PM -0800, Junio C Hamano wrote:
Both makes sense to me.
I also wonder if we would be helped by another repack mode that
coalesces small packs into a single one with minimum overhead, and
run that often from gc --auto, so that
On Sun, Jan 27, 2013 at 9:37 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
A while ago, I submitted an RFC for adding a new email notification
script to contrib [1]. The reaction seemed favorable and it was
suggested that the new script should replace post-receive-email rather
than be
Jeff King p...@peff.net writes:
I also wonder if we would be helped by another repack mode that
coalesces small packs into a single one with minimum overhead, and
run that often from gc --auto, so that we do not end up having to
have 50 packfiles.
...
I'm not sure. If I understand you
Matthieu Moy matthieu@grenoble-inp.fr writes:
Not HEAD, but .git/rebase-merge/onto, i.e. the target of the rebase.
Ideally, I would have loved to see rebasing master on origin/master,
but I do not think the target ref name is stored during rebase.
Perhaps do it with --format=%s then. It
Duy Nguyen pclo...@gmail.com writes:
On Tue, Jan 29, 2013 at 11:35 AM, Duy Nguyen pclo...@gmail.com wrote:
:(glob) magic
=
This magic is for people who want globbing. However, it does _not_ use
the same matching mechanism the non-magic pathspec does today. It uses
Junio C Hamano gits...@pobox.com writes:
Duy Nguyen pclo...@gmail.com writes:
On Tue, Jan 29, 2013 at 11:35 AM, Duy Nguyen pclo...@gmail.com wrote:
:(glob) magic
=
This magic is for people who want globbing. However, it does _not_ use
the same matching mechanism the non-magic
Ramkumar Ramachandra artag...@gmail.com writes:
marc.theaimsgroup.com does not exist anymore, so replace it
with a link to the archive on GMane.
I think it has been at http://marc.info/?l=git for some time.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
On Tue, Jan 29, 2013 at 08:15:15AM -0800, Junio C Hamano wrote:
With any backend that is non-trivial, it would not be unusual for
the *tool.cmd to look like:
[mergetool]
mytool = sh -c '
... some massaging to prepare the command line
... to run the
Jeff King p...@peff.net writes:
+static void write_meta_header(struct metapack_writer *mw, const char *id,
+ uint32_t version)
+{
+ version = htonl(version);
+
+ sha1write(mw-out, META, 4);
+ sha1write(mw-out, \0\0\0\1, 4);
+ sha1write(mw-out,
Jeff King p...@peff.net writes:
+int commit_metapack(unsigned char *sha1,
+ uint32_t *timestamp,
+ unsigned char **tree,
+ unsigned char **parent1,
+ unsigned char **parent2)
+{
+ struct commit_metapack *p;
+
+
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
marc.theaimsgroup.com does not exist anymore, so replace it
with a link to the archive on GMane.
I think it has been at http://marc.info/?l=git for some time.
Isn't GMane what all of us refer to on the list though?
--
To
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
marc.theaimsgroup.com does not exist anymore, so replace it
with a link to the archive on GMane.
I think it has been at http://marc.info/?l=git for some time.
Isn't GMane
Jonathan Nieder jrnie...@gmail.com writes:
Odd. https://www.gravatar.com/; also seems to work. I've put in a
technical support query to find out what the Gravatar admins prefer.
Thanks; will hold onto Andrej's patch until we hear what the story
is.
Of course we could do something like this
Hi Duy,
Nguyễn Thái Ngọc Duy wrote:
--- a/t/t7512-status-help.sh
+++ b/t/t7512-status-help.sh
@@ -76,7 +76,7 @@ test_expect_success 'status when rebase in progress before
resolving conflicts'
test_must_fail git rebase HEAD^ --onto HEAD^^
cat expected -\EOF
# Not
How about doing this instead, to update all outdated or incorrect
information in that file? In addition to the marc.info update,
- refer to gmane;
- git-scm.org gives a CNAME with less commercial feeling to the
same thing;
- A note from the maintainer is not usually followed by useful
Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
In the spirit of status' in-progress info. I think showing this is
more useful than (no branch). I tend to do git br more often than
git st and this catches my eyes.
Very nice idea. This would also
From: Michal Nazarewicz min...@mina86.com
Make git-send-email read password from a ~/.authinfo file instead of
requiring it to be stored in git configuration, passed as command line
argument or typed in.
There are various other applications that use this file for
authentication information so
These are kept short by simply deferring to PEP-8. Most of the Python
code in Git is already very close to this style (some things in contrib/
are not).
Rationale for version suggestions:
- Amongst the noise in [1], there isn't any disagreement about using
2.6 as a base (see also [2]),
On Sun, Jan 27, 2013 at 04:52:23PM -0800, David Aguilar wrote:
Update variable assignments to always use $(command $arg)
in their RHS instead of $(command $arg) as the latter
is harder to read. Make get_merge_tool_cmd() simpler by
avoiding echo and $(command) substitutions completely.
Junio C Hamano wrote:
- refer to gmane;
GMane has a wonderful interface, and deserves to be advertised.
- git-scm.org gives a CNAME with less commercial feeling to the
same thing;
Nice touch.
- A note from the maintainer is not usually followed by useful
discussion to discuss
John Keeping j...@keeping.me.uk writes:
Changes since v1:
- Set 3.1 as the minimum Python 3 version
- Remove the section on Unicode literals - it just adds confusion and
doesn't apply to the current code; we can deal with any issues if they
ever arise.
...
+ - We use the 'b' prefix
For a cloned BOINC git tree :
$ git clone git://boinc.berkeley.edu/boinc.git
the following 2 commands shows both starting and ending revisions :
$ gitk client_release_7.0.41..client_release_7.0.42
$ gitk client_release_7.0.43..client_release_7.0.44
however this command doesn't show the tag
On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote:
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -2,6 +2,35 @@
# git-mergetool--lib is a library for common merge tool functions
MERGE_TOOLS_DIR=$(git --exec-path)/mergetools
+mode_ok () {
+ diff_mode
Michal Nazarewicz m...@google.com writes:
From: Michal Nazarewicz min...@mina86.com
Make git-send-email read password from a ~/.authinfo file instead of
requiring it to be stored in git configuration, passed as command line
argument or typed in.
Makes one wonder why .authinfo and not
On Tue, Jan 29, 2013 at 11:34:31AM -0800, Junio C Hamano wrote:
John Keeping j...@keeping.me.uk writes:
Changes since v1:
- Set 3.1 as the minimum Python 3 version
- Remove the section on Unicode literals - it just adds confusion and
doesn't apply to the current code; we can deal
Hi Toralf,
Toralf Förster wrote:
$ git clone git://boinc.berkeley.edu/boinc.git
the following 2 commands shows both starting and ending revisions :
$ gitk client_release_7.0.41..client_release_7.0.42
gitk is running something similar to
git log --graph --decorate --boundary
On 01/29/2013 08:57 PM, Jonathan Nieder wrote:
As you guessed, 7.0.45 seems to live in a different area of history. :)
Well, seems be point to the root cause ..
BTW
$ gitk --simplify-by-decoration client_release_7.0.44..client_release_7.0.45
only 3 rows in the main window where
$ gitk
John Keeping j...@keeping.me.uk writes:
On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote:
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -2,6 +2,35 @@
# git-mergetool--lib is a library for common merge tool functions
MERGE_TOOLS_DIR=$(git --exec-path)/mergetools
Sorry for being absent a long time. I hope you have managed to sort out
the git-blame fixes anyway.
Jonathan Nieder jrnie...@gmail.com writes:
Without this patch, the author column in git-blame-mode spills
over in some rows:
822a7d ram...@ramsay1.demon.co.uk:const char git_usage_
From: Michal Nazarewicz min...@mina86.com
Make git-send-email read password from a ~/.authinfo or a ~/.netrc
file instead of requiring it to be stored in git configuration, passed
as command line argument or typed in.
There are various other applications that use this file for
authentication
On Tue, Jan 29, 2013 at 07:58:01AM -0800, Junio C Hamano wrote:
The point is not about space. Disk is cheap, and it is not making
it any worse than what happens to your target audience, that is a
fetch-only repository with only gc --auto in it, where nobody
passes -f to repack to cause
On Tue, Jan 29, 2013 at 11:22 AM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jan 27, 2013 at 04:52:23PM -0800, David Aguilar wrote:
Update variable assignments to always use $(command $arg)
in their RHS instead of $(command $arg) as the latter
is harder to read. Make get_merge_tool_cmd()
Jeff King p...@peff.net writes:
But how do these somewhat mediocre concatenated packs get turned into
real packs?
How do they get processed in a fetch-only repositories that
sometimes run gc --auto today? By runninng repack -a -d -f
occasionally, perhaps?
Do we run repack -adf
On Tue, Jan 29, 2013 at 12:22 PM, Junio C Hamano gits...@pobox.com wrote:
John Keeping j...@keeping.me.uk writes:
On Sun, Jan 27, 2013 at 04:52:25PM -0800, David Aguilar wrote:
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -2,6 +2,35 @@
# git-mergetool--lib is a library for
David Aguilar dav...@gmail.com writes:
On Tue, Jan 29, 2013 at 11:22 AM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jan 27, 2013 at 04:52:23PM -0800, David Aguilar wrote:
Update variable assignments to always use $(command $arg)
in their RHS instead of $(command $arg) as the latter
is
Michal Nazarewicz m...@google.com writes:
It is rather strange to require a comma-separated-values parser to
read a file format this simple, isn't it?
I was worried about spaces in password. CVS should handle such case
nicely, whereas simple split won't. Nonetheless, I guess that in the
David Aguilar dav...@gmail.com writes:
I don't want to stomp on your feet and poke at this file too much if
you're planning on building on top of it (I already did a few times
;-). My git time is a bit limited for the next few days so I don't
want to hold you up. I can help shepherd through
On Tue, Jan 29, 2013 at 02:27:21PM -0800, David Aguilar wrote:
I don't want to stomp on your feet and poke at this file too much if
you're planning on building on top of it (I already did a few times
;-). My git time is a bit limited for the next few days so I don't
want to hold you up. I
On Tue, Jan 29, 2013 at 02:55:26PM -0800, Junio C Hamano wrote:
David Aguilar dav...@gmail.com writes:
I don't want to stomp on your feet and poke at this file too much if
you're planning on building on top of it (I already did a few times
;-). My git time is a bit limited for the next
From: Michal Nazarewicz min...@mina86.com
Make git-send-email read password from a ~/.authinfo or ~/.netrc file
instead of requiring it to be stored in git configuration, passed as
command line argument or typed in.
There are various other applications that use this file for
authentication
Ah! Lovely, thank you, Jeff!
Alas, it's a shared server so I'm limited to what the host provides, but that
solves my problem.
Cheers!
On 29 Jan 2013, at 19:23, Jeff King p...@peff.net wrote:
On Tue, Jan 29, 2013 at 04:54:13PM +1100, Michael Tyson wrote:
I've a readonly git repository
On Wed, Jan 30, 2013 at 1:44 AM, Jonathan Nieder jrnie...@gmail.com wrote:
- # You are currently rebasing.
+ # You are currently rebasing branch '\''rebase_conflicts'\'' on
'\''000106f'\''.
SHA1-in-tests radar blinking.
Would it be possible to compute the expected output, as in
On Tue, Jan 29, 2013 at 4:15 PM, Jeff King p...@peff.net wrote:
+static void write_meta_header(struct metapack_writer *mw, const char *id,
+ uint32_t version)
+{
+ version = htonl(version);
+
+ sha1write(mw-out, META, 4);
+ sha1write(mw-out,
On Jan 29, 2013, at 7:25 AM, Ævar Arnfjörð Bjarmason ava...@gmail.com wrote:
On Sun, Jan 27, 2013 at 9:37 AM, Michael Haggerty mhag...@alum.mit.edu
wrote:
A while ago, I submitted an RFC for adding a new email notification
script to contrib [1]. The reaction seemed favorable and it was
John Keeping j...@keeping.me.uk writes:
On Tue, Jan 29, 2013 at 02:55:26PM -0800, Junio C Hamano wrote:
...
I can work with John to get this part into a shape to support his
extended use sometime toward the end of this week, by which time
hopefully you have some time to comment on the
On Tue, Jan 29, 2013 at 4:14 PM, Jeff King p...@peff.net wrote:
The timings from this one are roughly similar to what I posted earlier.
Unlike the earlier version, this one keeps the data for a single commit
together for better cache locality (though I don't think it made a big
difference in
Junio C Hamano gits...@pobox.com writes:
Heh, I actually was hoping that you will send in a replacement for
David's patch ;-)
Here is what I will squash into the one we have been discussing. In
a few hours, I expect I'll be able to push this out in the 'pu'
branch.
I ended up doing this a
On Tue, Jan 29, 2013 at 4:16 PM, Jeff King p...@peff.net wrote:
+int commit_metapack(unsigned char *sha1,
+ uint32_t *timestamp,
+ unsigned char **tree,
+ unsigned char **parent1,
+ unsigned char **parent2)
+{
Nit
On 01/29/2013 12:10 PM, Jeff King wrote:
On Tue, Jan 29, 2013 at 11:15:34AM +0100, Michael Haggerty wrote:
Please document the new functions in
Documentation/technical/api-strbuf.txt. Personally I would also
advocate a docstring in the header file, but obviously that preference
is the
Update variable assignments to always use $(command $arg)
in their RHS instead of $(command $arg) as the latter
is harder to read. Make get_merge_tool_cmd() simpler by
avoiding echo and $(command) substitutions completely.
Signed-off-by: David Aguilar dav...@gmail.com
---
This is a replacement
On Tue, Jan 29, 2013 at 09:35:12AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
+static void write_meta_header(struct metapack_writer *mw, const char *id,
+ uint32_t version)
+{
+ version = htonl(version);
+
+ sha1write(mw-out, META, 4);
On Wed, Jan 30, 2013 at 08:30:57AM +0700, Nguyen Thai Ngoc Duy wrote:
On Tue, Jan 29, 2013 at 4:15 PM, Jeff King p...@peff.net wrote:
+static void write_meta_header(struct metapack_writer *mw, const char *id,
+ uint32_t version)
+{
+ version =
David Aguilar dav...@gmail.com writes:
Update variable assignments to always use $(command $arg)
in their RHS instead of $(command $arg) as the latter
is harder to read. Make get_merge_tool_cmd() simpler by
avoiding echo and $(command) substitutions completely.
Signed-off-by: David Aguilar
On Tue, Jan 29, 2013 at 09:38:10AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
+int commit_metapack(unsigned char *sha1,
+ uint32_t *timestamp,
+ unsigned char **tree,
+ unsigned char **parent1,
+ unsigned char
On Wed, Jan 30, 2013 at 10:36:10AM +0700, Nguyen Thai Ngoc Duy wrote:
On Tue, Jan 29, 2013 at 4:16 PM, Jeff King p...@peff.net wrote:
+int commit_metapack(unsigned char *sha1,
+ uint32_t *timestamp,
+ unsigned char **tree,
+ unsigned
On Wed, Jan 30, 2013 at 10:31:43AM +0700, Nguyen Thai Ngoc Duy wrote:
On Tue, Jan 29, 2013 at 4:14 PM, Jeff King p...@peff.net wrote:
The timings from this one are roughly similar to what I posted earlier.
Unlike the earlier version, this one keeps the data for a single commit
together for
Junio C Hamano gits...@pobox.com writes:
Please take this as just a preview of early WIP. I think I may end
up doing moderate amount of refactoring as a preparatory step before
these patches, so nitpick-reviews are likely to become waste of
reviewer's time at this point.
I've pushed out a
On Tue, Jan 29, 2013 at 11:53:19AM -0800, Junio C Hamano wrote:
Either way it still encourages a plaintext password to be on disk,
which may not be what we want, even though it may be slight if not
really much of an improvement. Again the Help-for-users has this
amusing bit:
I do not mind a
85 matches
Mail list logo
