Re: [PATCH 08/22] config.c: mark more strings for translation

On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/config.c b/config.c > @@ -461,7 +461,7 @@ int git_config_from_parameters(config_fn_t fn, void *data) > envw = xstrdup(env); > > if (sq_dequote_to_argv(envw, , ,

Re: GDPR compliance best practices?

Hi, Unfortunatly this important topic of GDPR compliance has not seen much interest. After asking github about how they would cope with the issue of erasing the author field, they changed their privacy policy, which now clarifies that this won't be done. My guess is that this would

Re: how exactly can git config section names contain periods?

On Sun, 3 Jun 2018, SZEDER Gábor wrote: > > > > On Fri, 1 Jun 2018, Jeff King wrote: > > > > > On Fri, Jun 01, 2018 at 04:14:12PM -0400, Robert P. J. Day wrote: > > > > ok, so how on earth would i use "git config" at the command line > > > > to set a config variable with some arbitrary level of

[PATCH] update-ref --stdin: use skip_prefix()

Use skip_prefix() instead of starts_with() and strcmp() when parsing 'git update-ref's stdin to avoid a couple of magic numbers. Signed-off-by: SZEDER Gábor --- builtin/update-ref.c | 25 + 1 file changed, 13 insertions(+), 12 deletions(-) diff --git

[PATCH v2 07/23] builtin/replace.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/replace.c | 82 +++ 1 file changed, 41 insertions(+), 41 deletions(-) diff --git a/builtin/replace.c b/builtin/replace.c index de826e8209..c77b325aa1 100644 --- a/builtin/replace.c +++

[PATCH v2 18/23] refspec.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- refspec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refspec.c b/refspec.c index 6e1efd4d60..1266e509c2 100644 --- a/refspec.c +++ b/refspec.c @@ -127,7 +127,7 @@ void refspec_item_init(struct refspec_item *item, const char

[PATCH v2 06/23] builtin/pack-objects.c: mark more strings for translation

Most of these are straight forward. GETTEXT_POISON does catch the last string in cmd_pack_objects(), but since this is --progress output, it's not supposed to be machine-readable. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/pack-objects.c | 108 +

[PATCH v2 13/23] environment.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- environment.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/environment.c b/environment.c index 2a6de2330b..d129c4adc5 100644 --- a/environment.c +++ b/environment.c @@ -147,7 +147,7 @@ static char *expand_namespace(const char

[PATCH v2 20/23] sequencer.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- sequencer.c | 26 ++ 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/sequencer.c b/sequencer.c index def8ae587f..01f3afe7f4 100644 --- a/sequencer.c +++ b/sequencer.c @@ -714,7 +714,7 @@ static const char

[PATCH v2 23/23] transport-helper.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- t/t5801-remote-helpers.sh | 8 ++-- transport-helper.c| 87 --- 2 files changed, 48 insertions(+), 47 deletions(-) diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh index 88c7f158ef..e3bc53b0c7

[PATCH v2 02/23] archive-tar.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- archive-tar.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/archive-tar.c b/archive-tar.c index b6f58ddf38..68e72d9176 100644 --- a/archive-tar.c +++ b/archive-tar.c @@ -121,7 +121,7 @@ static int stream_blocked(const

[PATCH v2 21/23] sha1-file.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- sha1-file.c | 104 ++-- 1 file changed, 52 insertions(+), 52 deletions(-) diff --git a/sha1-file.c b/sha1-file.c index d2df30c4c4..a0ce97b10b 100644 --- a/sha1-file.c +++ b/sha1-file.c @@ -378,8 +378,8 @@

[PATCH v2 09/23] config.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- config.c | 76 +++ t/t1305-config-include.sh | 2 +- 2 files changed, 39 insertions(+), 39 deletions(-) diff --git a/config.c b/config.c index ec08db1d1b..96b6020819 100644 --- a/config.c +++

[PATCH v2 17/23] refs.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c| 40 +-- t/t1400-update-ref.sh | 20 +++--- t/t1404-update-ref-errors.sh | 4 +-- t/t3210-pack-refs.sh | 2 +-

[PATCH v2 16/23] pkt-line.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- pkt-line.c | 26 +- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/pkt-line.c b/pkt-line.c index 941e41dfc1..04d10bbd03 100644 --- a/pkt-line.c +++ b/pkt-line.c @@ -101,7 +101,7 @@ int packet_flush_gently(int fd) {

[PATCH v2 03/23] archive-zip.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- archive-zip.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/archive-zip.c b/archive-zip.c index 48d843489c..7ad46d8854 100644 --- a/archive-zip.c +++ b/archive-zip.c @@ -309,11 +309,11 @@ static int

[PATCH v2 05/23] builtin/grep.c: mark strings for translation and no full stops

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/grep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/grep.c b/builtin/grep.c index 9774920999..58f941e951 100644 --- a/builtin/grep.c +++ b/builtin/grep.c @@ -489,7 +489,7 @@ static int grep_cache(struct grep_opt *opt,

[PATCH v2 15/23] object.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- object.c| 10 +- t/t1450-fsck.sh | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/object.c b/object.c index f7f4de3aaf..c20ea782f1 100644 --- a/object.c +++ b/object.c @@ -51,7 +51,7 @@ int

[PATCH v2 22/23] transport.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- transport.c | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/transport.c b/transport.c index 2f6a7cb4cd..516a83b7f6 100644 --- a/transport.c +++ b/transport.c @@ -139,7 +139,7 @@ static struct ref

[PATCH v2 08/23] commit-graph.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- commit-graph.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/commit-graph.c b/commit-graph.c index 4c6127088f..5a300535b2 100644 --- a/commit-graph.c +++ b/commit-graph.c @@ -76,28 +76,28 @@ struct commit_graph

[PATCH v2 10/23] connect.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- connect.c | 78 +++ t/t5570-git-daemon.sh | 6 ++-- 2 files changed, 44 insertions(+), 40 deletions(-) diff --git a/connect.c b/connect.c index 083cf804a7..70b97cfef6 100644 --- a/connect.c +++

[RFC PATCH 6/7] merge-recursive: enforce rule that index matches head before merging

builtin/merge.c says that when we are about to perform a merge: ...the index must be in sync with the head commit. The strategies are responsible to ensure this. merge-recursive has always relied on unpack_trees() to enforce this requirement, except in the case of an "Already up to

[RFC PATCH 7/7] merge: fix misleading pre-merge check documentation

builtin/merge.c contains this important requirement for merge strategies: ...the index must be in sync with the head commit. The strategies are responsible to ensure this. However, Documentation/git-merge.txt says: ...[merge will] abort if there are any changes registered in the

[RFC PATCH 0/7] merge requirement: index matches head

Between working on some other things, I happened to be reading Documentation/git-merge.txt and ran across the part that says: ...[merge will] abort if there are any changes registered in the index relative to the `HEAD` commit. (One exception is when the changed index entries are in

[RFC PATCH 5/7] t6044: add more testcases with staged changes before a merge is invoked

According to Documentation/git-merge.txt, ...[merge will] abort if there are any changes registered in the index relative to the `HEAD` commit. (One exception is when the changed index entries are in the state that would result from the merge already.) Add some tests showing that

[RFC PATCH 1/7] t6044: verify that merges expected to abort actually abort

t6044 has lots of tests for verifying that merge will abort as expected when there are changes staged before the merge starts. However, it only checked for non-zero exit code, which could mean that the merge ran to completion with conflicts. Check that the merge was actually correctly aborted,

[RFC PATCH 3/7] merge-recursive: make sure when we say we abort that we actually abort

In commit 65170c07d4 ("merge-recursive: avoid incorporating uncommitted changes in a merge", 2017-12-21), it was noted that there was a special case when merge-recursive didn't rely on unpack_trees() to enforce the index == HEAD requirement, and thus that it needed to do that enforcement itself.

[RFC PATCH 2/7] t6044: add a testcase for index matching head, when head doesn't match HEAD

The `git merge-recursive` command allows the user to directly specify three commits to merge -- base, head, and remote. (More than three can be specified in the case of multiple merge bases.) Note that since the user is allowed to specify head, it need not match HEAD. Virtually every test and

[RFC PATCH 4/7] merge-recursive: fix assumption that head tree being merged is HEAD

`git merge-recursive` does a three-way merge between user-specified trees base, head, and remote. Since the user is allowed to specify head, we can not necesarily assume that head == HEAD. We modify index_has_changes() to take an extra argument specifying the tree to compare the index to. If

Re: [PATCH 21/22] transport.c: mark more strings for translation

On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/transport.c b/transport.c > @@ -875,7 +875,7 @@ struct transport *transport_get(struct remote *remote, > const char *url) > ret->progress = isatty(2); > > if

Re: [PATCH 11/22] dir.c: mark more strings for translation

On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/dir.c b/dir.c > @@ -560,7 +560,7 @@ int report_path_error(const char *ps_matched, > - error("pathspec '%s' did not match any file(s) known to git.", > +

[PATCH v2] t/perf/run: Use proper "--get-regexp", not "--get-regex"

Even though "--get-regex" appears to work with "git config", the clear standard is to spell out the action in full. Signed-off-by: Robert P. J. Day --- this is the only occurrence i saw of this in the entire code base, so it seemed worth tweaking just for consistency. diff --git

Re: [PATCH 16/22] refs.c: mark more strings for translation

On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/refs.c b/refs.c > @@ -1845,7 +1845,7 @@ int ref_update_reject_duplicates(struct string_list > *refnames, > if (!cmp) { >

Re: [PATCH 10/22] convert.c: mark more strings for translation

On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/convert.c b/convert.c > @@ -203,11 +203,11 @@ static void check_global_conv_flags_eol(const char > *path, enum crlf_action crlf_ > if (conv_flags &

Re: [RFC PATCH 4/7] merge-recursive: fix assumption that head tree being merged is HEAD

On 03/06/18 07:58, Elijah Newren wrote: > `git merge-recursive` does a three-way merge between user-specified trees > base, head, and remote. Since the user is allowed to specify head, we can > not necesarily assume that head == HEAD. > > We modify index_has_changes() to take an extra

Re: [PATCH] sha1-file.c: Correct $GITDIR to $GIT_DIR

Could you please add "in a comment" to the end of the subject line? So it will be immediately clear to future readers of 'git log --oneline' that this is not a bugfix. > Fix single misspelling of $GITDIR to correct $GIT_DIR. > > Signed-off-by: Robert P. J. Day > > --- > > only occurrence in

Re: [PATCH v2] t/perf/run: Use proper "--get-regexp", not "--get-regex"

From: "Robert P. J. Day" On Sun, 3 Jun 2018, Thomas Gummerer wrote: > Subject: [PATCH v2] t/perf/run: Use proper "--get-regexp", not micronit: we prefer starting with a lowercase letter after the "area:" prefix in commit messages. Junio can probably fix that while queuing, so no need to

Re: [PATCH 19/22] sequencer.c: mark more strings for translation

On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/sequencer.c b/sequencer.c > @@ -2597,15 +2597,17 @@ static int error_with_patch(struct commit *commit, > - fprintf(stderr, "You can amend the commit now, with\n"

Re: [PATCH 22/22] transport-helper.c: mark more strings for translation

On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/t/t5801-remote-helpers.sh b/t/t5801-remote-helpers.sh > @@ -196,13 +196,13 @@ static struct child_process *get_helper(struct > transport *transport) > -

[PATCH] t/perf/run: Use proper "--get-regexp", not "get-regex"

Even though "--get-regex" appears to work with "git config", the standard is to spell out the action in full. Signed-off-by: Robert P. J. Day --- this is the only occurrence i saw of this in the entire code base, so it seemed worth tweaking just for consistency. diff --git a/t/perf/run

Re: [PATCH 03/22] builtin/config.c: mark more strings for translation

On Sun, Jun 3, 2018 at 11:01 AM, Eric Sunshine wrote: > On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy > wrote: >> There are also some minor adjustments in the strings. >> >> Signed-off-by: Nguyễn Thái Ngọc Duy >> --- >> diff --git a/builtin/config.c b/builtin/config.c >> @@ -746,7

[PATCH] Use ZSH_NAME instead of ZSH_VERSION because it's redefined by git-completion.zsh

The `git-completion.zsh` unsets the `$ZSH_VERSION` which makes this check moot. The result (at least for me) is that zsh segfaults because of all the variables it's unsetting. --- contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: format-patch: no 'prerequisite-patch-id' info when specifying commit range

Hi, Junio On 05/29, Eduardo Habkost wrote: >Hi, > >I'm trying to use git-format-patch --base to generate the list of >prerequisite patches for a series, but the behavior of git >doesn't seem to match the documentation: > >When using a commit count (e.g.: "-2"), git-format-patch generates the

Re: how exactly can git config section names contain periods?

Am 03.06.2018 um 11:53 schrieb Robert P. J. Day: if i wanted to do something this admittedly awkward, would using periods give me some benefit related to, i don't know, regex matching, as compared to using a different character? or am i just way overthinking this? is anyone out there actually

Re: [RFC/PATCH 3/7] rerere: add some documentation

On 05/24, Junio C Hamano wrote: > Thomas Gummerer writes: > > > +Conflict normalization > > +-- > > + > > +To try and re-do a conflict resolution, even when different merge > > +strategies are used, 'rerere' computes a conflict ID for each > > +conflict in the file. > > + > >

[PATCH v2] sha1-file.c: correct $GITDIR to $GIT_DIR in a comment

Fix single misspelling of $GITDIR to correct $GIT_DIR in a comment. Signed-off-by: Robert P. J. Day --- updated patch to clarify that the misspelling is only in a comment. diff --git a/sha1-file.c b/sha1-file.c index 555e780f4..695e5c627 100644 --- a/sha1-file.c +++ b/sha1-file.c @@ -610,7

Re: [PATCH 09/22] connect.c: mark more strings for translation

On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy wrote: > There are also some rephrasing and breaking sentences to help > translators. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/connect.c b/connect.c > @@ -921,7 +928,7 @@ static enum protocol parse_connect_url(const char

Re: [PATCH v2] t/perf/run: Use proper "--get-regexp", not "--get-regex"

> Subject: [PATCH v2] t/perf/run: Use proper "--get-regexp", not micronit: we prefer starting with a lowercase letter after the "area:" prefix in commit messages. Junio can probably fix that while queuing, so no need to resend. On 06/03, Robert P. J. Day wrote: > > Even though "--get-regex"

Re: [PATCH 19/22] sequencer.c: mark more strings for translation

On Sun, Jun 3, 2018 at 10:16 AM, Eric Sunshine wrote: > On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy > wrote: >> Signed-off-by: Nguyễn Thái Ngọc Duy >> --- >> diff --git a/sequencer.c b/sequencer.c >> @@ -2597,15 +2597,17 @@ static int error_with_patch(struct commit *commit, >> -

Re: [PATCH 20/22] sha1-file.c: mark more strings for translation

On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/sha1-file.c b/sha1-file.c > @@ -71,17 +71,17 @@ static void git_hash_sha1_final(unsigned char *hash, > git_hash_ctx *ctx) > static void git_hash_unknown_init(git_hash_ctx

Re: how exactly can git config section names contain periods?

> On Fri, 1 Jun 2018, Jeff King wrote: > > > On Fri, Jun 01, 2018 at 04:14:12PM -0400, Robert P. J. Day wrote: > > > ok, so how on earth would i use "git config" at the command line > > > to set a config variable with some arbitrary level of subsections? > > > let's try this: > > > > You

Re: [PATCH v2] t/perf/run: Use proper "--get-regexp", not "--get-regex"

On Sun, 3 Jun 2018, Thomas Gummerer wrote: > > Subject: [PATCH v2] t/perf/run: Use proper "--get-regexp", not > > micronit: we prefer starting with a lowercase letter after the "area:" > prefix in commit messages. Junio can probably fix that while > queuing, so no need to resend. argh, i

Re: GDPR compliance best practices?

From: "Peter Backes" On Sun, Jun 03, 2018 at 02:59:26PM +0200, Ævar Arnfjörð Bjarmason wrote: I'm not trying to be selfish, I'm just trying to counter your literal reading of the law with a comment of "it'll depend". Just like there's a law against public urination in many places, but this is

Re: GDPR compliance best practices?

On Sun, Jun 03, 2018 at 12:45:25PM +0200, Ævar Arnfjörð Bjarmason wrote: > protection". I.e. regulators / prosecutors are much likely to go after > some advertising company than some project using a Git repo. Well, it is indeed rather unlikely that one particular git repo project will be

[PATCH] sha1-file.c: Correct $GITDIR to $GIT_DIR

Fix single misspelling of $GITDIR to correct $GIT_DIR. Signed-off-by: Robert P. J. Day --- only occurrence in entire code base that i ran across, so i figured might as well fix it. diff --git a/sha1-file.c b/sha1-file.c index 555e780f4..695e5c627 100644 --- a/sha1-file.c +++ b/sha1-file.c @@

Re: GDPR compliance best practices?

On Sun, Jun 03 2018, Peter Backes wrote: > On Sun, Jun 03, 2018 at 12:45:25PM +0200, Ævar Arnfjörð Bjarmason wrote: >> protection". I.e. regulators / prosecutors are much likely to go after >> some advertising company than some project using a Git repo. > > Well, it is indeed rather unlikely

Re: GDPR compliance best practices?

On Sun, Jun 03, 2018 at 02:59:26PM +0200, Ævar Arnfjörð Bjarmason wrote: > I'm not trying to be selfish, I'm just trying to counter your literal > reading of the law with a comment of "it'll depend". > > Just like there's a law against public urination in many places, but > this is applied very

Re: [PATCH 21/22] transport.c: mark more strings for translation

On Sun, Jun 3, 2018 at 10:29 AM, Eric Sunshine wrote: > On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy > wrote: >> Signed-off-by: Nguyễn Thái Ngọc Duy >> --- >> diff --git a/transport.c b/transport.c >> @@ -875,7 +875,7 @@ struct transport *transport_get(struct remote *remote, >> const

[PATCH v2 11/23] convert.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- convert.c | 38 -- t/t0021-conversion.sh | 2 +- 2 files changed, 21 insertions(+), 19 deletions(-) diff --git a/convert.c b/convert.c index f47e60022e..e53911d4f8 100644 --- a/convert.c +++ b/convert.c @@

[PATCH v2 00/23] Mark strings for translation

v2 changes - fix one _() (was "()" by accident) - improve some error messages while i'm making changes - restore some multi-sentence messages back All non-_() changes are now collected in the first patch. Interdiff diff --git a/builtin/config.c b/builtin/config.c index 85f043a243..3c26df6c48

[PATCH v2 01/23] Update messages in preparation for i18n

Many messages will be marked for translation in the following commits. This commit updates some of them to be more consistent and reduce diff noise in those commits. Changes are - keep the first letter of die(), error() and warning() in lowercase - no full stop in die(), error() or warning() if

[PATCH v2 12/23] dir.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- dir.c| 6 +++--- t/t3005-ls-files-relative.sh | 4 ++-- t/t7400-submodule-basic.sh | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/dir.c b/dir.c index 7e39f38563..8e7fa02a01 100644 --- a/dir.c +++ b/dir.c @@

[PATCH v2 04/23] builtin/config.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/config.c | 48 +-- t/t1308-config-set.sh | 2 +- 2 files changed, 25 insertions(+), 25 deletions(-) diff --git a/builtin/config.c b/builtin/config.c index ebeb4c5638..3c26df6c48 100644 ---

[PATCH v2 19/23] replace-object.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- replace-object.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/replace-object.c b/replace-object.c index 801b5c1678..ddc1546b8c 100644 --- a/replace-object.c +++ b/replace-object.c @@ -17,7 +17,7 @@ static int

[PATCH v2 14/23] exec-cmd.c: mark more strings for translation

Signed-off-by: Nguyễn Thái Ngọc Duy --- exec-cmd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/exec-cmd.c b/exec-cmd.c index 02d31ee897..4f81f44310 100644 --- a/exec-cmd.c +++ b/exec-cmd.c @@ -358,7 +358,7 @@ int execl_git_cmd(const char *cmd, ...) }

Re: [PATCH v6 8/8] checkout & worktree: introduce checkout.defaultRemote

On Sat, Jun 2, 2018 at 7:50 AM, Ævar Arnfjörð Bjarmason wrote: > Introduce a checkout.defaultRemote setting which can be used to > designate a remote to prefer (via checkout.defaultRemote=origin) when > running e.g. "git checkout master" to mean origin/master, even though > there's other remotes

Re: [PATCH 06/22] builtin/replace.c: mark more strings for translation

On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy wrote: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/builtin/replace.c b/builtin/replace.c > @@ -456,10 +456,10 @@ static int create_graft(int argc, const char **argv, > int force, int gentle) > - if (remove_signature()) {

Re: [PATCH 03/22] builtin/config.c: mark more strings for translation

On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy wrote: > There are also some minor adjustments in the strings. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > diff --git a/builtin/config.c b/builtin/config.c > @@ -746,7 +746,7 @@ int cmd_config(int argc, const char **argv, const char >

Re: how exactly can git config section names contain periods?

On Fri, 1 Jun 2018, Jeff King wrote: > On Fri, Jun 01, 2018 at 04:14:12PM -0400, Robert P. J. Day wrote: ... snip ... > > ok, so how on earth would i use "git config" at the command line > > to set a config variable with some arbitrary level of subsections? > > let's try this: > > You don't.

Re: GDPR compliance best practices?

On Sun, Jun 03 2018, Peter Backes wrote: > Unfortunatly this important topic of GDPR compliance has not seen much > interest. I don't think you can infer that there's not much interest, but maybe people just don't have anything to say about it. There's a lot of discussions about this that

Re: git glob pattern in .gitignore and git command

On Sun, Jun 3, 2018 at 2:58 AM, Yubin Ruan wrote: > To ignore all .js file under a directory `lib', I can use "lib/**/js" to match > them. But when using git command such as "git add", using "git add lib/\*.js" > is sufficient. Why is this difference in glob mode? Historical reasons mostly. '**'

Re: GDPR compliance best practices?

On Sun, Jun 03, 2018 at 09:24:17PM +0200, Peter Backes wrote: > > He said: It would be a tyranny of lawyers. > > Let's not have a tyranny of lawyers. Let us, the engineers and hackers, > exercise the necessary control over those pesky lawyers by defining and > redefining the state of the art

Re: GDPR compliance best practices?

On Sun, Jun 03, 2018 at 05:03:44PM -0400, Theodore Y. Ts'o wrote: > If you don't think a potential 2x -- 10x performance hit isn't a > blocking factor --- sure, go ahead and try implementing it. And good > luck to you. And this is not a guarantee that it won't get rejected. > I certainly don't

Re: [RFC PATCH 4/7] merge-recursive: fix assumption that head tree being merged is HEAD

On Sun, Jun 03, 2018 at 02:52:12PM +0100, Ramsay Jones wrote: > On 03/06/18 07:58, Elijah Newren wrote: > > I'm really unsure where the index_has_changes() declaration should go; > > I stuck it in tree.h, but is there a better spot? > > Err, leave it where it is and '#include "tree.h"' ? :-D Or

Re: [PATCH v2 05/36] refspec: convert valid_fetch_refspec to use parse_refspec

Hi Brandon, On 17 May 2018 at 00:57, Brandon Williams wrote: > Convert 'valid_fetch_refspec()' to use the new 'parse_refspec()' > function to only parse a single refspec and eliminate an allocation. > > Signed-off-by: Brandon Williams > --- > refspec.c | 17 - > refspec.h | 3

Re: [PATCH 02/22] archive-zip.c: mark more strings for translation

On Sat, Jun 02, 2018 at 08:17:47AM +0200, Duy Nguyen wrote: > On Sat, Jun 2, 2018 at 6:32 AM, Nguyễn Thái Ngọc Duy > wrote: > > if (pathlen > 0x) { > > - return error("path too long (%d chars, SHA1: %s): %s", > > + return error(_("path too long (%d chars,

Re: GDPR compliance best practices?

On Sun, Jun 03 2018, Peter Backes wrote: > On Sun, Jun 03, 2018 at 02:59:26PM +0200, Ævar Arnfjörð Bjarmason wrote: >> I'm not trying to be selfish, I'm just trying to counter your literal >> reading of the law with a comment of "it'll depend". >> >> Just like there's a law against public

Re: GDPR compliance best practices?

correcting a negative /with/without/ and inserting a comma. - Original Message - From: "Philip Oakley" [snip] From a personal view, many folk want it to be that corporates (and open source organisations) should hold no personal information with having s/with/without/ explicit

Re: [PATCH 19/22] sequencer.c: mark more strings for translation

On Sun, Jun 3, 2018 at 11:14 AM, Duy Nguyen wrote: > On Sun, Jun 3, 2018 at 10:16 AM, Eric Sunshine > wrote: >> On Sat, Jun 2, 2018 at 12:32 AM, Nguyễn Thái Ngọc Duy >> wrote: >>> Signed-off-by: Nguyễn Thái Ngọc Duy >>> - fprintf(stderr, "Could not apply %s... %.*s\n", >>> +

Re: GDPR compliance best practices?

On Sun, Jun 03, 2018 at 10:52:33PM +02h00, hPeter Backes wrote: > But I will take your message as saying you at least don't see any > obvious criticism leading to complete rejection of the approach. If you don't think a potential 2x -- 10x performance hit isn't a blocking factor --- sure, go

[GSoC] GSoC with git, week 5

Hi, I wrote a post about this week. Unfortunately, I have a technical issue with my website, so you can find it right in this email instead. I’m sorry about that. I will publish it on my blog as soon as it comes back online. Feel free to give me your feedback! Cheers, Alban -- As you may

Re: git glob pattern in .gitignore and git command

Hi Yubun, From: "Yubin Ruan" To ignore all .js file under a directory `lib', I can use "lib/**/js" to match them. But when using git command such as "git add", using "git add lib/\*.js" is sufficient. Why is this difference in glob mode? I have heard that there are many different glob mode

Re: GDPR compliance best practices?

On Sun, Jun 03, 2018 at 07:46:17PM +0200, Peter Backes wrote: > > Let's be honest: We do not know what legitimization exactly in each > specific case the git metadata is being distributed under. It seems like you are engaging in something even more dangerous than a hardware engineering

Re: GDPR compliance best practices?

On Sun, Jun 03, 2018 at 02:18:07PM -0400, Theodore Y. Ts'o wrote: > I would gently suggest that if you really want to engage in something > practical than speculating how the GPDR compliance will work out in > actual practice, that you contact a lawyer and get official legal > advice? I

Re: GDPR compliance best practices?

Addendum: I one discussed with a philosopher the question: What is your argument against libertarianism? He said: It would be a tyranny of lawyers. Let's not have a tyranny of lawyers. Let us, the engineers and hackers, exercise the necessary control over those pesky lawyers by defining and

Re: GDPR compliance best practices?

On Sun, Jun 03, 2018 at 09:48:16PM +0200, Ævar Arnfjörð Bjarmason wrote: > Sure, but what I'm pointing out is a) you can't focus on git as the > technology because it tells you nothing about what's being done with it > (e.g. the log file case I mentioned b) nobody who came up with the GDPR > was

Re: GDPR compliance best practices?

On Sun, Jun 03, 2018 at 11:28:43PM +0100, Philip Oakley wrote: > It is here that Article 6 kicks in as to whether the 'organisation' can > retain the data and continue to use it. Article 6 is not about continuing to use data. Article 6 is about having and even obtaining it in the first place.

Re: GDPR compliance best practices?

On Sun, Jun 03, 2018 at 04:07:39PM -0400, Theodore Y. Ts'o wrote: > Why don't you try to implement your proposal then, and then benchmark > it. After you find out how much of a performance disaster it's going > to be, especially for large git repos, we can discuss who is being > tyrannical. See,

Re: GDPR compliance best practices?

From: "Peter Backes" On Sun, Jun 03, 2018 at 04:28:31PM +0100, Philip Oakley wrote: In most Git cases that legal/legitimate purpose is the copyright licence, and/or corporate employment. That is, Jane wrote it, hence X has a legal rights of use, and we need to have a record of that (Jane wrote

Re: GDPR compliance best practices?

On Sun, Jun 03, 2018 at 04:28:31PM +0100, Philip Oakley wrote: > In most Git cases that legal/legitimate purpose is the copyright licence, > and/or corporate employment. That is, Jane wrote it, hence X has a legal > rights of use, and we need to have a record of that (Jane wrote it) as > evidence

Re: does a stash *need* any reference to the branch on which it was created?

"Robert P. J. Day" writes: > i realize that, when you "git stash push", stash graciously saves > the branch you were on as part of the commit message, but does any > subsequent stash operation technically *need* that branch name? It is not "saves", but "the message it automatically generates

Re: [PATCH 2/2] sequencer.c: plug mem leak in git_sequencer_config

Jeff King writes: > I've looked into it before, but that causes its own wave of headaches. > The source of the problem is that we do: > > const char *some_var = "default"; > ... > git_config_string(_var, ...); Yup, that is a valid pattern for "run once and let exit(3) clean after us"

Re: [PATCH v7 2/2] http-backend: respect CONTENT_LENGTH for receive-pack

On Sun, Jun 03, 2018 at 12:27:49AM +0300, Max Kirillov wrote: > Push passes to another commands, as described in > https://public-inbox.org/git/20171129032214.gb32...@sigill.intra.peff.net/ > > As it gets complicated to correctly track the data length, instead transfer > the data through parent

Regression (?) in core.safecrlf=false messaging

I'm a bit unclear if I was depending on undocumented behaviour or not here but it seems the messaging has recently changed with respect to `core.safecrlf` My reading of the documentation https://git-scm.com/docs/git-config#git-config-coresafecrlf (I might be wrong here) - core.safecrlf = true ->

Re: [PATCH 2/2] sequencer.c: plug mem leak in git_sequencer_config

Junio C Hamano writes: > Stefan Beller writes: > >> Signed-off-by: Stefan Beller >> --- >> sequencer.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/sequencer.c b/sequencer.c >> index b98690ecd41..aba03e9429a 100644 >> --- a/sequencer.c >> +++ b/sequencer.c >> @@ -175,6 +175,7

Re: [PATCH v4 8/9] checkout: add advice for ambiguous "checkout "

Ævar Arnfjörð Bjarmason writes: > I.e. I was trying to avoid printing out the "error: pathspec 'master' > did not match any file(s) known to git." error altogether. That's still > arguably a good direction, since we *know* "master" would have otherwise > matched a remote branch, so that's

Re: format-patch: no 'prerequisite-patch-id' info when specifying commit range

Ye Xiaolong writes: > I narrowed down the problem to revision walk, if users specify the commit > range > via "Z..C" pattern, the first prepare_revision_walk function called in > cmd_format_patch would mark all parents (ancestors) of Z to be uninteresting, > thus the next revision walk in

Re: format-patch: no 'prerequisite-patch-id' info when specifying commit range

On 06/04, Junio C Hamano wrote: >Ye Xiaolong writes: > >> I narrowed down the problem to revision walk, if users specify the commit >> range >> via "Z..C" pattern, the first prepare_revision_walk function called in >> cmd_format_patch would mark all parents (ancestors) of Z to be uninteresting,

Re: [RFC PATCH 4/7] merge-recursive: fix assumption that head tree being merged is HEAD

Elijah Newren writes: > `git merge-recursive` does a three-way merge between user-specified trees > base, head, and remote. Since the user is allowed to specify head, we can > not necesarily assume that head == HEAD. > > We modify index_has_changes() to take an extra argument specifying the >

Re: [PATCH v7 2/2] http-backend: respect CONTENT_LENGTH for receive-pack

Max Kirillov writes: > +static void pipe_fixed_length(const char *prog_name, int out, size_t req_len) > +{ > + unsigned char buf[8192]; > + size_t remaining_len = req_len; > + > + while (remaining_len > 0) { > + size_t chunk_length = remaining_len > sizeof(buf) ?

  1   2   >