On Fri, Nov 10, 2017 at 10:39:39AM +0100, Peter Krefting wrote:
> Running strace, it seems like it is doing lstat(), open(), mmap(), close()
> and munmap() on every single file in the repository, which takes a lot of
> time.
>
> I thought it was just updating the status, but "git status" returns
From: Phillip Wood
Move run_rewrite_hook() from bulitin/commit.c to sequencer.c so it can
be shared with other commands and add a new function
commit_post_rewrite() based on the code in builtin/commit.c that
encapsulates rewriting notes and running the post-rewrite
From: Phillip Wood
If the commit message does not need to be edited then create the
commit without forking 'git commit'. Taking the best time of ten runs
with a warm cache this reduces the time taken to cherry-pick 10
commits by 27% (from 282ms to 204ms), and the time
From: Phillip Wood
Load default values for message cleanup and gpg signing of commits in
preparation for committing without forking 'git commit'.
Signed-off-by: Phillip Wood
---
Notes:
changes since v1:
- renamed
From: Phillip Wood
Thanks for the feedback on v1 I've updated the patches as
suggested. See the comments on each patch for what has changed. I've
added a patch to the start of the series to test the commit messages
of intermediate squashes. I've added this as the RFC
From: Phillip Wood
Return an error rather than dying so that the sequencer can exit
cleanly once it starts committing without forking 'git commit'
Signed-off-by: Phillip Wood
---
builtin/commit.c | 3 ++-
sequencer.c | 17
From: Phillip Wood
When there is more than one squash/fixup command in a row check the
intermediate messages are correct.
Signed-off-by: Phillip Wood
---
t/t3404-rebase-interactive.sh | 4
1 file changed, 4 insertions(+)
diff --git
From: Phillip Wood
Move print_commit_summary() from builtin/commit.c to sequencer.c so it
can be shared with other commands. The function is modified by
changing the last argument to a flag so callers can specify whether
they want to show the author date in addition
From: Phillip Wood
Add update_head() based on the code that updates HEAD after committing
in builtin/commit.c that can be called by 'git commit' and other
commands.
Signed-off-by: Phillip Wood
---
Notes:
changes since v1:
-
From: Phillip Wood
Add the Signed-off-by: trailer in one place rather than adding it to
the message when doing a recursive merge and specifying '--signoff'
when running 'git commit'. This means that if there are conflicts when
merging with a strategy other than
Hi!
On a big repository (57000 files, 2,5 gigabytes in .git/objects), git
cherry-pick is very slow for me (v2.15.0). This is cherry-picking a
one-file change, where the file is in the same place on both branches,
and which applies cleanly (I am backporting a few fixes to a
maintenance
On Fri, Nov 10, 2017 at 09:52:16AM +0900, Junio C Hamano wrote:
> > That said, if this is the only place that has this funny quoting, it may
> > not be worth polluting the rest of the code with the idea that quoting
> > spaces is a good thing to do.
>
> Sounds sane. We can probably use a helper
Good day,
I am Mr. Sam Azada from Burkina Faso a Minister confide on me to look
for foreign partner who will assist him to invest the sum of Fifty
Million Dollars ($50,000,000) in your country.
He has investment interest in mining, exotic properties for commercial
resident, development
On Friday 10 November 2017 at 12:14 pm +0900, Junio C Hamano wrote:
> Eric Sunshine writes:
>
> > or against the change:
> >
> > - synonym bloat; balloons documentation
> > - steals command verbs from potential future features
> > - ...
>
> I tend to agree
> We hung back on it to leave it as low-hanging fruit for other Outreachy
> applicants. Perhaps Olga would like to pick it up now that the
> application period is over.
It's absolutely not a problem for me, I can do that as one more
warm-up exercise in the beginning of the internship.
Thanks!
Hello everyone,
There seems to be a difference how Git 2.15.0 handles submodules in
comparison with 2.14.2.
In Git 2.14.2 `git commit -a` will not stage submodules which has
`ignore = all` set in their .gitmodule section. However, in Git 2.15.0
`git commit -a` will stage all submodules no matter
From: Phillip Wood
Move the functions that check for empty messages from bulitin/commit.c
to sequencer.c so they can be shared with other commands. The
functions are refactored to take an explicit cleanup mode and template
filename passed by the caller.
Hi,
I'm starting to look into the cover-at-tip topic that I found in the leftover
bits (http://www.spinics.net/lists/git/msg259573.html)
Here's a first draft of a patch that adds support for format-patch
--cover-at-tip. It compiles and works in my nice and user firnedly test case.
Just wanted
Jeff King:
Can you get a backtrace? I'd do something like:
Seems that it spends most time in diffcore_count_changes(), that is
where it hits whenever I hit Ctrl+C (various line numbers 199-207 in
diffcore-delta.c; this is on the v2.15.0 tag).
(gdb) bt
#0 diffcore_count_changes
Hi,
It is hard to work with Git tags, because on low level hash
of non-annotated tag is pointing to commit, but hash for
annotated tag is pointing to tag metadata.
On low level that means that there is no way to get commit
hash from tag in a single step. If tag is annotated, you need
to find and
On 11/10/2017 7:37 AM, Peter Krefting wrote:
Jeff King:
Can you get a backtrace? I'd do something like:
Seems that it spends most time in diffcore_count_changes(), that is
where it hits whenever I hit Ctrl+C (various line numbers 199-207 in
diffcore-delta.c; this is on the v2.15.0 tag).
On 07/11/17 15:13, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> And this step is going in the right direction, but I am not sure if
>> this made the function safe enough to be called repeatedly from the
>> rebase machinery and we are ready to unleash this to the end
The examples and common practice for adding markers such as "RFC" or
"v2" to the subject of patch emails is to have them within the same
brackets as the "PATCH" text, not after the closing bracket. Further,
the practice of `git format-patch` and the like, as well as what appears
to be the more
Le 10/11/2017 à 11:24, Nicolas Morey-Chaisemartin a écrit :
> Hi,
>
> I'm starting to look into the cover-at-tip topic that I found in the leftover
> bits (http://www.spinics.net/lists/git/msg259573.html)
>
> Here's a first draft of a patch that adds support for format-patch
> --cover-at-tip.
On 07/11/17 00:18, Junio C Hamano wrote:
> Jacob Keller writes:
>
> I would have to say that the describe's one is wrong if it does not
> match what for_each_glob_ref() does for the log family of commands'
> "--branches=" etc. describe.c::get_name() uses positive
> and
Derrick Stolee:
Git is spending time detecting renames, which implies you probably
renamed a folder or added and deleted a large number of files. This
rename detection is quadratic (# adds times # deletes).
Yes, a couple of directories with a lot of template files have been
renamed (and
I faced an unexpected behaviour during cherry-picking
a commit to a branch with a submodule.
Git graph:
A -- B [master]
\
`- C -- D [test]
Both branches have a file with name `a_file`.
It has been added by commit A.
Commits B and C add a folder with name `a_submodule` to the respective
And while at it let's simplify t0021/rot13-filter.pl by
using Git/Packet.pm.
This will make it possible to reuse packet related
functions in other test scripts.
Signed-off-by: Christian Couder
---
perl/Git/Packet.pm | 169
These function help read and write capabilities.
To make them more generic and make it easy to reuse them,
the following changes are made:
- we don't require capabilities to come in a fixed order,
- we allow duplicates,
- we check that the remote supports the capabilities we
advertise,
- we
To make it possible in a following commit to move packet
reading and writing functions into a Packet.pm module,
let's refactor these functions, so they don't handle
printing debug output and exiting.
While at it let's create packet_key_val_read()
to still handle erroring out in a common case.
Goal
Packet related functions in Perl can be useful to write new filters or
to debug or test existing filters. They might also in the future be
used by other software using the same packet line protocol. So instead
of having them in t0021/rot13-filter.pl, let's extract them into a new
Since edcc8581 ("convert: add filter..process
option", 2016-10-16) when t0021/rot13-filter.pl was created, list
comparison in this perl script have been quite broken.
packet_txt_read() returns a 2-element list, and the right hand
side of "eq" also has a list with (two, elements), but "eq" takes
Before further refactoring the "t0021/rot13-filter.pl" script,
let's modernize the style of its 'if .. elsif .. else' clauses
to improve its readability by making it more similar to our
other perl scripts.
Signed-off-by: Christian Couder
---
t/t0021/rot13-filter.pl | 39
If there is no new line at the end of something it receives,
the packet_txt_read() function die()s, but it's difficult to
debug without much context.
Let's give a bit more information when that happens.
Signed-off-by: Christian Couder
---
t/t0021/rot13-filter.pl | 3
Let's refactor the code to initialize communication into its own
packet_initialize() function, so that we can reuse this
functionality in following patches.
Signed-off-by: Christian Couder
---
t/t0021/rot13-filter.pl | 26 --
1 file changed, 16
As checking for a lf character at the end of a buffer
will be useful in another function, let's refactor this
functionality into a small remove_final_lf_or_die()
helper function.
Signed-off-by: Christian Couder
---
t/t0021/rot13-filter.pl | 16
1 file
digging through both git-bisect.sh and git-bisect.txt, and it seems
pretty clear they're both a bit out of date WRT documenting the newer
alternatives "old"/"new" as opposed to the older "good"/"bad" terms,
and a few other things.
first, trivially, neither the script nor the man page mention
Rafael Ascensão writes:
> I agree that describe should receive the "normalize" treatment. However,
> and following the same reasoning, why should describe users adopt the
> rules imposed by --glob? I could argue they're also used to the way it
> works now.
>
> That being
On Fri, Nov 10, 2017 at 03:02:50PM +, Adam Dinwoodie wrote:
> The examples and common practice for adding markers such as "RFC" or
> "v2" to the subject of patch emails is to have them within the same
> brackets as the "PATCH" text, not after the closing bracket. Further,
> the practice of
On Fri, Nov 10, 2017 at 5:57 AM, Robert P. J. Day wrote:
>
> just noticed these examples in "man git-bisect":
>
> EXAMPLES
> $ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good
> ...
> $ git bisect start HEAD origin --# HEAD is bad, origin is good
>
On Fri, Nov 10, 2017 at 10:13 AM, Elijah Newren wrote:
> In a repo with around 60k files with deep directory hierarchies (due to
> Elijah Newren (4):
> sequencer: Warn when internal merge may be suboptimal due to
> renameLimit
> Remove silent clamp of renameLimit
>
On Fri, 10 Nov 2017 16:37:49 +0100
Nicolas Morey-Chaisemartin wrote:
> > Hi,
> >
> > I'm starting to look into the cover-at-tip topic that I found in the
> > leftover bits (http://www.spinics.net/lists/git/msg259573.html)
Thanks - I personally would find this very
On 10/11/17 11:09, Phillip Wood wrote:
> From: Phillip Wood
>
> Move the functions that check for empty messages from bulitin/commit.c
> to sequencer.c so they can be shared with other commands. The
> functions are refactored to take an explicit cleanup mode and
Tweak a number of files to mention "view" as an alternative to
"visualize":
Documentation/git-bisect.txt | 9 -
Documentation/user-manual.txt | 3 ++-
builtin/bisect--helper.c | 2 +-
contrib/completion/git-completion.bash | 2 +-
git-bisect.sh
Dear Western Union Customer,
You have been awarded with the sum of $50,000 USD by our office, as one of our
customers who use Western Union in their daily business transaction. This award
was been selected through the internet, where your e-mail address was indicated
and notified. Please
When trying to cherry-pick a change that has lots of renames, it is
somewhat unsettling to wait a really long time without any feedback.
Signed-off-by: Elijah Newren
---
sequencer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sequencer.c b/sequencer.c
index
On Thu, Nov 9, 2017 at 9:00 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> We have no worktree specific config yet, though patches for
>> this were floated on the mailing list.
>>
>> Though recent versions of git learned to conditionally include
>>
JPMorgan Chase & Co.
270 Park Avenue,
Midtown Manhattan
New York City,
Attention:
We are pleased to inform you about your fund which was seized by International
Monetary Fund (IMF) due to your failure to provide necessary credentials which
state the legitimacy of your fund, the fund was said
Phillip Wood writes:
> On 07/11/17 15:13, Junio C Hamano wrote:
> ...
>> Another possibility perhaps is that the function is safe to reuse
>> already even without this patch, of course ;-).
>>
> Hmm, maybe it is. Looking at pick_commits() and do_pick_commit() if the
>
Since this is happening during a merge, you might need to use merge.renameLimit
or the merge strategy option of -Xno-renames. Although the code does fallback
to use the diff.renameLimit but there is still a lot that is done before even
checking
the rename limit so I would first try getting
Interesting timing. I have some performance patches specifically
developed because rename detection during merges made a small
cherry-pick in a large repo rather slow...in my case, I dropped the
time for the cherry pick by a factor of about 30 (no guarantees you'll
see the same; it's very
In commit 0024a5492 (Fix the rename detection limit checking; 2007-09-14),
the renameLimit was clamped to 32767. This appears to have been to simply
avoid integer overflow in the following computation:
num_create * num_src <= rename_limit * rename_limit
although it also could be viewed as a
In a repo with around 60k files with deep directory hierarchies (due to
being predominantly java code) and which had a few high level directories
moved around (making it appear to git as dozens of thousands of individual
file renames), attempts to cherry-pick commits across product versions
In a repo with around 60k files with deep directory hierarchies (due to
being predominantly java code) and which had a few high level directories
moved around (making it appear to git as dozens of thousands of individual
file renames), attempts to cherry-pick commits across product versions
Jeff King writes:
> Are there callers who don't just print the result? If not, we could just
> always emit. That's slightly more efficient since it drops the expensive
> strbuf_insert (though there are already so many copies going on in
> quote_path_relative that it hardly
Nicolas Morey-Chaisemartin writes:
> I would need to add "some" level of parsing to am.c to make sure
> the patch content is just garbage and that there are no actual
> hunks for that.
>
> I did not find any public API that would allow me to do that,
> although
Phillip Wood writes:
> From: Phillip Wood
>
> Add update_head() based on the code that updates HEAD after committing
> in builtin/commit.c that can be called by 'git commit' and other
> commands.
>
> Signed-off-by: Phillip Wood
Thanks for taking a look!
On Fri, Nov 10, 2017 at 10:26 AM, Stefan Beller wrote:
>> - if (rename_limit <= 0 || rename_limit > 32767)
>> - rename_limit = 32767;
>> if ((num_create <= rename_limit || num_src <= rename_limit) &&
>> -
I faced an unexpected behaviour during cherry-picking
a commit to a branch with a submodule.
Git graph:
A -- B [master]
\
`- C -- D [test]
Both branches have a file with name `a_file`.
It has been added by commit A.
Commits B and C add a folder with name `a_submodule` to the respective
Having renamed files silently treated as deleted/modified conflicts
instead of correctly resolving the renamed/modified case has caused lots
of pain for some users. Eventually, some of them figured out to set
merge.renameLimit to something higher, but without feedback about what
value it should
The possibility of setting merge.renameLimit beyond 2^16 raises the
possibility that the values passed to progress can exceed 2^32. For my
usecase of interest, I only needed to pass a value a little over 2^31. If
I were only interested in fixing my usecase, I could have simply changed
last_value
On Fri, Nov 10, 2017 at 9:39 AM, Elijah Newren wrote:
> In commit 0024a5492 (Fix the rename detection limit checking; 2007-09-14),
> the renameLimit was clamped to 32767. This appears to have been to simply
> avoid integer overflow in the following computation:
>
>
>
>>> Basically, a workflow where it's easier to have each submodule checked
>>> out at master, and we can still keep track of historical relationship
>>> of what commit was the submodule at some time ago, but without causing
>>> some of these headaches.
>>
>> So essentially a repo or otherwise
This fixes an issue that existed before my directory rename detection
patches that affects both normal renames and renames implied by
directory rename detection. Additional codepaths that only affect
overwriting of directy files that are involved in directory rename
detection will be added in a
I want to re-use some other functions in the file without moving those other
functions or dealing with a handful of annoying split function declarations
and definitions.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 138
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 347
1 file changed, 347 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index 157299105f..115d0d2622 100755
---
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 401
1 file changed, 401 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index 7af8962512..4066b08767 100755
---
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 303
1 file changed, 303 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index ec054b210a..d15153c652 100755
---
The amount of logic in merge_trees() relative to renames was just a few
lines, but split it out into new handle_renames() and cleanup_renames()
functions to prepare for additional logic to be added to each. No code
or logic changes, just a new place to put stuff for when the rename
detection
directory renaming and merging can cause one or more files to be moved to
where an existing file is, or to cause several files to all be moved to
the same (otherwise vacant) location. Add checking and reporting for such
cases, falling back to no-directory-rename handling for such paths.
Directory renames with the ability to merge directories opens up the
possibility of add/add/add/.../add conflicts, if each of the N
directories being merged into one target directory all had a file with
the same name. We need a way to check for and report on such
collisions; this hashmap will be
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 371
1 file changed, 371 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index 115d0d2622..bdfd943c88 100755
---
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 283
1 file changed, 283 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index d15153c652..157299105f 100755
---
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 137
1 file changed, 137 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index 00811f512a..021513ec00 100755
---
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 505
1 file changed, 505 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index bdfd943c88..bb179b16c8 100755
---
[This series is entirely independent of my rename detection limits series.
However, I have a separate rename detection performance series that depends
on both this series and the rename detection limits series.]
In this patchset, I introduce directory rename detection to merge-recursive,
t3501 had a testcase originally added to ensure cherry-pick wouldn't
segfault when working with a dirty file involved in a rename. While
the segfault was fixed, there was another problem this test demonstrated:
namely, that git would overwrite a dirty file involved in a rename.
Further, the test
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 100
1 file changed, 100 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index 021513ec00..ec054b210a 100755
---
get_renames() would look up stage data that already existed (populated
in get_unmerged(), taken from whatever unpack_trees() created), and if
it didn't exist, would call insert_stage_data() to create the necessary
entry for the given file. The insert_stage_data() fallback becomes
much more
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 125
1 file changed, 125 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index b737b0a105..00811f512a 100755
---
On Fri, 20 Oct 2017 10:18:39 -0700
Brandon Williams wrote:
> Some of the pain points with the current protocol spec are:
After some in-office discussion, I think that the most important pain
point is that we have to implement each protocol twice: once for
HTTP(S), and once
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 391
1 file changed, 391 insertions(+)
create mode 100755 t/t6043-merge-rename-directories.sh
diff --git a/t/t6043-merge-rename-directories.sh
This populates a list of directory renames for us. The list of
directory renames is not yet used, but will be in subsequent commits.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 146 ++
1 file changed, 146
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 314
1 file changed, 314 insertions(+)
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
index bb179b16c8..7af8962512 100755
---
Create a new function, get_diffpairs() to compute the diff_filepairs
between two trees. While these are currently only used in
get_renames(), I want them to be available to some new functions. No
actual logic changes yet.
Signed-off-by: Elijah Newren
---
merge-recursive.c |
Signed-off-by: Elijah Newren
---
merge-recursive.c | 39 +++--
t/t6043-merge-rename-directories.sh | 6 +++---
2 files changed, 40 insertions(+), 5 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index
This just adds dir_rename_entry and the associated functions; code using
these will be added in subsequent commits.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 24
merge-recursive.h | 8
2 files changed, 32 insertions(+)
diff --git
This commit hooks together all the directory rename logic by making the
necessary changes to the rename struct, it's dst_entry, and the
diff_filepair under consideration.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 195
merge_trees() did a variety of work, including:
* Calling get_unmerged() to get unmerged entries
* Calling record_df_conflict_files() with all unmerged entries to
do some work to ensure we could handle D/F conflicts correctly
* Calling get_renames() to check for renames.
An easily
If I have to walk through the debugger and inspect the values found in
here in order to figure out their meaning, despite having known these
things inside and out some years back, then they probably need a comment
for the casual reader to explain their purpose.
Signed-off-by: Elijah Newren
Before trying to apply directory renames to paths within the given
directories, we want to make sure that there aren't conflicts at the
directory level. There will be additional checks at the individual
file level too, which will be added later.
Signed-off-by: Elijah Newren
get_renames() has always zero'ed out diff_queued_diff.nr while only
manually free'ing diff_filepairs that did not correspond to renames.
Further, it allocated struct renames that were tucked away in the
return string_list. Make sure all of these are deallocated when we
are done with them.
Before trying to apply directory renames to paths within the given
directories, we want to make sure that there aren't conflicts at the
file level either. If there aren't any, then get the new name from
any directory renames.
Signed-off-by: Elijah Newren
---
merge-recursive.c
Signed-off-by: Elijah Newren
---
merge-recursive.c | 26 +++---
t/t6043-merge-rename-directories.sh | 8
2 files changed, 27 insertions(+), 7 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index
Previously, if !o->detect_rename then get_renames() would return an
empty string_list, and then process_renames() would have nothing to
iterate over. It seems more straightforward to simply avoid calling
either function in that case.
Signed-off-by: Elijah Newren
---
I haven't tested the non Windows paths but the patch looks reasonable.
This inspired me to get someone more familiar with perl (thanks Johannes)
to revisit this code for the Windows side as well. The logic for
determining the git worktree when running on Windows is more complex
than necessary.
Phillip Wood writes:
> Here's the summary from the previous version
> These patches teach the sequencer to create commits without forking
> git commit when the commit message does not need to be edited. This
> speeds up cherry picking 10 commits by 26% and picking 10
Thanks for the patch. Some comments below...
On Fri, Nov 10, 2017 at 11:32 AM, Robert P. J. Day
wrote:
> Tweak a number of files to mention "view" as an alternative to
> "visualize":
You probably want to end this sentence with a period, not a colon.
>
Christian Couder writes:
> There are only a few small changes compared to v2:
Please go incremental as v2 is already in 'next', and small changes
are easier to reiew and understand when given as follow-up "polish
this minor glitch in the initial effort" patches.
On Fri, 10 Nov 2017, Eric Sunshine wrote:
> Thanks for the patch. Some comments below...
>
> On Fri, Nov 10, 2017 at 11:32 AM, Robert P. J. Day
> wrote:
> > Tweak a number of files to mention "view" as an alternative to
> > "visualize":
>
> You probably want to end this
1 - 100 of 129 matches
Mail list logo