Back in 233c3e6 (parse_pathspec: preserve prefix length via
PATHSPEC_PREFIX_ORIGIN - 2013-07-14), parse_pathspec() is taught to
save prefix length as a dynamic magic. This is needed when the
pathspec is passed to another process and and prefix lenght would be
lost.
Back then we support two cases.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/glossary-content.txt | 5 +
builtin/add.c| 5 +-
dir.c| 47 +++--
pathspec.c | 9 +-
pathspec.h | 4 +-
t/t6132-pathspec
A WIP patch [1] was posted a while ago. This is the polished version
with tests and stuff. '!' is used as the shortcut instead of '-'. You
can now say "select this path except this subpath..." for nearly all
commands that take pathspec.
[1] http://thread.gmane.org/gmane.comp.version-control.git/23
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/glossary-content.txt | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index aa1c888..b7e7ab5 100644
--- a/Documentation
From: Anders Waldenborg
diff.orderfile acts as a default for the -O command line option.
[sb: fixed testcases & revised docs based on Jonathan Nieder's suggestions]
Signed-off-by: Anders Waldenborg
Thanks-to: Jonathan Nieder
Signed-off-by: Samuel Bronson
---
*I* even verified that the tests
Until now, HEAD could be used with git-push to push the current
branch. Now @ is a shortcut to HEAD, but it didn't work when
pushing branches. It fails with:
fatal: remote part of refspec is not a valid name in @
Reinterpret all branch names from argv in order for @ to be used
when pushing bran
On 06/12/2013 08:07, Duy Nguyen wrote:
> On Wed, Dec 4, 2013 at 11:11 PM, SCHILZ MANFRED wrote:
>> Hello,
>> We are using git on windows7(git-version 1.8.1; see below) and we get the
>> following problem in using the command 'git --git-dir='
>>
>>
>> C:\UserTemp\git\appli3>git --git-dir=C:\UserT
On Fri, Dec 6, 2013 at 4:28 AM, Jeff King wrote:
> BTW, the raw looping to find "--" made me wonder how we handle:
>
> git log --grep -- HEAD
>
> I'd expect it to be equivalent to:
>
> git log --grep=-- HEAD
>
> but it's not; we truncate the arguments and complain that --grep is
> missing its
On Wed, Dec 4, 2013 at 11:11 PM, SCHILZ MANFRED wrote:
> Hello,
> We are using git on windows7(git-version 1.8.1; see below) and we get the
> following problem in using the command 'git --git-dir='
>
>
> C:\UserTemp\git\appli3>git --git-dir=C:\UserTemp\git\appli3 tag
> fatal: Not a git repositor
... instead of 1.8.6 (which would have been the name if we were on
auto-pilot), so that the version that comes after it will logically
be 2.0. Distro people may want to make sure that they are not
hardcoding "three-dewey-decimal are feature releases,
four-dewey-decimal are maintenance releases" he
When --prompt option is set, git-difftool displays a prompt for each modified
file to be viewed in an external diff program. At that point it could be useful
to display a counter and the total number of files in the diff queue.
Below is the current difftool prompt for the first of 5 modified files
Jens Lehmann writes:
> + fprintf(s->fp, "%c %s", comment_line_char, cut_line);
> + strbuf_add_commented_lines(&buf, explanation,
> strlen(explanation));
> + fprintf(s->fp, buf.buf);
This is better done with:
fputs(buf.buf, s->fp);
Already locally tw
Jeff King writes:
> The second half would be to simplify git-repack. The current behavior is
> to replace the old packfile with a tricky rename dance. Which is still
> correct, but overly complicated. We should be able to just drop the new
> packfile, since we know the bytes are identical (or ren
On Thu, Dec 5, 2013 at 2:54 PM, Jens Lehmann wrote:
> Am 05.12.2013 20:27, schrieb Martin Langhoff:
>> On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann wrote:
>>> Without knowing more I can't think of a reason why submodules should
>>> not suit your use case (but you'd have to script branching and ta
On Thu, Dec 5, 2013 at 12:28 PM, Jeff King wrote:
> Subject: pack-objects: name pack files after trailer hash
>
> Our current scheme for naming packfiles is to calculate the
> sha1 hash of the sorted list of objects contained in the
> packfile. This gives us a unique name, so we are reasonably
> s
Jeff King writes:
> BTW, the raw looping to find "--" made me wonder how we handle:
>
> git log --grep -- HEAD
>
> I'd expect it to be equivalent to:
>
> git log --grep=-- HEAD
>
> but it's not; we truncate the arguments and complain that --grep is
> missing its argument. Which is probably go
On Thu, Dec 05, 2013 at 04:00:00PM -0500, Jeff King wrote:
> Yes, I do expect an error. But it should not be "-- after filename". It
> should be "foobar is not a revision".
> [...]
> It would be nice to get the error messages right, though. I do not see
> any reason why it could not follow the sam
On Thu, Dec 05, 2013 at 12:15:07PM -0800, Junio C Hamano wrote:
> >> Hmph, it looks like it is following the usual "zero-or-more dashed
> >> options, zero-or-more revs and then zero-or-one double-dash and then
> >> zero-or-more paths" rule to parse the thing. "foobar" is a file and
> >> not a rev
Am 05.12.2013 00:19, schrieb Heiko Voigt:
> On Wed, Dec 04, 2013 at 02:32:46PM -0800, Junio C Hamano wrote:
> This series tries to achieve the following goals for the
> submodule..ignore=all configuration or the --ignore-submodules=all
> command line switch.
Thanks for the summary.
> * Make git
On Thu, Dec 05, 2013 at 11:04:18AM -0500, Jeff King wrote:
> > Yes. And this is why the packfile name algorithm is horribly flawed. I
> > keep saying we should change it to name the pack using the last 20
> > bytes of the file but ... nobody has written the patch for that? :-)
>
> Totally agree.
Jeff King writes:
> On Thu, Dec 05, 2013 at 12:00:16PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > $ >foobar
>> > $ git rev-parse foobar --
>> > foobar
>> > --
>> > fatal: bad flag '--' used after filename
>> >
>> > That's not right.
>>
>> Hmph, it looks like it is fo
Jens Lehmann writes:
> When using the '-v' option of "git commit" the diff added to the commit
> message temporarily for editing is stripped off after the user exited the
> editor by searching for "\ndiff --git " and truncating the commmit message
> there if it is found.
>
> But this approach has
On Thu, Dec 05, 2013 at 12:00:16PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > $ >foobar
> > $ git rev-parse foobar --
> > foobar
> > --
> > fatal: bad flag '--' used after filename
> >
> > That's not right.
>
> Hmph, it looks like it is following the usual "zero-or-more da
Jakub Narębski writes:
> But I am not against "return 0;" on validation error (would putting
> it in separate patch make review easier, or just pointlessly proliferate
> patches?).
OK.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ke
Jeff King writes:
> $ >foobar
> $ git rev-parse foobar --
> foobar
> --
> fatal: bad flag '--' used after filename
>
> That's not right.
Hmph, it looks like it is following the usual "zero-or-more dashed
options, zero-or-more revs and then zero-or-one double-dash and then
zero-or-more
Am 05.12.2013 20:27, schrieb Martin Langhoff:
> On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann wrote:
>> Without knowing more I can't think of a reason why submodules should
>> not suit your use case (but you'd have to script branching and tagging
>> yourself until these commands learn to recurse in
Nick Townsend writes:
> Interplay between paths specified in three ways now tested:
> * After a : in the tree-ish,
> * As a pathspec in the command,
> * By virtue of the current working directory
>
> Note that these tests are based on the behaviours
> as found in 1.8.5. They may not be intentiona
When using the '-v' option of "git commit" the diff added to the commit
message temporarily for editing is stripped off after the user exited the
editor by searching for "\ndiff --git " and truncating the commmit message
there if it is found.
But this approach has two problems:
- when the commit
On Thu, Dec 5, 2013 at 2:18 PM, Jens Lehmann wrote:
> Without knowing more I can't think of a reason why submodules should
> not suit your use case (but you'd have to script branching and tagging
> yourself until these commands learn to recurse into submodules too).
The submodules feature is way
Am 05.12.2013 00:01, schrieb Martin Langhoff:
> Hi folks.
>
> currently working on a project based on Moodle (the LMS that got me
> into git in the first place). This is a highly modular software, and I
> would like to maintain a bunch of "out of tree" modules in a single
> repository, and be able
On Thu, Dec 05, 2013 at 05:07:31PM +0700, Duy Nguyen wrote:
> $ git rev-parse foobar --
> foobar
> fatal: ambiguous argument 'foobar': unknown revision or path not in
> the working tree.
> Use '--' to separate paths from revisions, like this:
> 'git [...] -- [...]'
>
> I already put "--" there.
On Thu, Dec 5, 2013 at 7:16 PM, Junio C Hamano wrote:
> Krzesimir Nowak writes:
>> On Wed, 2013-12-04 at 17:07 +0100, Jakub Narębski wrote:
>>> The only change that needs to be done is replacing
>>>
>>>return $input;
>>>
>>> with
>>>
>>>return 1;
>>>
>>
>> I prefer to use
On Thu, Dec 05, 2013 at 10:01:28AM -0800, Junio C Hamano wrote:
> > You could have a "git-advertise-upstream" that generates a mirror blob
> > from your remotes config and pushes it to your publishing point. That
> > may be overkill, but I don't think it's possible with a
> > .git/config-based sol
On Wed, Dec 4, 2013 at 6:01 PM, Martin Langhoff
wrote:
> Is there a reasonable approach to scripting this?
Found my answers.
The 'subtree' merge strategy is smart enough to "mostly" help here.
However, it does not handle new files created in the subdirectory.
My workflow is this one. It is simi
Duy Nguyen writes:
> On Thu, Dec 5, 2013 at 8:23 AM, Junio C Hamano wrote:
>> * aa/transport-non-positive-depth-only (2013-11-26) 1 commit
>> (merged to 'next' on 2013-11-27 at b01f05b)
>> + transport: catch non positive --depth option value
>>
>> Will merge to 'master'.
>
> Don't. It breaks
Krzesimir Nowak writes:
> On Wed, 2013-12-04 at 17:07 +0100, Jakub Narębski wrote:
>> The only change that needs to be doe is replacing
>>
>>return $input;
>>
>> with
>>
>>return 1;
>>
>
> I prefer to use zeros instead of undefs - one might wonder if that undef
> is so
Christian Couder writes:
> Tell me if I can do something.
I think the tip of 'pu' with cc/starts-n-ends-with-endgame is in
fairly a good shape. The evil merge there may need to be updated
over time, but I think I can manage.
--
To unsubscribe from this list: send the line "unsubscribe git" in
t
Jeff King writes:
> Right, I think that's the most critical one (though you could also just
> use the convention of ".bundle" in the URL). I think we may want to
> leave room for more metadata, though.
Good. I like this line of thinking.
>> Heck, remote.origin.url might already
>> be a good mir
On Thu, Dec 05, 2013 at 02:21:09PM +0100, Michael Haggerty wrote:
> A better alternative would be to ask users to clone from the central
> server. In this case, the central server would want to tell the clients
> to grab what they can from their local bootstrap mirror and then come
> back to the
On Wed, Dec 04, 2013 at 10:50:27PM -0800, Shawn Pearce wrote:
> I wasn't thinking about using a "well known blob" for this.
>
> Jonathan, Dave, Colby and I were kicking this idea around on Monday
> during lunch. If the initial ref advertisement included a "mirrors"
> capability the client could r
Good Day,
This mail is to make an inquiry on the below Questions.
Do you Ship oversea or do intend to start Shipping oversea? (though we already
know of a Freight Forwarder that will pick our packages from you and deliver to
us Australia.
PAYMENT MODE...CREDIT CARD
Kindly send
http://goo.gl/N47wYu проститесь с расплывчатым очертанием В телевизоре
N▀╖╡ФЛr╦⌡yЗХ ьb╡X╛╤г╖vь^√)ч╨{.nг+┴╥═┼ь╖╤⌡║э╗}╘·╡ф═zз&j:+v┴╗╬╚▒ЙГzZ+─й+zfё╒╥h
┬╖~├╜├шiЪШЮz╧ ╝w╔╒╦?≥╗Х╜з&╒)ъ╒f
On Thu, Dec 5, 2013 at 5:21 AM, Michael Haggerty wrote:
> This discussion has mostly been about letting small Git servers delegate
> the work of an initial clone to a beefier server. I haven't seen any
> explicit mention of the inverse:
>
> Suppose a company has a central Git server that is meant
This discussion has mostly been about letting small Git servers delegate
the work of an initial clone to a beefier server. I haven't seen any
explicit mention of the inverse:
Suppose a company has a central Git server that is meant to be the
"single source of truth", but has worldwide offices and
Now that git supports data transfer from or to a shallow clone, these
limitations are not true anymore.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-clone.txt | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-cl
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/receive-pack.c | 3 ---
t/t5537-push-shallow.sh | 35 +++
2 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 5c85bb4..78fe8ee 100644
--- a/builtin/r
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/gitremote-helpers.txt | 7 +++
builtin/fetch-pack.c| 16 +---
remote-curl.c | 31 +--
t/t5536-fetch-shallow.sh| 27 +++
tran
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/send-pack.c | 3 ---
send-pack.c | 19 +--
t/t5537-push-shallow.sh | 25 +
3 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index 664dd
The basic 8 steps to update .git/shallow does not fully apply here
because the user may choose to accept just a few refs (while fetch
always accepts all refs). The steps are modified a bit.
1-6. same as before. After calling assign_shallow_commits_to_refs at
step 6, each shallow commit has a bi
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/fetch-pack.c | 7 +++
remote-curl.c| 3 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index 927424b..aa6e596 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@
This patch teaches "prune" to remove shallow roots that are no longer
reachable from any refs (e.g. when the relevant refs are removed).
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/git-prune.txt | 2 ++
builtin/gc.c| 1 +
builtin/prune.c | 4
commit.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/send-pack.c | 4 +++-
t/t5537-push-shallow.sh | 38 ++
transport.c | 5 ++---
3 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index ea2ab
clone_local() does not handle $SRC/shallow. It could be made so, but
it's simpler to use fetch-pack/upload-pack instead.
This used to be caught by the check in upload-pack, which is triggered
by transport_get_remote_refs(), even in local clone case. The check is
now gone and check_everything_conne
Signed-off-by: Nguyễn Thái Ngọc Duy
---
connected.c | 42 ++
connected.h | 2 ++
2 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/connected.c b/connected.c
index fae8d64..427389d 100644
--- a/connected.c
+++ b/connected.c
@@ -19,17 +19,17 @@
This may be needed when a hook is run after a new shallow pack is
received, but .git/shallow is not settled yet. A temporary shallow
file to plug all loose ends should be used instead. GIT_SHALLOW_FILE
is overriden by --shallow-file.
--shallow-file does not work in this case because the hook may s
This is the preparation for adding --shallow-file to both
unpack-objects and index-pack. To sum up:
- struct argv_array used instead of const char **
- status/code, ip/child, unpacker/keeper are moved out to function
top level
- successful flow now ends at the end of the function
Signed-o
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/technical/pack-protocol.txt | 4 +-
builtin/receive-pack.c| 78 +++
builtin/send-pack.c | 2 +-
send-pack.c | 3 ++
t/t5537-push-shallow.sh
When "fetch --depth=N" where N exceeds the longest chain of history in
the source repo, usually we just send an "unshallow" line to the
client so full history is obtained.
When the source repo is shallow we need to make sure to "unshallow"
the current shallow point _and_ "shallow" again when the c
The same steps are done as in when --update-shallow is not given. The
only difference is we now add all shallow commits in "ours" and
"theirs" to .git/shallow (aka "step 8").
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/fetch-options.txt | 6 ++
builtin/fetch.c | 6
Signed-off-by: Nguyễn Thái Ngọc Duy
---
fetch-pack.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/fetch-pack.c b/fetch-pack.c
index 0e7483e..35d097e 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -925,6 +925,18 @@ static int remove_duplicates_in_ref
This patch just put together pieces from the 8 steps patch. We stop at
step 7 and reject refs that require new shallow commits.
Note that, by rejecting refs that require new shallow commits, we
leave dangling objects in the repo, which become "object islands" by
the next "git fetch" of the same so
Signed-off-by: Nguyễn Thái Ngọc Duy
---
fetch-pack.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/fetch-pack.h b/fetch-pack.h
index 461cbf3..9b08388 100644
--- a/fetch-pack.h
+++ b/fetch-pack.h
@@ -8,18 +8,18 @@ struct fetch_pack_args {
co
Signed-off-by: Nguyễn Thái Ngọc Duy
---
commit.h | 3 +
shallow.c | 295 ++
2 files changed, 298 insertions(+)
diff --git a/commit.h b/commit.h
index 9ead93b..69bca3e 100644
--- a/commit.h
+++ b/commit.h
@@ -223,6 +223,9 @@ extern vo
Cloning from a shallow repository does not follow the "8 steps for new
.git/shallow" because if it does we need to get through step 6 for all
refs. That means commit walking down to the bottom.
Instead the rule to create .git/shallow is simpler and, more
importantly, cheap: if a shallow commit is
Suppose a fetch or push is requested between two shallow repositories
(with no history deepening or shortening). A pack that contains
necessary objects is transferred over together with .git/shallow of
the sender. The receiver has to determine whether it needs to update
.git/shallow if new refs nee
Signed-off-by: Nguyễn Thái Ngọc Duy
---
transport.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/transport.h b/transport.h
index 8f96bed..b3679bb 100644
--- a/transport.h
+++ b/transport.h
@@ -193,10 +193,4 @@ void transport_print_push_status(const char *dest, struct
ref *refs,
ty
This reroll should fix all comments I have received in v3. I reordered
the shallow checks a bit so in common case it should be as cheap as
a normal fetch or push. See 08/28 and 20/28 for the big picture. I'm not
entirely happy with the hook issue in 20/28, but it looks good enough
for me. There are
send-pack can send a pack with loose ends to the server. receive-pack
before 6d4bb38 (fetch: verify we have everything we need before
updating our ref - 2011-09-01) does not detect this and keeps the pack
anyway, which corrupts the repository, at least from fsck point of
view.
send-pack will lear
If either receive-pack or upload-pack is called on a shallow
repository, shallow commits (*) will be sent after the ref
advertisement (but before the packet flush), so that the receiver has
the full "shape" of the sender's commit graph. This will be needed for
the receiver to update its .git/shallo
The latter can do everything the former can and is used in many more
places.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/send-pack.c | 5 ++---
connect.c | 12 +++-
remote.h| 7 ++-
send-pack.c | 7 ---
send-pack.h | 2 +-
transport.c
No callers pass a non-empty pointer as shallow_points at this
stage. As a result, all clients still refuse to talk to shallow
repository on the other end.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/fetch-pack.c | 2 +-
builtin/send-pack.c | 2 +-
connect.c| 12 +++-
r
Signed-off-by: Nguyễn Thái Ngọc Duy
---
commit.h | 8 +---
fetch-pack.c | 5 +++--
shallow.c | 20 +++-
upload-pack.c | 2 +-
4 files changed, 24 insertions(+), 11 deletions(-)
diff --git a/commit.h b/commit.h
index a879526..1faf717 100644
--- a/commit.h
+++ b/co
If we borrow objects from another repository, we should also pay
attention to their $GIT_DIR/shallow (and even info/grafts). But
current alternates code does not.
Reject alternate repos that are shallow because we do not do it
right. In future the alternate code may be updated to check
$GIT_DIR/sh
This is very urgent from Western Union, our Operation manager has sent your
1st
payment of $5000.00 out of your total amount of $1.5million dollar and we
needed this from you to complete the ransfer, You’ re Name,Address, ID CARD
and
Telephone No: Noted That Only Fee Request from You Is for Reactiv
On Thu, Dec 5, 2013 at 11:00 AM, Krzesimir Nowak wrote:
> On Wed, 2013-12-04 at 19:06 +0100, Jakub Narębski wrote:
>> On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak
>> wrote:
>>> +The gitweb.extrabranchrefs is actually a multi-valued configuration
>>> +variable, so following example is also co
$ git rev-parse foobar --
foobar
fatal: ambiguous argument 'foobar': unknown revision or path not in
the working tree.
Use '--' to separate paths from revisions, like this:
'git [...] -- [...]'
I already put "--" there. So it should shut up.
--
Duy
--
To unsubscribe from this list: send the line
On Wed, 2013-12-04 at 19:06 +0100, Jakub Narębski wrote:
> On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak
> wrote:
> >
> > Allow extra-branch-refs feature to tell gitweb to show refs from
> > additional hierarchies in addition to branches in the list-of-branches
> > view.
> >
> > Signed-off-by:
On Wed, 2013-12-04 at 17:07 +0100, Jakub Narębski wrote:
> On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak
> wrote:
>
> > Users of validate_* passing "0" might get failures on correct name
> > because of coercion of "0" to false in code like:
> > die_error(500, "invalid ref") unless (check_ref_f
On Wed, 2013-12-04 at 16:56 +0100, Jakub Narębski wrote:
> On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak
> wrote:
>
> > This check will be used in more than one place later.
> >
> > Signed-off-by: Krzesimir Nowak
> > Reviewed-by: Junio C Hamano
> > Reviewed-by: Jakub Narębski
>
> All right
On Wed, 2013-12-04 at 12:31 -0800, Junio C Hamano wrote:
> Krzesimir Nowak writes:
>
> > This check will be used in more than one place later.
> >
> > Signed-off-by: Krzesimir Nowak
> > Reviewed-by: Junio C Hamano
>
> Again, I do not think I reviewed this exact version. Nor did I say
> that us
On Wed, 2013-12-04 at 12:28 -0800, Junio C Hamano wrote:
> Martin Langhoff writes:
>
> > On Wed, Dec 4, 2013 at 10:46 AM, Krzesimir Nowak
> > wrote:
> >> On Wed, 2013-12-04 at 16:11 +0100, Jakub Narębski wrote:
> >>> On Wed, Dec 4, 2013 at 2:42 PM, Krzesimir Nowak
> >>> wrote:
> >>>
> >>> > S
81 matches
Mail list logo
