Johannes Schindelin writes:
> Technically, it is not a write-up, and I never meant it to be that. I
> intended this document to help me remember what had been discussed, and I
> doubt it is useful at all to anybody who has not been there.
>
> I abused the Git mailing list to share that link, what
René Scharfe writes:
> Am 10.02.2017 um 23:24 schrieb Junio C Hamano:
>> * vn/xdiff-func-context (2017-01-15) 1 commit
>> - xdiff -W: relax end-of-file function detection
>>
>> "git diff -W" has been taught to handle the case where a new
>> function is added at the end of the file better.
>>
>
Nick Desaulniers writes:
> For the dangers related to fuzzing, is there more info? I found
> and old post on this from Linus calling fuzzing dangerous but
> from what I could tell about my patch that wouldn't apply
> without fuzzing, the only difference in bad hunks was
> whitespace that had div
Siddharth Kannan writes:
> @@ -2234,11 +2235,18 @@ int setup_revisions(int argc, const char **argv,
> struct rev_info *revs, struct s
> }
> if (opts < 0)
> exit(128);
> - continue;
> +
> +
Am 10.02.2017 um 23:24 schrieb Junio C Hamano:
* vn/xdiff-func-context (2017-01-15) 1 commit
- xdiff -W: relax end-of-file function detection
"git diff -W" has been taught to handle the case where a new
function is added at the end of the file better.
Will hold.
Discussion on an follow-up
It's not my call about the defaults, but users can be surprised by
such changes.
For the dangers related to fuzzing, is there more info? I found
and old post on this from Linus calling fuzzing dangerous but
from what I could tell about my patch that wouldn't apply
without fuzzing, the only differ
Junio C Hamano writes:
> Making "am -3" default may also scare users who are not exactly
> comfortable with reading "git diff" output during a conflicted merge
> and resolving a conflict, but other than that there shouldn't be any
> downside.
Another obvious downside is that there are those of u
On 02/10, René Scharfe wrote:
> prune_cache() first identifies those entries at the start of the sorted
> array that can be discarded. Then it moves the rest of the entries up.
> Last it identifies the unwanted trailing entries among the moved ones
> and cuts them off.
>
> Change the order: Ident
Johannes Schindelin writes:
> Teach preload-index to avoid lstat() calls for index-entries
> with skip-worktree bit set. This is a performance optimization.
> ...
> diff --git a/preload-index.c b/preload-index.c
> index c1fe3a3ef9c..70a4c808783 100644
> --- a/preload-index.c
> +++ b/preload-inde
Hello,
I'M Anessa female 25 years old single, I am contacting you because I will be
relocating to your country.
I will send you my photos soon as i hear from you and also tell you much about
my self.
Thanks.
Sincerely yours
Anessa.
Luke Diamand writes:
> On 9 February 2017 at 23:39, Junio C Hamano wrote:
>> Lars Schneider writes:
>>
>>> unfortunately, I missed to send this v2. I agree with Luke's review and
>>> I moved the re-encode of the path name to the `streamOneP4File` and
>>> `streamOneP4Deletion` explicitly.
>>>
>>
Jeff King writes:
> I dunno. I always use it, but I'm not sure if there are any downsides,
> aside from a little extra processing time. It does have some
> incompatibilities with other options. And I think it kicks in rename
> detection (but I might be mis-remembering another feature). That could
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
2.12-rc1 has been tagged and most
On 9 February 2017 at 23:39, Junio C Hamano wrote:
> Lars Schneider writes:
>
>> unfortunately, I missed to send this v2. I agree with Luke's review and
>> I moved the re-encode of the path name to the `streamOneP4File` and
>> `streamOneP4Deletion` explicitly.
>>
>> Discussion:
>> http://public-i
On Fri, Feb 10, 2017 at 01:37:12PM -0800, Stefan Beller wrote:
> > This is not exactly an answer to your question, but "git am -3" is often
> > a better solution than trying to fuzz patches. It assumes the patches
> > are Git patches (and record their origin blobs), and that you have that
> > blob
SZEDER Gábor writes:
> Care should be taken, though, because that prefix might contain
> 'for-each-ref' format specifiers as part of the left hand side of a
> '..' range or '...' symmetric difference notation or fetch/push/etc.
> refspec, e.g. 'git log "evil-%(refname)..br'. Doubling every '%'
>
On Fri, Feb 10, 2017 at 12:57 PM, Jeff King wrote:
> On Fri, Feb 10, 2017 at 11:20:59AM -0800, Nick Desaulniers wrote:
>
>> I frequently need to backport patches from the Linux kernel to older
>> kernel versions (Android Security). My usual workflow for simple
>> patches is:
>>
>> 1. try `git am
On Fri, Feb 10, 2017 at 09:23:15PM +, David Turner wrote:
> > Speaking of stderr, I wonder if this function should be calling
> > fflush(stderr) before looking at the fstat result. There could be contents
> > buffered
> > there that haven't been written out yet (not from child processes, but
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Friday, February 10, 2017 4:15 PM
> To: David Turner
> Cc: git@vger.kernel.org; pclo...@gmail.com; Junio C Hamano
>
> Subject: Re: [PATCH v5] gc: ignore old gc.log files
>
> > @@ -76,10 +78,30 @@ static void git_conf
A release candidate Git v2.12.0-rc1 is now available for testing
at the usual places. It is comprised of 455 non-merge commits
since v2.11.0, contributed by 65 people, 20 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following pu
A server can end up in a state where there are lots of unreferenced
loose objects (say, because many users are doing a bunch of rebasing
and pushing their rebased branches). Running "git gc --auto" in
this state would cause a gc.log file to be created, preventing
future auto gcs, causing pack file
Junio C Hamano writes:
> Jeff King writes:
>
>> On Mon, Feb 06, 2017 at 02:34:08PM -0800, Junio C Hamano wrote:
>>
>>> * sk/parse-remote-cleanup (2017-02-06) 1 commit
>>> (merged to 'next' on 2017-02-06 at 6ec89f72d5)
>>> + parse-remote: remove reference to unused op_prep
>>>
>>> Code clean
> @@ -76,10 +78,30 @@ static void git_config_date_string(const char *key, const
> char **output)
> static void process_log_file(void)
> {
> struct stat st;
> - if (!fstat(get_lock_file_fd(&log_lock), &st) && st.st_size)
> + if (fstat(get_lock_file_fd(&log_lock), &st)) {
> +
Jeff King writes:
> I dunno. This seems like a lot of manual scrambling to try to overcome
> unlikely errors just to make our stderr heard (and we'd still fail in
> some cases). It seems like:
>
> if (fstat(...)) {
> /* weird, fstat failed; try our best to mention it */
> error_errn
> -Original Message-
> From: Jeff King [mailto:p...@peff.net]
> Sent: Friday, February 10, 2017 3:09 PM
> To: David Turner
> Cc: git@vger.kernel.org; pclo...@gmail.com
> Subject: Re: [PATCH v3] gc: ignore old gc.log files
>
> On Fri, Feb 10, 2017 at 02:20:19PM -0500, David Turner wrote:
A server can end up in a state where there are lots of unreferenced
loose objects (say, because many users are doing a bunch of rebasing
and pushing their rebased branches). Running "git gc --auto" in
this state would cause a gc.log file to be created, preventing
future auto gcs, causing pack file
On Fri, Feb 10, 2017 at 11:20:59AM -0800, Nick Desaulniers wrote:
> I frequently need to backport patches from the Linux kernel to older
> kernel versions (Android Security). My usual workflow for simple
> patches is:
>
> 1. try `git am patch.txt`.
This is not exactly an answer to your question
On Fri, Feb 10, 2017 at 08:44:27PM +, David Turner wrote:
> > But maybe there are other systems emulating fstat() would trigger here.
> > I dunno.
>
> Yeah, I'm also not sure. On the other hand, if we're going to catch fstat
> errors anyway, we might as well do something sensible with this
Am 10.02.2017 um 15:20 schrieb Johannes Schindelin:
It is curious that only MacOSX builds trigger an error about this, both
GCC and Clang, but not Linux GCC nor Clang (see
https://travis-ci.org/git/git/jobs/200182819#L1152 for details):
builtin/bisect--helper.c:299:6: error: variable 'good_syn'
Johannes Schindelin writes:
> diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
> index 292a0720fcc..1d6e27a09d8 100755
> --- a/t/t1700-split-index.sh
> +++ b/t/t1700-split-index.sh
> @@ -200,4 +200,21 @@ EOF
> test_cmp expect actual
> '
>
> +test_expect_failure 'rev-parse --s
On Fri, Feb 10, 2017 at 02:20:19PM -0500, David Turner wrote:
> @@ -76,10 +77,47 @@ static void git_config_date_string(const char *key, const
> char **output)
> static void process_log_file(void)
> {
> struct stat st;
> - if (!fstat(get_lock_file_fd(&log_lock), &st) && st.st_size)
> +
prune_cache() first identifies those entries at the start of the sorted
array that can be discarded. Then it moves the rest of the entries up.
Last it identifies the unwanted trailing entries among the moved ones
and cuts them off.
Change the order: Identify both start *and* end of the range to k
Git should never get itself into a state where it refuses to do any
maintenance, just because at some point some piece of the maintenance
didn't make progress.
In this commit, git learns to ignore gc.log files which are older than
(by default) one day old. It also learns about a config, gc.logExp
Junio C Hamano writes:
> David Turner writes:
> ...
>> It might still happen that manual intervention is required
>> (e.g. because the repo is corrupt), but at the very least it won't be
>> because Git is too dumb to try again.
>
> Thanks, nicely explained.
Sorry but I spotted a typo "whre" and
The function prune_cache() relies on the fact that it is only called on
max_prefix and sneakily uses the matching global variable max_prefix_len
directly. Tighten its interface by passing both the string and its
length as parameters. While at it move the NULL check into the function
to collect al
Am 08.02.2017 um 07:22 schrieb Duy Nguyen:
On Wed, Feb 8, 2017 at 5:04 AM, René Scharfe wrote:
Pass the match member of the first pathspec item directly to
read_directory() instead of using common_prefix() to duplicate it first,
thus avoiding memory duplication, strlen(3) and free(3).
How abo
David Turner writes:
> It would be good if automatic gc were useful to server operators.
> A server can end up in a state whre there are
> lots of unreferenced loose objects (say, because many users are doing
> a bunch of rebasing and pushing their rebased branches). Before this
> patch, this sta
Nick Desaulniers writes:
> I frequently need to backport patches from the Linux kernel to older
> kernel versions (Android Security)
> ...
> My question is, why does `patch` seem to do a better job at applying
> patches than `git am`? It's almost like the `git` tools don't try to fuzz
> the
Michael Haggerty writes:
> This is v2 of the patch series, considerably reorganized but not that
> different codewise.
Thanks. The way the series loses "!*submodule and !submodule are
the same thing, sometimes" is easier to follow when presented in
this order, at least to me.
Michael Haggerty writes:
> There is no need to call read_ref_full() or resolve_gitlink_ref() from
> read_loose_refs(), because we already have a ref_store object in hand.
> So we can call resolve_ref_recursively() ourselves. Happily, this
> unifies the code for the submodule vs. non-submodule cas
I frequently need to backport patches from the Linux kernel to older
kernel versions (Android Security). My usual workflow for simple
patches is:
1. try `git am patch.txt`.
2. if that fails try `git apply -v patch.txt` then add commit message
manually.
3. if that fails try `patch -p1 < patch.txt`
Git should never get itself into a state where it refuses to do any
maintenance, just because at some point some piece of the maintenance
didn't make progress.
In this commit, git learns to ignore gc.log files which are older than
(by default) one day old. It also learns about a config, gc.logExp
Michael Haggerty writes:
> This avoids the need to add forward declarations in the next step.
>
> Signed-off-by: Michael Haggerty
> ---
> refs.c | 64
> 1 file changed, 32 insertions(+), 32 deletions(-)
Makes sense, but the patch
From: "Johannes Schindelin"
Hi Junio,
On Thu, 9 Feb 2017, Junio C Hamano wrote:
Johannes Schindelin writes:
> Almost. While I fixed the performance issues as well as the design
> allowed, I happened to "fix" the problem where an incomplete prefix
> match could be favored over an exact match
Johannes Schindelin writes:
> Johannes Schindelin (1):
> rev-parse: fix several options when running in a subdirectory
>
> Michael Rappazzo (1):
> rev-parse tests: add tests executed from a subdirectory
>
> builtin/rev-parse.c | 15 +++
> t/t1500-rev-parse.sh | 28 ++
Johannes Schindelin writes:
> diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
> index ff13e59e1db..84af2802f6f 100644
> --- a/builtin/rev-parse.c
> +++ b/builtin/rev-parse.c
> @@ -545,6 +545,7 @@ int cmd_rev_parse(int argc, const char **argv, const char
> *prefix)
> unsigned int fla
This patch introduces "-" as a method to refer to a revision, and adds tests to
test that git-log works with this shorthand.
This change will touch the following commands (through
revision.c:setup_revisions):
* builtin/blame.c
* builtin/diff.c
* builtin/diff-files.c
* builtin/diff-index.c
* built
setup_revisions used to consider any argument starting with "-" to be either a
valid option or nothing at all. This patch will teach it to check if the
argument is a revision before declaring that it is nothing at all.
Before this patch, handle_revision_arg was not called for arguments starting
wi
Thanks a lot, Matthieu, for your comments on an earlier version of this
patch! [1]
After the discussion there, I have considered the changes that have been made
and I broke them into two separate commits.
I have included the list of commands that are touched by this patch series in
the second co
Johannes Schindelin writes:
> From: Michael Rappazzo
>
> t2027-worktree-list has an incorrect expectation for --git-common-dir
> which has been adjusted and marked to expect failure.
>
> Some of the tests added have been marked to expect failure. These
> demonstrate a problem with the way that
On Thu, Feb 9, 2017 at 5:56 PM, Jonathan Nieder wrote:
> Private reply because using HTML mail on phone:
So I presume putting it back on the list is fine.
> Does this need to be a remote helper capability?
No, as all other capabilities of the git-protocol are mapped 1:1 to
the transport helper
Matt McCutchen writes:
> Currently "git fetch REMOTE SHA1" silently exits 1 if the server doesn't
> allow requests for unadvertised objects by sha1. Change it to print a
> meaningful error message.
>
> Signed-off-by: Matt McCutchen
> ---
>
> The fetch code looks unbelievably complicated to me a
Am 09.02.2017 um 01:10 schrieb Jack Adrian Zappa:
where it has grabbed a line at 126 and is using that for the hunk header.
When I say that, I mean that it is using that line for *every* hunk
header, for every change, regardless if it has passed a hunk head that
it should have matched.
Stran
Currently "git fetch REMOTE SHA1" silently exits 1 if the server doesn't
allow requests for unadvertised objects by sha1. Change it to print a
meaningful error message.
Signed-off-by: Matt McCutchen
---
The fetch code looks unbelievably complicated to me and I don't understand all
the cases tha
On Fri, Feb 10, 2017 at 7:56 AM, Jeff King wrote:
> On Fri, Feb 10, 2017 at 12:16:10PM +0100, Michael Haggerty wrote:
>
>> This is v2 of the patch series, considerably reorganized but not that
>> different codewise. Thanks to Stefan, Junio, and Peff for their
>> feedback about v1 [1]. I think I ha
On Fri, Feb 10, 2017 at 04:49:02PM +0100, Johannes Schindelin wrote:
> > I think this is only half the story. A heavy-sha1 workload is faster,
> > which is good. But one of the original reasons to prefer blk-sha1 (at
> > least on Linux) is that resolving libcrypto.so symbols takes a
> > non-trivia
Hi Junio,
On Thu, 9 Feb 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > I just started typing stuff up in a Google Doc, and made it editable to
> > everyone, feel free to help and add things:
> >
> > https://docs.google.com/document/d/1KDoSn4btbK5VJCVld32he29U0pUeFGhpFxyx9ZJDDB0
Hi Arif,
On Wed, 24 Aug 2016, Johannes Schindelin wrote:
> On Tue, 23 Aug 2016, Arif Khokar wrote:
>
> > On 08/20/2016 03:57 PM, Jakub Narębski wrote:
> >
> > > But perhaps the problem is current lack of tooling in the opposite
> > > direction, namely getting patches from mailing list and apply
Hey Johannes,
On Fri, Feb 10, 2017 at 7:50 PM, Johannes Schindelin
wrote:
>
> It is curious that only MacOSX builds trigger an error about this, both
> GCC and Clang, but not Linux GCC nor Clang (see
> https://travis-ci.org/git/git/jobs/200182819#L1152 for details):
>
> builtin/bisect--helper.c:2
On Fri, Feb 10, 2017 at 12:16:10PM +0100, Michael Haggerty wrote:
> This is v2 of the patch series, considerably reorganized but not that
> different codewise. Thanks to Stefan, Junio, and Peff for their
> feedback about v1 [1]. I think I have addressed all of your comments.
>
> Changes since v1:
Hi Junio,
On Thu, 9 Feb 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > Almost. While I fixed the performance issues as well as the design
> > allowed, I happened to "fix" the problem where an incomplete prefix
> > match could be favored over an exact match.
>
> Hmph. Would it
From: Michael Rappazzo
t2027-worktree-list has an incorrect expectation for --git-common-dir
which has been adjusted and marked to expect failure.
Some of the tests added have been marked to expect failure. These
demonstrate a problem with the way that some options to git rev-parse
behave when
Hi Peff,
On Fri, 10 Feb 2017, Jeff King wrote:
> On Thu, Feb 09, 2017 at 11:27:49PM +0100, Johannes Schindelin wrote:
>
> > From: Jeff Hostetler
> >
> > Use OpenSSL's SHA-1 routines rather than builtin block-sha1 routines.
> > This improves performance on SHA1 operations on Intel processors.
>
The bug that bit me (hard!) and that triggered not only a long series of
curses but also my writing a patch and sending it to the list was that
`git rev-parse --git-path HEAD` would give *incorrect* output when run
in a subdirectory of a regular checkout, but *correct* output when run
in a subdirec
In addition to making git_path() aware of certain file names that need
to be handled differently e.g. when running in worktrees, the commit
557bd833bb (git_path(): be aware of file relocation in $GIT_DIR,
2014-11-30) also snuck in a new option for `git rev-parse`:
`--git-path`.
On the face of it,
Hi Mike,
On Thu, 9 Feb 2017, Mike Rappazzo wrote:
> On Thu, Feb 9, 2017 at 5:54 PM, Junio C Hamano wrote:
> >
> > That leaves what the right single-step behaviour change should be. As
> > I recall Duy said something about --common-dir and other things Mike's
> > earlier change also covered, I'd
You have 1 new Schedule message
Use the link below:
http://sportscouts.co.uk/i.php
Blackboard | IT Services
From: Jeff Hostetler
Teach preload-index to avoid lstat() calls for index-entries
with skip-worktree bit set. This is a performance optimization.
During a sparse-checkout, the skip-worktree bit is set on items
that were not populated and therefore are not present in the
worktree. The per-threa
It is curious that only MacOSX builds trigger an error about this, both
GCC and Clang, but not Linux GCC nor Clang (see
https://travis-ci.org/git/git/jobs/200182819#L1152 for details):
builtin/bisect--helper.c:299:6: error: variable 'good_syn' is used
uninitialized whenever 'if' co
Hi Philip,
On Thu, 9 Feb 2017, Philip Oakley wrote:
> From: "Johannes Schindelin"
> Sent: Thursday, February 09, 2017 8:55 PM
>
> > The rebase--helper code (specifically, the patch moving autosquash
> > logic into it: https://github.com/dscho/git/commit/7d0831637f) tries
> > to match exact oneli
Dear Sir/Madam.
Assalamu`Alaikum.
I am Dr mohammad ouattara, I have ($10.6 Million us dollars) to transfer into
your account,
I will send you more details about this deal and the procedures to follow when
I receive a positive response from you,
Have a great day,
Dr mohammad ouattara.
Hi team,
at the GitMerge conference, I heard a couple of times "I do not bother
reporting bugs in `pu` or `next` on MacOSX and Windows anymore, only Linux
seems to be truly supported" or some variation thereof.
This is a strong indicator that we have some room for improvement here.
Active reader
Hello,
I am very pleased to informing you of this development. I found an
active and professional bank that can handle the financial transaction
on our behalf, and I have suggested you as the beneficiary to the gold
and diamond deposits, mining concession and company ownership because
I found out
Aside from scaling better, this means that the submodule name needn't be
stored in the ref_store instance anymore (which will be changed in a
moment). This, in turn, will help loosen the strict 1:1 relationship
between ref_stores and submodules.
Signed-off-by: Michael Haggerty
---
refs.c
There is no need to call read_ref_full() or resolve_gitlink_ref() from
read_loose_refs(), because we already have a ref_store object in hand.
So we can call resolve_ref_recursively() ourselves. Happily, this
unifies the code for the submodule vs. non-submodule cases.
This requires resolve_ref_recu
This avoids the need to add forward declarations in the next step.
Signed-off-by: Michael Haggerty
---
refs.c | 64
1 file changed, 32 insertions(+), 32 deletions(-)
diff --git a/refs.c b/refs.c
index 9bd0bc1..707092f 100644
--- a
Move the responsibility for registering the ref_store for a submodule
from base_ref_store_init() to a new function, register_ref_store(). Call
the latter from ref_store_init().
Signed-off-by: Michael Haggerty
---
refs.c | 43 +--
1 file changed, 29 inserti
Push the submodule attribute down from ref_store to files_ref_store.
This is another step towards loosening the 1:1 connection between
ref_stores and submodules.
Signed-off-by: Michael Haggerty
---
refs.c | 11 --
refs/files-backend.c | 61 ++
The only external entry point to the ref_store lookup functions is
get_ref_store(), which ensures that submodule == "" is passed along as
NULL. So ref_store_init() and lookup_ref_store() don't have to handle
submodule being specified as the empty string.
Signed-off-by: Michael Haggerty
---
refs.
This is another step towards weakening the 1:1 relationship between
ref_stores and submodules.
Signed-off-by: Michael Haggerty
---
refs.c | 3 +--
refs/files-backend.c | 2 +-
refs/refs-internal.h | 7 +++
3 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/refs.c b/
The old practice of storing the empty string in this member for the main
repository was a holdover from before 00eebe3 (refs: create a base class
"ref_store" for files_ref_store, 2016-09-04), when the submodule was
stored in a flex array at the end of `struct files_ref_store`. Storing
NULL for this
The following functions currently don't need to be exposed:
* ref_store_init()
* lookup_ref_store()
That might change in the future, but for now make them private.
Signed-off-by: Michael Haggerty
---
refs.c | 19 +--
refs/refs-internal.h | 19 ---
This is v2 of the patch series, considerably reorganized but not that
different codewise. Thanks to Stefan, Junio, and Peff for their
feedback about v1 [1]. I think I have addressed all of your comments.
Changes since v1:
* Rebase from `master` onto `maint` (to match Junio).
* Reorder some commi
On 02/10/2017 01:40 AM, Jeff King wrote:
> On Thu, Feb 09, 2017 at 10:23:35PM +0100, Michael Haggerty wrote:
>
So push the submodule attribute down to the `files_ref_store` class
(but continue to let the `ref_store`s be looked up by submodule).
>>>
>>> I'm not sure I understand all of th
On 02/09/2017 09:34 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>> [...]
>> +static int submodule_hash_cmp(const void *entry, const void *entry_or_key,
>> + const void *keydata)
>> +{
>> +const struct submodule_hash_entry *e1 = entry, *e2 = entry_or_key;
>> +
Dear Friend.
I Hoped that you will not expose or betray this trust and confident that I am
about to repose on you for the mutual benefit of our families.I need your
urgent assistance in transferring the sum of $5 million U.S dollars into your
account. The money has been dormant for years in ou
David Turner writes:
> The intent of automatic gc is to have a git repository be relatively
> low-maintenance from a server-operator perspective.
This is diametrically opposite from how I recall the auto-gc came
about in Sep 2007. The primary purpose was to help desktop clients
that never run
I am Mr.Bong Phang, Togo (West Africa) I want to seek your partnership
and mutual understanding on a favorable transaction £ 12.5 million,
which will benefit both of us.
Greetings,
Barrister Bong Phang
88 matches
Mail list logo
