Jsem Lucas Brown, jsem financní dustojník, dávám pujcky jednotlivcum a firme
pro obchodní a osobní úcely, kontaktujte me, pokud potrebujete jakýkoli druh
pujcky. Poskytuji pujcky široké verejnosti s úrokovou sazbou 2%.
Sehr geehrte Damen und Herren,
Sie brauchen Geld? Sie sind auf der suche nach einem Darlehnen? Seriös und
unkompliziert?
Dann sind Sie hier bei uns genau richtig.
Durch unsere jahrelange Erfahrung und kompetente Beratung sind wir Europaweit
tätig.
Wir bieten jedem ein GÜNSTIGES Darlehnen zu TOP
Ben Peart writes:
> OK. I'll call this new extension "EOIE" ("end of index
> entries"). Other than the standard header/footer, it will only contain
> a 32 bit offset to the beginning of the extension entries. I'll
> always write out that extension unless you would prefer it be behind a
> settin
Johannes Schindelin writes:
I notice that I left a few things unanswered even after giving
answers to the most important part (i.e. "what is this for was
sold incorrectly"). Here are the leftover bits.
>> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
>> index 89cc
On 11/14/2017 8:12 PM, Junio C Hamano wrote:
Ben Peart writes:
I have no thoughts or plans for changes in the future of IEOT (which I
plan to rename ITOC). At this point in time, I can't even imagine
what else we'd want as the index only contains cache entries, ...
Yeah, but the thing is
On Tue, 14 Nov 2017 16:30:43 -0800
Stefan Beller wrote:
> The walking is performed in reverse order to show the introduction of a
> blob rather than its last occurrence.
The code as implemented here does not do this - it instead shows the last
occurrence.
> NAME
>
> -git-describe - Descr
On Tue, 14 Nov 2017 16:30:42 -0800
Stefan Beller wrote:
> In the next patch we'll learn how to describe more than just commits,
> so factor out describing commits into its own function. That will make
> the next patches easy as we still need to describe a commit as part of
> describing blobs.
>
On Tue, 14 Nov 2017 16:30:41 -0800
Stefan Beller wrote:
> For debuggers aid we'd want to print debug statements early, so
> introduce a new line in the debug output that describes the whole
> function, and then change the next debug output to describe why we
> need to search. Conveniently drop th
On Tue, 14 Nov 2017 16:30:39 -0800
Stefan Beller wrote:
> The change in list-objects.c is rather minimal as we'll be re-using
> the infrastructure put in place of the revision walking machinery. For
> example one could expect that add_pending_tree is not called, but rather
> commit->tree is direc
Elijah Newren writes:
> Eek! My apologies. I will go through and fix them up. I see no
> reference to checkpatch.pl in git, but a google search shows there's
> one in the linux source tree. Is that were I get it from, or is there
> a different one?
> Also, would you like me to make a separ
Ben Peart writes:
> I have no thoughts or plans for changes in the future of IEOT (which I
> plan to rename ITOC). At this point in time, I can't even imagine
> what else we'd want as the index only contains cache entries, ...
Yeah, but the thing is that this is open source, and the imagination
In the next patch we'll learn how to describe more than just commits,
so factor out describing commits into its own function. That will make
the next patches easy as we still need to describe a commit as part of
describing blobs.
While factoring out the functionality to describe_commit, make sure
Sometimes users are given a hash of an object and they want to
identify it further (ex.: Use verify-pack to find the largest blobs,
but what are these? or [1])
When describing commits, we try to anchor them to tags or refs, as these
are conceptually on a higher level than the commit. And if there
For debuggers aid we'd want to print debug statements early, so
introduce a new line in the debug output that describes the whole
function, and then change the next debug output to describe why we
need to search. Conveniently drop the arg from the second line;
which will be useful in a follow up co
With traverse_trees_and_blobs factored out of the main traverse function,
the next patch can introduce an in-order revision walking with ease.
In the next patch we'll call `traverse_trees_and_blobs` from within the
loop walking the commits, such that we'll have one invocation of that
function per
The functionality to list tree objects in the order they were seen
while traversing the commits will be used in one of the next commits,
where we teach `git describe` to describe not only commits, but blobs, too.
The change in list-objects.c is rather minimal as we'll be re-using
the infrastructur
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
t/t6120-describe.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 1c0e8659d9..c8b7ed82d9 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
@@ -304,7 +304,
The function `describe` has already a variable named `oid` declared at
the beginning of the function for an object id. Do not shadow that
variable with a pointer to an object id.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
builtin/describe.c | 8
1 file changed, 4 i
* omitted the check for options, none of them made sense.
* use of --reverse
* an additional test asked for by Jonathan
previous discussion
https://public-inbox.org/git/20171102194148.2124-1-sbel...@google.com/
interdiff to current queued patches below.
Thanks,
Stefan
Stefan Beller (7):
t6120:
On Tue, Nov 14, 2017 at 10:39:31AM -0500, Marc Branchaud wrote:
> >rm -rf .git/logs
>
> Unfortunately, removing the logs directory does not fix "git gc". So I
> restored it.
>
> However I did find all of the bad SHAs in the HEAD logs of four of my
> worktrees.
Ah, right. There are more log
On Sun, Nov 12, 2017 at 5:33 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Sometimes users are given a hash of an object and they want to
>> identify it further (ex.: Use verify-pack to find the largest blobs,
>> but what are these? or [1])
>
> Thanks for finishing the topic you started.
On Tue, Nov 14, 2017 at 1:11 PM, Elijah Newren wrote:
> On Mon, Nov 13, 2017 at 4:42 PM, Stefan Beller wrote:
>> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
>
>> "In my opinion" ... sounds like commit message?
>
> Sure, I can move it there.
>
>
>>> +# Testcase 7a, rename-dir vs. renam
On Tue, Nov 14, 2017 at 12:33 PM, Stefan Beller wrote:
> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
>> +# Possible Resolutions:
>> +# Previous git: y/{a,b,f}, z/{c,d}, x/e
>> +# Expected: y/{a,b,e,f}, z/{c,d}
>> +# Preferred:y/{a,b,e}, z/{c,d,f}
>
> it might be tr
On Tue, 14 Nov 2017 12:40:03 -0800
Stefan Beller wrote:
> Thanks for the review!
>
> This series was written with the mindset, that a user would only ever
> want to describe bad blobs. (bad in terms of file size, unwanted content, etc)
>
> With the --reverse you only see the *first* introductio
On Mon, Nov 13, 2017 at 4:42 PM, Stefan Beller wrote:
> On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> "In my opinion" ... sounds like commit message?
Sure, I can move it there.
>> +# Testcase 7a, rename-dir vs. rename-dir (NOT split evenly) PLUS
>> add-other-file
>> +# Commit A:
On Tue, Nov 14, 2017 at 10:48 AM, Stefan Beller wrote:
> test_expect_success 'unrelated file/submodule conflict is ignored' '
> (
> cd a_repo &&
> git checkout with_file^0 &&
> git cherry-pick with_sub^0
This makes no sense, yet. Sorry about the noise.
I think you
On Tue, Nov 14, 2017 at 12:02 PM, Jonathan Tan wrote:
> On Thu, 2 Nov 2017 12:41:48 -0700
> Stefan Beller wrote:
>
>> Sometimes users are given a hash of an object and they want to
>> identify it further (ex.: Use verify-pack to find the largest blobs,
>> but what are these? or [1])
>>
>> "This
On Fri, Nov 10, 2017 at 11:05 AM, Elijah Newren wrote:
> 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-dire
On Tue, Nov 14, 2017 at 3:14 PM, Eric Sunshine wrote:
> For my own edification...
> [...]
> git worktree add ../topic
>
> * Correctly errors out, refusing to create a new branch named "topic",
> if "topic" is already a branch.
By the way, there's an additional DWIM that could be done here instead
On Tue, Nov 14, 2017 at 3:45 AM, Thomas Gummerer wrote:
> On 11/13, Junio C Hamano wrote:
>> If so, as long as the new DWIM kicks in ONLY when "topic" does not
>> exist, I suspect that there is no backward compatibility worries.
>> The command line
>>
>> $ git worktree add ../a-new-worktree to
On Tue, 14 Nov 2017, Eric Sunshine wrote:
> On Tue, Nov 14, 2017 at 3:43 AM, Robert P. J. Day
> wrote:
> > from "man git-worktree", there seem to be some inaccuracies in the
> > SYNOPSIS regarding the "add" subcommand:
> >
> > git worktree add \
> > [-f] [--detach] [--checkout] [--lock] [-
On Thu, 2 Nov 2017 12:41:48 -0700
Stefan Beller wrote:
> Sometimes users are given a hash of an object and they want to
> identify it further (ex.: Use verify-pack to find the largest blobs,
> but what are these? or [1])
>
> "This is an interesting endeavor, because describing things is hard."
On Tue, Nov 14, 2017 at 11:55 AM, Jonathan Tan wrote:
> On Thu, 2 Nov 2017 12:41:46 -0700
> Stefan Beller wrote:
>
>> For debuggers aid we'd want to print debug statements early, so
>> introduce a new line in the debug output that describes the whole
>> function, and then change the next debug o
On Thu, 2 Nov 2017 12:41:46 -0700
Stefan Beller wrote:
> For debuggers aid we'd want to print debug statements early, so
> introduce a new line in the debug output that describes the whole
> function, and then change the next debug output to describe why we
> need to search. Conveniently drop th
On Thu, 2 Nov 2017 12:41:44 -0700
Stefan Beller wrote:
> @@ -239,6 +239,8 @@ void traverse_commit_list(struct rev_info *revs,
> if (commit->tree)
> add_pending_tree(revs, commit->tree);
> show_commit(commit, data);
> + if (revs->tree_
Hi Shawn,
Shawn Landden wrote:
I think this is preferrable to bringing the assembly routines into
the git code-base, as a way of getting access to these high-performance
routines to a git available in Debian, Ubuntu, or Fedora (which
all use BLK_SHA1=1 due to GPLv2 + OpenSSL license considerat
Please, I am aware that this is certainly not a conventional approach to
communicating with a stranger or establish a relationship of trust,
but you will understand the need for my action. I am an independent
non-director of Hang Seng Bank Hong Kong. I have important matter to
talk with you about
+cc Ефимов Василий who reported the issue at
https://public-inbox.org/git/743acc29-85bb-3773-b6a0-68d4a0b8f...@ispras.ru/
On Tue, Nov 14, 2017 at 9:31 AM, Elijah Newren wrote:
> The code for a newly added path assumed that the path was a normal file,
> and thus checked for there being a director
On Mon, Nov 13, 2017 at 9:30 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> + entry = dir_rename_find_entry(dir_renames, old_dir);
>> + if (!entry) {
>> + entry = xcalloc(1, sizeof(struct dir_rename_entry));
>> + hashmap_entr
--
Diese E-Mail fordert Sie strikt auf, sich für eine große Investition mit
mir zusammenzutun, um weitere Informationen zu erhalten.
Mit freundlichen Grüßen,
Khvostova Zhanna
On Tue, Nov 14, 2017 at 3:43 AM, Robert P. J. Day wrote:
> from "man git-worktree", there seem to be some inaccuracies in the
> SYNOPSIS regarding the "add" subcommand:
>
> git worktree add \
> [-f] [--detach] [--checkout] [--lock] [-b ] []
>
> first, there's no mention of "-B" in that SY
On Mon, Nov 13, 2017 at 9:14 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Elijah Newren writes:
>>
>>> +struct rename_info {
>>> +struct string_list *head_renames;
>>> +struct string_list *merge_renames;
>>> +};
>>
>> This type is added in order to allow the caller and the hel
Thanks for your reply!
On Tue, Nov 14, 2017 at 9:17 AM, Elijah Newren wrote:
> On Mon, Nov 13, 2017 at 3:46 PM, Stefan Beller wrote:
>> On Mon, Nov 13, 2017 at 3:39 PM, Elijah Newren wrote:
>>> On Mon, Nov 13, 2017 at 2:12 PM, Stefan Beller wrote:
I wanted to debug a very similar issue to
On Mon, Nov 13, 2017 at 8:46 PM, Junio C Hamano wrote:
> It took me a while to figure out that you are basing this on top of
> a slightly older tip of 'master'. When rebasing on, or merging to,
> a newer codebase
Sorry about that. Yes, I worked on the series over time and rebased a
couple time
The code for a newly added path assumed that the path was a normal file,
and thus checked for there being a directory still being in the way of
the file. Note that since unpack_trees() does path-in-the-way checks
already, the only way for there to be a directory in the way at this
point in the cod
On Mon, Nov 13, 2017 at 3:46 PM, Stefan Beller wrote:
> On Mon, Nov 13, 2017 at 3:39 PM, Elijah Newren wrote:
>> On Mon, Nov 13, 2017 at 2:12 PM, Stefan Beller wrote:
>>> I wanted to debug a very similar issue today just after reviewing this
>>> series, see
>>> https://public-inbox.org/git/743ac
(Back to the beginning)
You have a file ApplicationManifest.xml
It is encoded in UTF-16 (and has CRLF)
You convert it into UTF-8
The file has still CRLF (in the worktree)
Now you add it and make a commit.
Under both Linux and Windows you have "text=auto".
I assume that you have efficiently core
On Tue, Nov 14, 2017 at 10:39 AM, Marc Branchaud wrote:
> I'm willing to chalk this up to bugs in the early worktree code, unless one
> of the CC'd worktree developers thinks otherwise.
>
> An explicit "git worktree delete" command would be nice for manually
> cleaning things up. It's easy to jus
On 2017-11-14 17:13, Ashish Negi wrote:
> Running the command gives me :
>
> git ls-files --eol file_name
> i/-text w/-text attr/text=auto file_name
>
That is strange to me:
According to that, Git would treat the file as text=auto.
And the content is "not next", so there is
All other error messages from notes use stderr. Do the same when
alerting users of an unresolved notes merge.
Fix the output redirection in t3310 and t3320 as well. Previously, the
tests directed output to a file, but stderr was either not captured or
not sent to the file due to the order of the
After changing the encoding of file to utf-8, same command gives:
git ls-files --eol file_name
i/lfw/crlf attr/text=auto ApplicationManifest.xml
On Tue, Nov 14, 2017 at 9:43 PM, Ashish Negi wrote:
> Running the command gives me :
>
> git ls-files --eol file_name
> i/-te
Running the command gives me :
git ls-files --eol file_name
i/-text w/-text attr/text=auto file_name
On 2017-11-14 01:21 AM, Christian Couder wrote:
On Tue, Nov 14, 2017 at 3:04 AM, wrote:
From: Haaris
Description:
This patch adds a new option to the config command.
Uses flag --expiry-date as a data-type to covert date-strings to
timestamps when reading from config files (GET).
This flag i
On 11/14/2017 10:04 AM, Junio C Hamano wrote:
Ben Peart writes:
How about I add the logic to write out a special extension right
before the SHA1 that contains an offset to the beginning of the
extensions section. I will also add the logic in do_read_index() to
search for and load this speci
(It turned out that this problem is related to worktrees. CCing some
worktree folks.)
On 2017-11-14 12:53 AM, Jeff King wrote:
On Mon, Nov 13, 2017 at 04:13:19PM -0500, Marc Branchaud wrote:
Various incantations of "git show ... 9c355a7726e31" only fail with the same
error, so I can't determ
> If it's a small range of gnupg versions which fail badly when the GNUPGHOME
> dir is removed, then there's far less reason for git to do much more than
> make an effort to kill the agent.
>
Yeah. FWIW, it may be reasonable to consider dropping the patch once we are
certain distros don't ship th
On 2017-11-14 13:31, Ashish Negi wrote:
> Hello
>
> I have a cross platform project. I have a utf-16 file in it.
> I changed its encoding to urf-8 and committed. When i pulled the file
> in Linux, it shows that file is modified. This means that the commit
> which changed the encoding does not conv
Kaartic Sivaraam writes:
> I should have been a little more clear with the numbering, sorry. The
> correct prefix should have been as follows,
>
>* [PATCH v2 1/2] --> [PATCH v2 3/3]
>
>* [PATCH v2 1/2] --> [PATCH v2 4/3]
>
> Sorry for the inconvenience.
I assume that the second one above
Ben Peart writes:
> How about I add the logic to write out a special extension right
> before the SHA1 that contains an offset to the beginning of the
> extensions section. I will also add the logic in do_read_index() to
> search for and load this special extension if it exists.
>
> This will pr
while writing up a cheat sheet with a visual layout of .git for my
students, i compared "git help repository-layout" to my git clone of
the kernel source tree, and noted the following things are not
mentioned in the repo layout help page -- i have no idea how complete
that page is supposed to be
Nicolas Morey-Chaisemartin writes:
>> So there probably needs a convention meant to be followed by human
>> users when writing cover letters, so a mechanical process can tell
>> which part of the text is to be made into the merge commit without
>> understanding human languages.
>
> In the long te
Johan Herland writes:
>> Sounds like a good plan. If the message does move to stderr, there are also
>> a few tests in 3310 that need adjusted. They presume an error message from
>> `git notes merge`, but they only redirect stdout to the output file.
>>
>> While I was bored, I prepared a commit
On 11/13/2017 8:10 PM, Junio C Hamano wrote:
Ben Peart writes:
The proposed format for extensions (ie having both a header and a
footer with name and size) in the current patch already enables having
multiple extensions that can be parsed forward or backward. Any
extensions that would want
Le 14/11/2017 à 14:05, Junio C Hamano a écrit :
> Nicolas Morey-Chaisemartin writes:
>
>> The triple dash is so that the diffstat/shortlog as not seen as
>> part of the cover letter. As said in the cover letter for this
>> series, it kinda breaks legacy behaviour right now. It should
>> either
Nicolas Morey-Chaisemartin writes:
> The triple dash is so that the diffstat/shortlog as not seen as
> part of the cover letter. As said in the cover letter for this
> series, it kinda breaks legacy behaviour right now. It should
> either be printed only for cover-at-tip, or a new separator sho
Hello
I have a cross platform project. I have a utf-16 file in it.
I changed its encoding to urf-8 and committed. When i pulled the file
in Linux, it shows that file is modified. This means that the commit
which changed the encoding does not convert crlf to lf, when new
format is text based (utf-8
I should have been a little more clear with the numbering, sorry. The
correct prefix should have been as follows,
* [PATCH v2 1/2] --> [PATCH v2 3/3]
* [PATCH v2 1/2] --> [PATCH v2 4/3]
Sorry for the inconvenience.
---
Kaartic
The lower level code has been made to handle this case for the
sake of consistency. This has made this check redundant.
So, remove the redundant check.
Signed-off-by: Kaartic Sivaraam
---
builtin/branch.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
From: Junio C Hamano
strbuf_check_branch_ref() is the central place where many codepaths
see if a proposed name is suitable for the name of a branch. It was
designed to allow us to get stricter than the check_refname_format()
check used for refnames in general, and we already use it to reject
a
Greetings from Dr. mohammad ouattara.
Assalamu`Alaikum.
My Name is Dr. mohammad ouattara, I am a banker by profession. I'm from
Ouagadougou, Burkina Faso, West Africa. My reason for contacting you is to
transfer an abandoned $14.6M to your account.
The owner of this fund died since 2004 wit
Attention: Beneficiary,
Your long awaited part payment of $2.5.000.00Usd (TWO MILLION FIVE Hundred
Thousand United State Dollars) is ready for immediate release to you, and
it was electronically credited into an ATM Visa Card for easy delivery.
Your new Payment Reference No.- 6363836,
Password N
On Tue, 14 Nov 2017, Bryan Turner wrote:
> On Tue, Nov 14, 2017 at 1:18 AM, Robert P. J. Day
> wrote:
> >
> > just noticed something i was unaware of -- some git commands can't
> > be run if i'm in the .git directory, while others can. for example,
> > if i "cd .git", commands like this work j
On Tue, Nov 14, 2017 at 1:18 AM, Robert P. J. Day wrote:
>
> just noticed something i was unaware of -- some git commands can't
> be run if i'm in the .git directory, while others can. for example,
> if i "cd .git", commands like this work just fine:
>
> $ git show
> $ git branch
> $ git l
GNUTLS uses the same cryptograms SHA1 routines (Cryptograms)
by Andy Polyakov as OpenSSL, but with a license
that is acceptable for downstream packagers.
This is not the cleanest way to use the GNUTLS library,
as it is reallocating the context every time, and GNUTLS itsself
fudges an OpenSSL CTX
On Tue, Nov 14, 2017 at 6:15 AM, Todd Zullinger wrote:
> Junio C Hamano wrote:
>>
>> The message goes to the standard output stream since it was introduced in
>> 809f38c8 ("git notes merge: Manual conflict resolution, part 1/2",
>> 2010-11-09) and 6abb3655 ("git notes merge:
>> Manual conflict res
Le 14/11/2017 à 07:14, Junio C Hamano a écrit :
> Nicolas Morey-Chaisemartin writes:
>
>> -const char *body = "*** SUBJECT HERE ***\n\n*** BLURB HERE ***\n";
>> -const char *msg;
>> +const char *body = "*** SUBJECT HERE ***\n\n*** BLURB HERE ***\n\n";
> H.
The \n from fprintf(re
Signed-off-by: Robert P. J. Day
---
by god, i'm going to get a patch into the code base if it kills me.
diff --git a/t/t7409-submodule-detached-work-tree.sh
b/t/t7409-submodule-detached-work-tree.sh
index c20717181..fc018e363 100755
--- a/t/t7409-submodule-detached-work-tree.sh
+++ b/t/t740
just noticed something i was unaware of -- some git commands can't
be run if i'm in the .git directory, while others can. for example,
if i "cd .git", commands like this work just fine:
$ git show
$ git branch
$ git log
but others seem unwilling to determine the "working tree":
$ git
Le 14/11/2017 à 07:00, Junio C Hamano a écrit :
> Nicolas Morey-Chaisemartin writes:
>
>> if (!git_config_get_bool("commit.gpgsign", &gpgsign))
>> state->sign_commit = gpgsign ? "" : NULL;
>> +
>> }
> Please give at least a cursory proof-reading before sending things
> out.
>
Le 14/11/2017 à 06:47, Junio C Hamano a écrit :
> Nicolas Morey-Chaisemartin writes:
>
>> Extract the patch ID and series length from the [PATCH N/M]
>> prefix in the mail header
>>
>> Signed-off-by: Nicolas Morey-Chaisemartin
>> ---
>> mailinfo.c | 35 +++
>>
On Mon, 13 Nov 2017, Eric Sunshine wrote:
> On Mon, Nov 13, 2017 at 4:06 PM, Robert P. J. Day
> wrote:
... snip ...
> > how is this "expire time" measured? relative to what? i've
> > looked under .git/worktrees/, and i see a bunch of files
> > defining that worktree, but it's not clear how a
On 11/13, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > Factor the functions out, so they can be re-used from other places. In
> > particular these functions will be re-used in builtin/worktree.c to make
> > git worktree add dwim more.
> >
> > While there add a description to the functio
more annoying pedantry (but you're used to that by now, right?) ...
from "man git-worktree", there seem to be some inaccuracies in the
SYNOPSIS regarding the "add" subcommand:
git worktree add \
[-f] [--detach] [--checkout] [--lock] [-b ] []
first, there's no mention of "-B" in that S
On 11/13, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > I'm a bit torn about hiding his behind an additional flag in git
> > worktree add or not. I would like to have the feature without the
> > additional flag, but it might break some peoples expectations, so
> > dunno.
>
> Yeah, I agr
Diese E-Mail fordert Sie strikt auf, sich für eine große Investition mit
mir zusammenzutun, um weitere Informationen zu erhalten.
Mit freundlichen Grüßen,
Khvostova Zhanna
85 matches
Mail list logo
