On Sat, Jun 9, 2018 at 12:22 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Fri, Jun 08 2018, Johannes Sixt wrote:
>
> > Am 08.06.2018 um 18:00 schrieb Thomas Braun:
> >> I for my part would much rather prefer that to be a compile time
> >> option so that I don't need to check on every git update on
On Fri, Jun 08 2018, Jonathan Nieder wrote:
> Separate from that legal context, though, I think it's an interesting
> feature request. I don't think it goes far enough: I would like a way
> to erase arbitrary information from the history in a repository. For
> example, if I accidentally check
On Fri, Jun 08 2018, Peter Backes wrote:
> On Fri, Jun 08, 2018 at 10:13:20AM +0200, Ævar Arnfjörð Bjarmason wrote:
>> Can you walk us through how anyone would be expected to fork (as create
>> a new project, not the github-ism) existing projects under such a
>> regiment?
>
> I don't see your
Add tests showing how "git-blame" behaves. As noted in an earlier
change there's a behavior difference between core.abbrev=40 and
--abbrev=40.
Let's also assert that neither way of changing the abbreviation length
modifies the porcelain output.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Operations that need to abbreviate a lot of SHA-1s such as 'git log
--oneline' experience degraded performance when traversing a lot of
packs. See [1] and [2] for some relevant performance numbers.
One way to address this is something like the MIDX to make looking up
the SHA-1s cheaper.
This
In ac53fe8601 ("sha1_name: convert uses of 40 to GIT_SHA1_HEXSZ",
2017-07-13) the code this is validating user input for in
find_unique_abbrev_r() was converted to GIT_SHA1_HEXSZ, but the
corresponding validation codepath wasn't change. Let's do that.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Hi,
Peter Backes wrote:
> I'd like to ask whether anyone has best practices for achieving GDPR
> compliance for git repos? The GDPR will come into effect in the EU next
> month.
This is a reasonable question to ask other Git users on this list to
share ideas, so thanks for asking it.
> In
The "log" family of commands does its own parsing for --abbrev in
revision.c, so having dedicated tests for it makes sense.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t0014-abbrev.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t0014-abbrev.sh b/t/t0014-abbrev.sh
index
Since 84393bfd73 ("blame: add --abbrev command line option and make it
honor core.abbrev", 2011-04-06) first released with v1.7.6 "git blame"
has supported both core.abbrev and --abbrev to change the abbreviation
length.
Initially output wouldn't alter the abbreviation length to account for
the
Adjust this code that'll be modified in a subsequent change to have
more than one line per branch to use braces per the CodingGuidelines,
this makes the later change easier to understand.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
diff.c | 5 +++--
revision.c | 5 +++--
2 files changed, 6
In a later change I mean to make values like -1 and +1 mean something
different, but right now they're implicitly parsed. Let's test for the
current behavior before changing it.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t0014-abbrev.sh | 131 --
1
The only thing out of the ordinary with git-describe is the --abbrev=0
special-case.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t0014-abbrev.sh | 25 +
1 file changed, 25 insertions(+)
diff --git a/t/t0014-abbrev.sh b/t/t0014-abbrev.sh
index d8b060d922..645bcca1d1
In a later change I'm adding stress testing of the commit abbreviation
as it relates to git-blame and others, and initially thought that the
inability to extract full SHA-1s from the non-"--porcelain" output was
a bug.
In hindsight I could have read the existing paragraph more carefully,
but
The "git-{ls-files,ls-tree,show-ref}" commands all have in common that
the core.abbrev variable is ignored, and only --abbrev works. This is
intentional since these are all plumbing.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t0014-abbrev.sh | 32
1 file
Adjust this code that'll be modified in a subsequent change to have
more than one line per branch to use braces per the CodingGuidelines,
this makes the later change easier to understand.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
parse-options-cb.c | 5 +++--
1 file changed, 3 insertions(+), 2
The "diff" family of commands does its own parsing for --abbrev in
diff.c, so having dedicated tests for it makes sense.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t0014-abbrev.sh | 31 +++
1 file changed, 31 insertions(+)
diff --git a/t/t0014-abbrev.sh
Adjust this code that'll be modified in a subsequent change to have
more than one line per branch to use braces per the CodingGuidelines,
this makes the later change easier to understand.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
config.c | 4 ++--
1 file changed, 2 insertions(+), 2
Unify how --abbrev=XYZ and core.abbrev=XYZ is handled. 2/4 parsers for
these values would just let these invalid values pass, treating them
as though "0" was provided, which due to other inconsistent fallback
logic (soon to be fixed) would be treated as providing MINIMUM_ABBREV.
Signed-off-by:
For no good reason the --abbrev= command-line option was less strict
than the core.abbrev config option, which came down to the latter
using git_config_int() which rejects an empty string, but the rest of
the parsing using strtoul() which will convert it to 0.
Signed-off-by: Ævar Arnfjörð
Change the core.abbrev config variable and the corresponding --abbrev
command-line option to support relative values such as +1 or -1.
Before Linus's e6c587c733 ("abbrev: auto size the default
abbreviation", 2016-09-30) git would default to abbreviating object
names to 7-hexdigits, and only
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/t0014-abbrev.sh | 10 ++
1 file changed, 10 insertions(+)
diff --git a/t/t0014-abbrev.sh b/t/t0014-abbrev.sh
index 934c54a96b..d8b060d922 100755
--- a/t/t0014-abbrev.sh
+++ b/t/t0014-abbrev.sh
@@ -168,4 +168,14 @@ do
"
done
+for i
This new function is like test_line_count except it uses "wc -c"
instead of "wc -l". Perhaps this should be a parameter, but I don't
see us needing "wc -m" (chars), "wc -w" (words) etc.
Change a couple of existing tests that use this, I expect to use this
in later patches when adding more tests.
How hashes are abbreviated is a core feature of git, and should have
its own t0*.sh tests. There's a few tests for core.abbrev and --abbrev
already, but none of those stress the feature itself and its edge
cases much. We should have tests for those in one place.
I don't like some of this behavior
This patch series implements an entirely alternate method of achieving
some of the same ends as the MIDX, using the approach suggested by
Jeff King from the RFC thread back in January[1]. You can now do:
core.abbrev = 20
core.validateAbbrev = false
Or:
core.abbrev = +2
Referring to the "length" of a file is ambiguous. We mean the number
of lines, so let's say that.
Changes the description added in fb3340a6a7 ("test-lib: introduce
test_line_count to measure files", 2010-10-31).
Signed-off-by: Ævar Arnfjörð Bjarmason
---
t/README | 2 +-
1 file changed, 1
> The commit-graph file is a very helpful feature for speeding up git
> operations. In order to make it more useful, make it possible to
> write the commit-graph file during standard garbage collection
> operations.
>
> Add a 'gc.commitGraph' config setting that triggers writing a
>
On Fri, Jun 08 2018, Johannes Sixt wrote:
> Am 08.06.2018 um 18:00 schrieb Thomas Braun:
>> I for my part would much rather prefer that to be a compile time
>> option so that I don't need to check on every git update on windows
>> if this is now enabled or not.
>
> This exactly my concern,
Am 08.06.2018 um 04:53 schrieb Theodore Y. Ts'o:
And of course, that's the other thing you seem to fundamentally not
understand about how git works. Every developer in the world working
on that open source project has their own copy.
Everyone here understands how Git works, of course.
Am 08.06.2018 um 18:00 schrieb Thomas Braun:
I for my part would much rather prefer that to be a compile time
option so that I don't need to check on every git update on windows
if this is now enabled or not.
This exactly my concern, too! A compile-time option may make it a good
deal less
On Fri, Jun 8, 2018 at 11:52 PM, Jonathan Nieder wrote:
> SZEDER Gábor wrote:
>> On Fri, Jun 8, 2018 at 11:23 PM, Jonathan Nieder wrote:
>
+ [[ -z "${GIT_SOURCING_ZSH_COMPLETION}" ]] ; then
>>>
>>> Needs a - before the } to avoid errors in a shell where the user has
>>> chosen to use "set
SZEDER Gábor wrote:
> On Fri, Jun 8, 2018 at 11:23 PM, Jonathan Nieder wrote:
>>> + [[ -z "${GIT_SOURCING_ZSH_COMPLETION}" ]] ; then
>>
>> Needs a - before the } to avoid errors in a shell where the user has
>> chosen to use "set -u". See v1.7.4-rc0~159 (completion: fix zsh check
>> under
On Fri, Jun 8, 2018 at 11:23 PM, Jonathan Nieder wrote:
> Hi,
>
> SZEDER Gábor wrote:
>
>> Being in RC phase, I'm all for aiming for a minimal solution.
>> However, I don't think that the better fix would be erm.. any "less
>> minimal":
>>
>> diff --git a/contrib/completion/git-completion.bash
Hi,
SZEDER Gábor wrote:
> Being in RC phase, I'm all for aiming for a minimal solution.
> However, I don't think that the better fix would be erm.. any "less
> minimal":
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index
> Related question: what would it take to add a zsh completion sanity
> check to t/t9902-completion.sh?
I don't know. What I do know is that we can't just run our tests with
ZSH, e.g. running 'zsh ./t-basic.sh' shows mostly failures. So it
won't be as simple as modifying 't/lib-bash.sh'
This is an updated version of the set of changes I posted recently,
following comments on the list:
disable automatic sync after git-p4 submit:
https://marc.info/?l=git=152818734814838=2
better handling of being logged out by Perforce:
https://marc.info/?l=git=152818893815326=2
adapt the
git-p4 originally would fetch changes in one query. On large repos this
could fail because of the limits that Perforce imposes on the number of
items returned and the number of queries in the database.
To fix this, git-p4 learned to query changes in blocks of 512 changes,
However, this can be
Currently when p4 fails to run, git-p4 just crashes with an obscure
error message.
For example, if the P4 ticket has expired, you get:
Error: Cannot locate perforce checkout of in client view
This change checks whether git-p4 can talk to the Perforce server when
the first P4 operation is
This change lays some groundwork for better handling of rowcount errors
from the server, where it fails to send us results because we requested
too many.
It adds an option to p4CmdList() to return errors as a Python exception.
The exceptions are derived from P4Exception (something went wrong),
Add an option to the git-p4 submit command to disable syncing
with Perforce.
This is useful for the case where a git-p4 mirror has been setup
on a server somewhere, running from (e.g.) cron, and developers
then clone from this. Having the local cloned copy also sync
from Perforce just isn't
This just lets you set the --disable-rebase option with the
git configuration options git-p4.disableRebase. If you're
using this option, you probably want to set it all the time
for a given repo.
Signed-off-by: Luke Diamand
---
Documentation/git-p4.txt | 5 -
git-p4.py| 2 +-
The current code traps all exceptions around some code which parses an
integer, and then talks to Perforce.
That can result in errors from Perforce being ignored. Change the code
to only catch the integer conversion exceptions.
Signed-off-by: Luke Diamand
---
git-p4.py | 2 +-
1 file changed,
Am 07.06.2018 um 16:12 schrieb g...@jeffhostetler.com:
> Makefile| 2 +
> json-writer.c | 419
> json-writer.h | 113 +
> t/helper/test-json-writer.c | 572
>
Dear Nguyễn,
I am barrister Malouf Tuma, the solicitor and executor of late
(Eng.G.E. Nguyễn,), will" and "Testament"; who died of kidney cancer
with UN-identified family or relative. I am contacting you to stand in
as a next of kin to his deposit of US$11.350million, with one of the
leading bank
On 6/7/2018 1:24 PM, Eric Sunshine wrote:
On Thu, Jun 7, 2018 at 10:12 AM, wrote:
Add a series of jw_ routines and "struct json_writer" structure to compose
JSON data. The resulting string data can then be output by commands wanting
to support a JSON output format.
[...]
Signed-off-by:
Am 07.06.2018 um 16:12 schrieb g...@jeffhostetler.com:
> From: Jeff Hostetler
> +/*
> + * Add comma if we have already seen a member at this level.
> + */
> +static inline void maybe_add_comma(struct json_writer *jw)
> +{
> + if (!jw->open_stack.len)
> + return;
This is
The caret on boundary commits is only mentioned in the description of
--abbrev; this patch adds a description of the behaviour in the
paragraph describing how revision range specifiers are handled.
Signed-off-by: Stephen Kitt
---
Documentation/git-blame.txt | 3 ++-
1 file changed, 2
On Fri, 8 Jun 2018, Peter Backes wrote:
On Fri, Jun 08, 2018 at 12:42:54AM -0700, David Lang wrote:
Wrong, if you have to delete info, you are not allowed to keep a private
copy.
Yes you are allowed. See Art. 17 (3) lit e GDPR.
There is _nothing_ in the GDPR about publishing information,
# Truncating file names with Unicode characters
When shortening file names that contain Unicode characters, git performs
truncation without awareness of two-byte characters. That often leads to
splitting a character in half and displaying a garbage byte that's left.
Unawareness of Unicode also
On 6/8/2018 9:18 AM, Robert P. J. Day wrote:
for one of my courses, i wanted to write a section about the various
techniques for dealing with whitespace issues in git, so i started
making a list, things like:
- running "git diff --check"
- "git commit --cleanup=" possibilities
-
On Fri, Jun 08, 2018 at 10:45:51AM -0400, Theodore Y. Ts'o wrote:
> *Anyone* can run a repository. It's not just github and gitlab. The
> hobbiest in New Zealand, who might never visit Europe (so she can't
> be arrested when she visits the fair shores of Europe) and who has no
> business
Am 08.06.2018 um 11:07 schrieb Jeff King:
> On Thu, Jun 07, 2018 at 11:10:52PM +0200, Johannes Sixt wrote:
>
>> Am 07.06.2018 um 16:53 schrieb g...@jeffhostetler.com:
>>> From: Jeff Hostetler
>>>
>>> I've been working to add code to Git to optionally collect telemetry data.
>>> The goal is to be
On Thu, Jun 7, 2018 at 5:11 PM Duy Nguyen wrote:
>
> On Thu, Jun 7, 2018 at 9:41 AM, Elijah Newren wrote:
> > Subject line: unpack-trees rather than unpack-tress.
> >
> >
> >
> > On Wed, Jun 6, 2018 at 9:49 AM, Nguyễn Thái Ngọc Duy
> > wrote:
> >> Prior to fba92be8f7, this code implicitly (and
On Fri, Jun 8, 2018 at 11:40 AM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Thu, Jun 07 2018, Johannes Sixt wrote:
>
>> Am 07.06.2018 um 16:53 schrieb g...@jeffhostetler.com:
>>> From: Jeff Hostetler
>>>
>>> I've been working to add code to Git to optionally collect telemetry data.
>>> The goal is to
The `--cherry-pick` option states:
>Omit any commit that introduces the same change as another commit on the
>“other side”
For next git command I see next tree:
$ git log --graph --decorate --pretty=oneline --abbrev-commit --cherry-mark
--boundary --left-right
< bc2820d
On 6/8/2018 11:05 AM, Jakub Narębski wrote:
On Fri, 8 Jun 2018 at 15:56, Derrick Stolee wrote:
[..], the following
diff occurs from the previous patch:
[...]
diff --git a/t/t5318-commit-graph.sh b/t/t5318-commit-graph.sh
index b24e8b6689..9a0661983c 100755
--- a/t/t5318-commit-graph.sh
+++
On Fri, 8 Jun 2018 at 15:56, Derrick Stolee wrote:
> [..], the following
> diff occurs from the previous patch:
[...]
> diff --git a/t/t5318-commit-graph.sh b/t/t5318-commit-graph.sh
> index b24e8b6689..9a0661983c 100755
> --- a/t/t5318-commit-graph.sh
> +++ b/t/t5318-commit-graph.sh
> @@ -33,8
On Fri, Jun 08, 2018 at 08:26:57AM +0200, Peter Backes wrote:
>
> If you run a website where the world can access a repository, you are
> responsible for obeying the GDPR with respect to that repository. If
> you receive a request to be forgotten, you have to make sure you stop
> publishing
While iterating through the commit parents, perform the generation
number calculation and compare against the value stored in the
commit-graph.
The tests demonstrate that having a different set of parents affects
the generation number calculation, and this value propagates to
descendants. Hence,
In anticipation of verifying commit-graph file contents against the
object database, create parse_commit_internal() to allow side-stepping
the commit-graph file and parse directly from the object database.
Due to the use of generation numbers, this method should not be called
unless the intention
Signed-off-by: Derrick Stolee
---
builtin/commit-graph.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c
index 37420ae0fd..f0875b8bf3 100644
--- a/builtin/commit-graph.c
+++ b/builtin/commit-graph.c
@@ -51,8 +51,11 @@ static
The 'verify' subcommand must compare the commit content parsed from the
commit-graph against the content in the object database. Use
lookup_commit() and parse_commit_in_graph_one() to parse the commits
from the graph and compare against a commit that is loaded separately
and parsed directly from
Signed-off-by: Derrick Stolee
---
commit-graph.c | 6 ++
t/t5318-commit-graph.sh | 6 ++
2 files changed, 12 insertions(+)
diff --git a/commit-graph.c b/commit-graph.c
index e0f71658da..6d6c6beff9 100644
--- a/commit-graph.c
+++ b/commit-graph.c
@@ -986,6 +986,12 @@ int
This is the first of several commits that add a test to check that
'git commit-graph verify' catches corruption in the commit-graph
file. The first test checks that the command catches an error in
the file signature. This is a check that exists in the existing
commit-graph reading code.
Add a
The commit-graph file requires the following three chunks:
* OID Fanout
* OID Lookup
* Commit Data
If any of these are missing, then the 'verify' subcommand should
report a failure. This includes the chunk IDs malformed or the
chunk count is truncated.
Signed-off-by: Derrick Stolee
---
When writing commit-graph files, it can be convenient to ask for all
reachable commits (starting at the ref set) in the resulting file. This
is particularly helpful when writing to stdin is complicated, such as a
future integration with 'git gc'.
Signed-off-by: Derrick Stolee
---
The commit-graph file is a very helpful feature for speeding up git
operations. In order to make it more useful, make it possible to
write the commit-graph file during standard garbage collection
operations.
Add a 'gc.commitGraph' config setting that triggers writing a
commit-graph file after any
The commit-graph file has an extra chunk to store the parent int-ids for
parents beyond the first parent for octopus merges. Our test repo has a
single octopus merge that we can manipulate to demonstrate the 'verify'
subcommand detects incorrect values in that chunk.
Signed-off-by: Derrick Stolee
The commit-graph file ends with a SHA1 hash of the previous contents. If
a commit-graph file has errors but the checksum hash is correct, then we
know that the problem is a bug in Git and not simply file corruption
after-the-fact.
Compute the checksum right away so it is the first error that
The commit-graph feature is now integrated with 'fsck' and 'gc',
so remove those items from the "Future Work" section of the
commit-graph design document.
Also remove the section on lazy-loading trees, as that was completed
in an earlier patch series.
Signed-off-by: Derrick Stolee
---
Signed-off-by: Derrick Stolee
---
builtin/commit-graph.c | 39 +--
commit-graph.c | 15 +++
commit-graph.h | 7 +++
3 files changed, 23 insertions(+), 38 deletions(-)
diff --git a/builtin/commit-graph.c
If the commit-graph file becomes corrupt, we need a way to verify
that its contents match the object database. In the manner of
'git fsck' we will implement a 'git commit-graph verify' subcommand
to report all issues with the file.
Add the 'verify' subcommand to the 'commit-graph' builtin and its
Before verifying a commit-graph file against the object database, we
need to parse all commits from the given commit-graph file. Create
parse_commit_in_graph_one() to target a given struct commit_graph.
Signed-off-by: Derrick Stolee
---
commit-graph.c | 18 +++---
1 file changed, 15
When lazy-loading a tree for a commit, it will be important to select
the tree from a specific struct commit_graph. Create a new method that
specifies the commit-graph file and use that in
get_commit_tree_in_graph().
Signed-off-by: Derrick Stolee
---
commit-graph.c | 12 +---
1 file
If core.commitGraph is true, verify the contents of the commit-graph
during 'git fsck' using the 'git commit-graph verify' subcommand. Run
this check on all alternates, as well.
We use a new process for two reasons:
1. The subcommand decouples the details of loading and verifying a
The commit-graph file stores parents in a two-column portion of the
commit data chunk. If there is only one parent, then the second column
stores 0x to indicate no second parent.
The 'verify' subcommand checks the parent list for the commit loaded
from the commit-graph and the one parsed
In the commit-graph file, the OID fanout chunk provides an index into
the OID lookup. The 'verify' subcommand should find incorrect values
in the fanout.
Similarly, the 'verify' subcommand should find out-of-order values in
the OID lookup.
Signed-off-by: Derrick Stolee
---
commit-graph.c
In the 'verify' subcommand, load commits directly from the object
database to ensure they exist. Parse by skipping the commit-graph.
Signed-off-by: Derrick Stolee
---
commit-graph.c | 18 ++
t/t5318-commit-graph.sh | 7 +++
2 files changed, 25 insertions(+)
diff
The GRAPH_MIN_SIZE macro should be the smallest size of a parsable
commit-graph file. However, the minimum number of chunks was wrong.
It is possible to write a commit-graph file with zero commits, and
that violates this macro's value.
Rewrite the macro, and use extra macros to better explain the
Sorry for the fast rerolls, but Ævar found some runtime issues with the
string-list use and '\*' as multiplication on some platforms. Thus, v4
and v5 are broken. I did get a repro of those issues using VSTS Linux
build servers and checked that they are fixed in this version.
This version depends
for one of my courses, i wanted to write a section about the various
techniques for dealing with whitespace issues in git, so i started
making a list, things like:
- running "git diff --check"
- "git commit --cleanup=" possibilities
- config options like core.{eol,safecrlf,autocrlf}
-
On 6/6/2018 8:45 AM, Derrick Stolee wrote:
On 6/6/2018 8:26 AM, Ævar Arnfjörð Bjarmason wrote:
On Wed, Jun 06 2018, Derrick Stolee wrote:
On 6/6/2018 8:11 AM, Ævar Arnfjörð Bjarmason wrote:
On Wed, Jun 06 2018, Derrick Stolee wrote:
Signed-off-by: Derrick Stolee
+ string_list_clear(,
On Fri, Jun 08, 2018 at 10:13:20AM +0200, Ævar Arnfjörð Bjarmason wrote:
> Can you walk us through how anyone would be expected to fork (as create
> a new project, not the github-ism) existing projects under such a
> regiment?
I don't see your point. Copy the repository to fork. Nothing changes
On Fri, Jun 08, 2018 at 12:42:54AM -0700, David Lang wrote:
> Wrong, if you have to delete info, you are not allowed to keep a private
> copy.
Yes you are allowed. See Art. 17 (3) lit e GDPR.
> There is _nothing_ in the GDPR about publishing information,
> everything in it is about what you are
Derrick Stolee writes:
> The commit-graph file stores a condensed version of the commit history.
> This helps speed up several operations involving commit walks. This
> feature does not work well if those commits "change" using features like
> commit grafts, replace objects, or shallow clones.
On Thu, Jun 07 2018, g...@jeffhostetler.com wrote:
> From: Jeff Hostetler
>
> Create design documentation to describe the telemetry feature.
>
> Signed-off-by: Jeff Hostetler
> ---
> Documentation/technical/telemetry.txt | 475
> ++
> 1 file changed, 475
Dear Friend,
I am Mr.Azzia Mohammed, the head of file department of Bank of Africa
(B.O.A) herein Burkina Faso / Ouagadougou. In my department we
discover an abandoned sum of (US$18 million US Dollars) in an account
that belongs to one of our foreign customer who died along with his
family in
>>
>>> ErrorId MsgDb::MaxResults = { ErrorOf( ES_DB, 32,
>>> E_FAILED, EV_ADMIN, 1 ), "Request too large (over %maxResults%); see
>>> 'p4 help maxresults'." } ;//NOTRANS
>>> ErrorId MsgDb::MaxScanRows = { ErrorOf( ES_DB, 61,
>>> E_FAILED, EV_ADMIN, 1 ), "Too many
Sehr geehrte Damen und Herren,
Sie brauchen Geld? Sie sind auf der suche nach einem Darlehen? 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 Darlehen zu TOP
On Thu, Jun 07 2018, Johannes Sixt wrote:
> Am 07.06.2018 um 16:53 schrieb g...@jeffhostetler.com:
>> From: Jeff Hostetler
>>
>> I've been working to add code to Git to optionally collect telemetry data.
>> The goal is to be able to collect performance data from Git commands and
>> allow it to
On Thu, Jun 07, 2018 at 11:10:52PM +0200, Johannes Sixt wrote:
> Am 07.06.2018 um 16:53 schrieb g...@jeffhostetler.com:
> > From: Jeff Hostetler
> >
> > I've been working to add code to Git to optionally collect telemetry data.
> > The goal is to be able to collect performance data from Git
On Fri, Jun 08 2018, Peter Backes wrote:
> On Thu, Jun 07, 2018 at 10:53:13PM -0400, Theodore Y. Ts'o wrote:
>> The problem is you've left undefined who is "you"? With an open
>> source project, anyone who has contributed to open source project has
>> a copyright interest. That hobbyist in
On Fri, 8 Jun 2018, Peter Backes wrote:
you are the one arguing that the GDPR prohibits Git from storing and
revealing this license granting data, not me.
It prohibits publishing, and only after a request to be forgotten. It
does not prohibit storing your private copy.
Wrong, if you have to
On Thu, Jun 07, 2018 at 10:53:13PM -0400, Theodore Y. Ts'o wrote:
> The problem is you've left undefined who is "you"? With an open
> source project, anyone who has contributed to open source project has
> a copyright interest. That hobbyist in German who submitted a patch?
> They have a
On Thu, Jun 07, 2018 at 04:53:16PM -0700, David Lang wrote:
> the license is granted to the world, so the world has an interest in it.
Certainly, but you need to have overriding legitimate grounds. An
interest is not enough for justification. You have to weight your
interests against those of
Am 07.06.2018 um 16:12 schrieb g...@jeffhostetler.com:
> From: Jeff Hostetler
>
> Add a series of jw_ routines and "struct json_writer" structure to compose
> JSON data. The resulting string data can then be output by commands wanting
> to support a JSON output format.
>
> The json-writer
95 matches
Mail list logo
