* [PATCH 12/13] i18n: show-branch: mark error messages for translation
From: Vasco Almeida @ 2016-09-07 14:49 UTC (permalink / raw)
To: git; +Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason
In-Reply-To: <1473259758-11836-1-git-send-email-vascomalmeida@sapo.pt>
Lowercase some messages first word to match style of the others.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
---
builtin/show-branch.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/builtin/show-branch.c b/builtin/show-branch.c
index 2566935..8a5097d 100644
--- a/builtin/show-branch.c
+++ b/builtin/show-branch.c
@@ -701,8 +701,8 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
*
* Also --all and --remotes do not make sense either.
*/
- die("--reflog is incompatible with --all, --remotes, "
- "--independent or --merge-base");
+ die(_("--reflog is incompatible with --all, --remotes, "
+ "--independent or --merge-base"));
}
/* If nothing is specified, show all branches by default */
@@ -725,16 +725,16 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
av = fake_av;
ac = 1;
if (!*av)
- die("no branches given, and HEAD is not valid");
+ die(_("no branches given, and HEAD is not valid"));
}
if (ac != 1)
- die("--reflog option needs one branch name");
+ die(_("--reflog option needs one branch name"));
if (MAX_REVS < reflog)
- die("Only %d entries can be shown at one time.",
+ die(_("only %d entries can be shown at one time."),
MAX_REVS);
if (!dwim_ref(*av, strlen(*av), oid.hash, &ref))
- die("No such ref %s", *av);
+ die(_("no such ref %s"), *av);
/* Has the base been specified? */
if (reflog_base) {
@@ -826,12 +826,12 @@ int cmd_show_branch(int ac, const char **av, const char *prefix)
unsigned int flag = 1u << (num_rev + REV_SHIFT);
if (MAX_REVS <= num_rev)
- die("cannot handle more than %d revs.", MAX_REVS);
+ die(_("cannot handle more than %d revs."), MAX_REVS);
if (get_sha1(ref_name[num_rev], revkey.hash))
- die("'%s' is not a valid ref.", ref_name[num_rev]);
+ die(_("'%s' is not a valid ref."), ref_name[num_rev]);
commit = lookup_commit_reference(revkey.hash);
if (!commit)
- die("cannot find commit %s (%s)",
+ die(_("cannot find commit %s (%s)"),
ref_name[num_rev], oid_to_hex(&revkey));
parse_commit(commit);
mark_seen(commit, &seen);
--
2.7.4
^ permalink raw reply related
* [PATCH 13/13] i18n: update-index: mark warning for translation
From: Vasco Almeida @ 2016-09-07 14:49 UTC (permalink / raw)
To: git; +Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason
In-Reply-To: <1473259758-11836-1-git-send-email-vascomalmeida@sapo.pt>
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
---
builtin/update-index.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index ba04b19..7a17ce1 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -1127,9 +1127,9 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
break;
case UC_DISABLE:
if (git_config_get_untracked_cache() == 1)
- warning("core.untrackedCache is set to true; "
- "remove or change it, if you really want to "
- "disable the untracked cache");
+ warning(_("core.untrackedCache is set to true; "
+ "remove or change it, if you really want to "
+ "disable the untracked cache"));
remove_untracked_cache(&the_index);
report(_("Untracked cache disabled"));
break;
@@ -1139,9 +1139,9 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
case UC_ENABLE:
case UC_FORCE:
if (git_config_get_untracked_cache() == 0)
- warning("core.untrackedCache is set to false; "
- "remove or change it, if you really want to "
- "enable the untracked cache");
+ warning(_("core.untrackedCache is set to false; "
+ "remove or change it, if you really want to "
+ "enable the untracked cache"));
add_untracked_cache(&the_index);
report(_("Untracked cache enabled for '%s'"), get_git_work_tree());
break;
--
2.7.4
^ permalink raw reply related
* [PATCH 11/13] i18n: receive-pack: mark messages for translation
From: Vasco Almeida @ 2016-09-07 14:49 UTC (permalink / raw)
To: git; +Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason
In-Reply-To: <1473259758-11836-1-git-send-email-vascomalmeida@sapo.pt>
Mark messages refuse_unconfigured_deny_msg and
refuse_unconfigured_deny_delete_current_msg for translation.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
---
builtin/receive-pack.c | 58 ++++++++++++++++++++++----------------------------
1 file changed, 25 insertions(+), 33 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 011db00..79839d0 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -775,47 +775,39 @@ static int is_ref_checked_out(const char *ref)
return !strcmp(head_name, ref);
}
-static char *refuse_unconfigured_deny_msg[] = {
- "By default, updating the current branch in a non-bare repository",
- "is denied, because it will make the index and work tree inconsistent",
- "with what you pushed, and will require 'git reset --hard' to match",
- "the work tree to HEAD.",
- "",
- "You can set 'receive.denyCurrentBranch' configuration variable to",
- "'ignore' or 'warn' in the remote repository to allow pushing into",
- "its current branch; however, this is not recommended unless you",
- "arranged to update its work tree to match what you pushed in some",
- "other way.",
- "",
- "To squelch this message and still keep the default behaviour, set",
- "'receive.denyCurrentBranch' configuration variable to 'refuse'."
-};
+static char *refuse_unconfigured_deny_msg =
+ N_("By default, updating the current branch in a non-bare repository\n"
+ "is denied, because it will make the index and work tree inconsistent\n"
+ "with what you pushed, and will require 'git reset --hard' to match\n"
+ "the work tree to HEAD.\n"
+ "\n"
+ "You can set 'receive.denyCurrentBranch' configuration variable to\n"
+ "'ignore' or 'warn' in the remote repository to allow pushing into\n"
+ "its current branch; however, this is not recommended unless you\n"
+ "arranged to update its work tree to match what you pushed in some\n"
+ "other way.\n"
+ "\n"
+ "To squelch this message and still keep the default behaviour, set\n"
+ "'receive.denyCurrentBranch' configuration variable to 'refuse'.");
static void refuse_unconfigured_deny(void)
{
- int i;
- for (i = 0; i < ARRAY_SIZE(refuse_unconfigured_deny_msg); i++)
- rp_error("%s", refuse_unconfigured_deny_msg[i]);
+ rp_error("%s", _(refuse_unconfigured_deny_msg));
}
-static char *refuse_unconfigured_deny_delete_current_msg[] = {
- "By default, deleting the current branch is denied, because the next",
- "'git clone' won't result in any file checked out, causing confusion.",
- "",
- "You can set 'receive.denyDeleteCurrent' configuration variable to",
- "'warn' or 'ignore' in the remote repository to allow deleting the",
- "current branch, with or without a warning message.",
- "",
- "To squelch this message, you can set it to 'refuse'."
-};
+static char *refuse_unconfigured_deny_delete_current_msg =
+ N_("By default, deleting the current branch is denied, because the next\n"
+ "'git clone' won't result in any file checked out, causing confusion.\n"
+ "\n"
+ "You can set 'receive.denyDeleteCurrent' configuration variable to\n"
+ "'warn' or 'ignore' in the remote repository to allow deleting the\n"
+ "current branch, with or without a warning message.\n"
+ "\n"
+ "To squelch this message, you can set it to 'refuse'.");
static void refuse_unconfigured_deny_delete_current(void)
{
- int i;
- for (i = 0;
- i < ARRAY_SIZE(refuse_unconfigured_deny_delete_current_msg);
- i++)
- rp_error("%s", refuse_unconfigured_deny_delete_current_msg[i]);
+ rp_error("%s", _(refuse_unconfigured_deny_delete_current_msg));
}
static int command_singleton_iterator(void *cb_data, unsigned char sha1[20]);
--
2.7.4
^ permalink raw reply related
* [PATCH 05/13] i18n: branch: mark option description for translation
From: Vasco Almeida @ 2016-09-07 14:49 UTC (permalink / raw)
To: git; +Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason
In-Reply-To: <1473259758-11836-1-git-send-email-vascomalmeida@sapo.pt>
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
---
builtin/branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 7df0543..d5d93a8 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -657,7 +657,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_SET_INT( 0, "set-upstream", &track, N_("change upstream info"),
BRANCH_TRACK_OVERRIDE),
OPT_STRING('u', "set-upstream-to", &new_upstream, N_("upstream"), N_("change the upstream info")),
- OPT_BOOL(0, "unset-upstream", &unset_upstream, "Unset the upstream info"),
+ OPT_BOOL(0, "unset-upstream", &unset_upstream, N_("Unset the upstream info")),
OPT__COLOR(&branch_use_color, N_("use colored output")),
OPT_SET_INT('r', "remotes", &filter.kind, N_("act on remote-tracking branches"),
FILTER_REFS_REMOTES),
--
2.7.4
^ permalink raw reply related
* [PATCH 04/13] i18n: blame: mark error messages for translation
From: Vasco Almeida @ 2016-09-07 14:49 UTC (permalink / raw)
To: git; +Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason
In-Reply-To: <1473259758-11836-1-git-send-email-vascomalmeida@sapo.pt>
Mark error messages for translation passed to die() function.
Change "Cannot" to lowercase following the usual style.
Reflect changes to test by using test_i18ngrep.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
---
builtin/blame.c | 12 ++++++------
t/t8003-blame-corner-cases.sh | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index a5bbf91..3fee197 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2601,7 +2601,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
if (incremental || (output_option & OUTPUT_PORCELAIN)) {
if (show_progress > 0)
- die("--progress can't be used with --incremental or porcelain formats");
+ die(_("--progress can't be used with --incremental or porcelain formats"));
show_progress = 0;
} else if (show_progress < 0)
show_progress = isatty(2);
@@ -2727,7 +2727,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
sb.commits.compare = compare_commits_by_commit_date;
}
else if (contents_from)
- die("--contents and --reverse do not blend well.");
+ die(_("--contents and --reverse do not blend well."));
else {
final_commit_name = prepare_initial(&sb);
sb.commits.compare = compare_commits_by_reverse_commit_date;
@@ -2747,12 +2747,12 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
add_pending_object(&revs, &(sb.final->object), ":");
}
else if (contents_from)
- die("Cannot use --contents with final commit object name");
+ die(_("cannot use --contents with final commit object name"));
if (reverse && revs.first_parent_only) {
final_commit = find_single_final(sb.revs, NULL);
if (!final_commit)
- die("--reverse and --first-parent together require specified latest commit");
+ die(_("--reverse and --first-parent together require specified latest commit"));
}
/*
@@ -2779,7 +2779,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
}
if (oidcmp(&c->object.oid, &sb.final->object.oid))
- die("--reverse --first-parent together require range along first-parent chain");
+ die(_("--reverse --first-parent together require range along first-parent chain"));
}
if (is_null_oid(&sb.final->object.oid)) {
@@ -2820,7 +2820,7 @@ int cmd_blame(int argc, const char **argv, const char *prefix)
&bottom, &top, sb.path))
usage(blame_usage);
if (lno < top || ((lno || bottom) && lno < bottom))
- die("file %s has only %lu lines", path, lno);
+ die(_("file %s has only %lu lines"), path, lno);
if (bottom < 1)
bottom = 1;
if (top < 1)
diff --git a/t/t8003-blame-corner-cases.sh b/t/t8003-blame-corner-cases.sh
index e48370d..661f9d4 100755
--- a/t/t8003-blame-corner-cases.sh
+++ b/t/t8003-blame-corner-cases.sh
@@ -212,12 +212,12 @@ EOF
test_expect_success 'blame -L with invalid start' '
test_must_fail git blame -L5 tres 2>errors &&
- grep "has only 2 lines" errors
+ test_i18ngrep "has only 2 lines" errors
'
test_expect_success 'blame -L with invalid end' '
test_must_fail git blame -L1,5 tres 2>errors &&
- grep "has only 2 lines" errors
+ test_i18ngrep "has only 2 lines" errors
'
test_expect_success 'blame parses <end> part of -L' '
--
2.7.4
^ permalink raw reply related
* [PATCH 02/13] i18n: apply: mark error messages for translation
From: Vasco Almeida @ 2016-09-07 14:49 UTC (permalink / raw)
To: git; +Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason
In-Reply-To: <1473259758-11836-1-git-send-email-vascomalmeida@sapo.pt>
Mark error messages for translation passed to error() and die()
functions.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
---
builtin/apply.c | 46 +++++++++++++++++++++++-----------------------
1 file changed, 23 insertions(+), 23 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index ef03c74..ef2c084 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3065,8 +3065,8 @@ static int apply_binary_fragment(struct apply_state *state,
/* Binary patch is irreversible without the optional second hunk */
if (state->apply_in_reverse) {
if (!fragment->next)
- return error("cannot reverse-apply a binary patch "
- "without the reverse hunk to '%s'",
+ return error(_("cannot reverse-apply a binary patch "
+ "without the reverse hunk to '%s'"),
patch->new_name
? patch->new_name : patch->old_name);
fragment = fragment->next;
@@ -3111,8 +3111,8 @@ static int apply_binary(struct apply_state *state,
strlen(patch->new_sha1_prefix) != 40 ||
get_sha1_hex(patch->old_sha1_prefix, sha1) ||
get_sha1_hex(patch->new_sha1_prefix, sha1))
- return error("cannot apply binary patch to '%s' "
- "without full index line", name);
+ return error(_("cannot apply binary patch to '%s' "
+ "without full index line"), name);
if (patch->old_name) {
/*
@@ -3121,16 +3121,16 @@ static int apply_binary(struct apply_state *state,
*/
hash_sha1_file(img->buf, img->len, blob_type, sha1);
if (strcmp(sha1_to_hex(sha1), patch->old_sha1_prefix))
- return error("the patch applies to '%s' (%s), "
- "which does not match the "
- "current contents.",
+ return error(_("the patch applies to '%s' (%s), "
+ "which does not match the "
+ "current contents."),
name, sha1_to_hex(sha1));
}
else {
/* Otherwise, the old one must be empty. */
if (img->len)
- return error("the patch applies to an empty "
- "'%s' but it is not empty", name);
+ return error(_("the patch applies to an empty "
+ "'%s' but it is not empty"), name);
}
get_sha1_hex(patch->new_sha1_prefix, sha1);
@@ -3147,8 +3147,8 @@ static int apply_binary(struct apply_state *state,
result = read_sha1_file(sha1, &type, &size);
if (!result)
- return error("the necessary postimage %s for "
- "'%s' cannot be read",
+ return error(_("the necessary postimage %s for "
+ "'%s' cannot be read"),
patch->new_sha1_prefix, name);
clear_image(img);
img->buf = result;
@@ -3523,7 +3523,7 @@ static int try_threeway(struct apply_state *state,
write_sha1_file("", 0, blob_type, pre_sha1);
else if (get_sha1(patch->old_sha1_prefix, pre_sha1) ||
read_blob_object(&buf, pre_sha1, patch->old_mode))
- return error("repository lacks the necessary blob to fall back on 3-way merge.");
+ return error(_("repository lacks the necessary blob to fall back on 3-way merge."));
fprintf(stderr, "Falling back to three-way merge...\n");
@@ -3541,11 +3541,11 @@ static int try_threeway(struct apply_state *state,
/* our_sha1[] is ours */
if (patch->is_new) {
if (load_current(state, &tmp_image, patch))
- return error("cannot read the current contents of '%s'",
+ return error(_("cannot read the current contents of '%s'"),
patch->new_name);
} else {
if (load_preimage(state, &tmp_image, patch, st, ce))
- return error("cannot read the current contents of '%s'",
+ return error(_("cannot read the current contents of '%s'"),
patch->old_name);
}
write_sha1_file(tmp_image.buf, tmp_image.len, blob_type, our_sha1);
@@ -4020,29 +4020,29 @@ static void build_fake_ancestor(struct patch *list, const char *filename)
if (!preimage_sha1_in_gitlink_patch(patch, sha1))
; /* ok, the textual part looks sane */
else
- die("sha1 information is lacking or useless for submodule %s",
+ die(_("sha1 information is lacking or useless for submodule %s"),
name);
} else if (!get_sha1_blob(patch->old_sha1_prefix, sha1)) {
; /* ok */
} else if (!patch->lines_added && !patch->lines_deleted) {
/* mode-only change: update the current */
if (get_current_sha1(patch->old_name, sha1))
- die("mode change for %s, which is not "
- "in current HEAD", name);
+ die(_("mode change for %s, which is not "
+ "in current HEAD"), name);
} else
- die("sha1 information is lacking or useless "
- "(%s).", name);
+ die(_("sha1 information is lacking or useless "
+ "(%s)."), name);
ce = make_cache_entry(patch->old_mode, sha1, name, 0, 0);
if (!ce)
die(_("make_cache_entry failed for path '%s'"), name);
if (add_index_entry(&result, ce, ADD_CACHE_OK_TO_ADD))
- die ("Could not add %s to temporary index", name);
+ die(_("Could not add %s to temporary index"), name);
}
hold_lock_file_for_update(&lock, filename, LOCK_DIE_ON_ERROR);
if (write_locked_index(&result, &lock, COMMIT_LOCK))
- die ("Could not write temporary index to %s", filename);
+ die(_("Could not write temporary index to %s"), filename);
discard_index(&result);
}
@@ -4693,9 +4693,9 @@ static void check_apply_state(struct apply_state *state, int force_apply)
int is_not_gitdir = !startup_info->have_repository;
if (state->apply_with_reject && state->threeway)
- die("--reject and --3way cannot be used together.");
+ die(_("--reject and --3way cannot be used together."));
if (state->cached && state->threeway)
- die("--cached and --3way cannot be used together.");
+ die(_("--cached and --3way cannot be used together."));
if (state->threeway) {
if (is_not_gitdir)
die(_("--3way outside a repository"));
--
2.7.4
^ permalink raw reply related
* [PATCH 03/13] i18n: apply: mark info messages for translation
From: Vasco Almeida @ 2016-09-07 14:49 UTC (permalink / raw)
To: git; +Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason
In-Reply-To: <1473259758-11836-1-git-send-email-vascomalmeida@sapo.pt>
Mark messages for translation printed to stderr.
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
---
builtin/apply.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index ef2c084..43ab7c5 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -3525,7 +3525,7 @@ static int try_threeway(struct apply_state *state,
read_blob_object(&buf, pre_sha1, patch->old_mode))
return error(_("repository lacks the necessary blob to fall back on 3-way merge."));
- fprintf(stderr, "Falling back to three-way merge...\n");
+ fprintf(stderr, _("Falling back to three-way merge...\n"));
img = strbuf_detach(&buf, &len);
prepare_image(&tmp_image, img, len, 1);
@@ -3555,7 +3555,7 @@ static int try_threeway(struct apply_state *state,
status = three_way_merge(image, patch->new_name,
pre_sha1, our_sha1, post_sha1);
if (status < 0) {
- fprintf(stderr, "Failed to fall back on three-way merge...\n");
+ fprintf(stderr, _("Failed to fall back on three-way merge...\n"));
return status;
}
@@ -3567,9 +3567,9 @@ static int try_threeway(struct apply_state *state,
hashcpy(patch->threeway_stage[0].hash, pre_sha1);
hashcpy(patch->threeway_stage[1].hash, our_sha1);
hashcpy(patch->threeway_stage[2].hash, post_sha1);
- fprintf(stderr, "Applied patch to '%s' with conflicts.\n", patch->new_name);
+ fprintf(stderr, _("Applied patch to '%s' with conflicts.\n"), patch->new_name);
} else {
- fprintf(stderr, "Applied patch to '%s' cleanly.\n", patch->new_name);
+ fprintf(stderr, _("Applied patch to '%s' cleanly.\n"), patch->new_name);
}
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 01/13] i18n: apply: mark plural string for translation
From: Vasco Almeida @ 2016-09-07 14:49 UTC (permalink / raw)
To: git; +Cc: Vasco Almeida, Jiang Xin, Ævar Arnfjörð Bjarmason
Mark plural string for translation using Q_().
Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt>
---
builtin/apply.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/builtin/apply.c b/builtin/apply.c
index 1a488f9..ef03c74 100644
--- a/builtin/apply.c
+++ b/builtin/apply.c
@@ -4768,10 +4768,12 @@ static int apply_all_patches(struct apply_state *state,
state->whitespace_error),
state->whitespace_error);
if (state->applied_after_fixing_ws && state->apply)
- warning("%d line%s applied after"
- " fixing whitespace errors.",
- state->applied_after_fixing_ws,
- state->applied_after_fixing_ws == 1 ? "" : "s");
+ warning(Q_("%d line applied after"
+ " fixing whitespace errors.",
+ "%d lines applied after"
+ " fixing whitespace errors.",
+ state->applied_after_fixing_ws),
+ state->applied_after_fixing_ws);
else if (state->whitespace_error)
warning(Q_("%d line adds whitespace errors.",
"%d lines add whitespace errors.",
--
2.7.4
^ permalink raw reply related
* segfault in http.c when https URL is mistyped
From: Lars Wendler @ 2016-09-07 13:44 UTC (permalink / raw)
To: git; +Cc: Robin H. Johnson, lekto
In-Reply-To: <20160907151607.2b288034@abudhabi.paradoxon.rec>
[-- Attachment #1: Type: text/plain, Size: 761 bytes --]
Hi,
we at Gentoo got a bug report [1] about git-remote-https segfaulting
when the URL has been mistyped.
This seems to only be triggered when git was compiled with curl
support:
git clone https::/some.example-site.net/test.git
Observe the "https::/" instead of "https://". As soon as you run such a
command, syslog receives a message like:
kernel: git-remote-http[8766]: segfault at 0 ip 0000000000408abd sp
00007ffd70adf7c0 error 4 in git-remote-https[400000+103000]
Kind regards
Lars
[1] https://bugs.gentoo.org/592522
--
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93 9F68 498F E765 960E 9B39
Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html
[-- Attachment #2: Digitale Signatur von OpenPGP --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v1 2/2] read-cache: make sure file handles are not inherited by child processes
From: Lars Schneider @ 2016-09-07 13:39 UTC (permalink / raw)
To: Eric Wong; +Cc: Git Mailing List, gitster, tboegi, Johannes.Schindelin
In-Reply-To: <20160906210632.GA28263@starla>
> On 06 Sep 2016, at 23:06, Eric Wong <e@80x24.org> wrote:
>
> larsxschneider@gmail.com wrote:
>> static int ce_compare_data(const struct cache_entry *ce, struct stat *st)
>> {
>> int match = -1;
>> - int fd = open(ce->name, O_RDONLY);
>> + int fd = open(ce->name, O_RDONLY | O_CLOEXEC);
>>
>> if (fd >= 0) {
>> unsigned char sha1[20];
>
> Also, this needs to check EINVAL when O_CLOEXEC != 0 the same
> way create_tempfile currently does. Somebody could be building
> with modern headers but running an old kernel that doesn't
> understand O_CLOEXEC.
>
> There should probably be a open() wrapper for handling this case
> since we're now up to 3 places where open(... O_CLOEXEC) is
> used.
Right! Actually "sha1_file.c:git_open_noatime()" is already a wrapper, no?
Can't we use this here? The O_NOATIME flag shouldn't hurt, right?
Thanks,
Lars
^ permalink raw reply
* Re: [PATCH v1 1/2] sha1_file: open window into packfiles with CLOEXEC
From: Lars Schneider @ 2016-09-07 13:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eric Wong, git, gitster, tboegi
In-Reply-To: <alpine.DEB.2.20.1609061333030.129229@virtualbox>
> On 06 Sep 2016, at 13:38, Johannes Schindelin <johannes.schindelin@gmx.de> wrote:
>
> Hi Eric & Lars,
>
> On Mon, 5 Sep 2016, Eric Wong wrote:
>
>> larsxschneider@gmail.com wrote:
>>> All processes that the Git main process spawns inherit the open file
>>> descriptors of the main process. These leaked file descriptors can
>>> cause problems.
>>
>>
>>> -int git_open_noatime(const char *name)
>>> +int git_open_noatime_cloexec(const char *name)
>>> {
>>> - static int sha1_file_open_flag = O_NOATIME;
>>> + static int sha1_file_open_flag = O_NOATIME | O_CLOEXEC;
>>>
>>> for (;;) {
>>> int fd;
>
>> I question the need for the "_cloexec" suffixing in the
>> function name since the old function is going away entirely.
>
> Me, too. While it is correct, it makes things harder to read, so it may
> even cause more harm than it does good.
What name would you suggest? Leaving the name as-is seems misleading to me.
Maybe just "git_open()" ?
>> I prefer all FD-creating functions set cloexec by default
>> for FD > 2 to avoid inadvertantly leaking FDs. So we
>> ought to use pipe2, accept4, socket(..., SOCK_CLOEXEC), etc...
>> and fallback to the racy+slower F_SETFD when not available.
>
> In the original Pull Request where the change was contributed to Git for
> Windows, this was tested (actually, the code did not see whether fd > 2,
> but simply assumed that all newly opened file descriptors would be > 2
> anyway), and it failed:
>
> https://github.com/git-for-windows/git/pull/755#issuecomment-220247972
>
> So it appears that we would have to exclude at least the code path to `git
> upload-pack` from that magic.
I just realized that Dscho improved his original patch in GfW with a
fallback if CLOEXEC is not present.
I applied the same mechanism here. Would that be OK?
Thanks,
Lars
- static int sha1_file_open_flag = O_NOATIME;
+ static int sha1_file_open_flag = O_NOATIME | O_CLOEXEC;
for (;;) {
int fd;
@@ -1471,12 +1471,17 @@ int git_open_noatime(const char *name)
if (fd >= 0)
return fd;
- /* Might the failure be due to O_NOATIME? */
- if (errno != ENOENT && sha1_file_open_flag) {
- sha1_file_open_flag = 0;
+ /* Try again w/o O_CLOEXEC: the kernel might not support it */
+ if (O_CLOEXEC && errno == EINVAL && (sha1_file_open_flag & O_CLOEXEC)) {
+ sha1_file_open_flag &= ~O_CLOEXEC;
continue;
}
+ /* Might the failure be due to O_NOATIME? */
+ if (errno != ENOENT && (sha1_file_open_flag & O_NOATIME)) {
+ sha1_file_open_flag &= ~O_NOATIME;
+ continue;
+ }
^ permalink raw reply
* Re: [RFC/PATCH 0/2] more patch-id speedups
From: Johannes Schindelin @ 2016-09-07 13:06 UTC (permalink / raw)
To: Jeff King; +Cc: git, Michael Haggerty, Kevin Willford
In-Reply-To: <20160907075346.z6wtmqnfc6bsunjb@sigill.intra.peff.net>
Hi Peff,
On Wed, 7 Sep 2016, Jeff King wrote:
> Michael and I found a case where the "format-patch --cherry-pick A...B"
> command for a rebase took over 7 minutes to run with git v2.9.3. Yikes.
>
> Switching to v2.10 dropped that to a bit over 3 minutes (due to the
> kw/patch-ids-optim topic). Better, but not great.
I agree: not great, but better...
> The culprit turned out to be merge commits; the patch-id code will
> happily diff a merge against its first parent, and ignore the rest. This
> _seems_ like a bad idea, but maybe there is something clever going on
> that I don't know about. I couldn't find anything useful in the history,
> and given that this code was adapted from rebase, my guess is that it
> was never really intended to handle merge commits in the first place (of
> course we weren't trying to rebase merge commits; but it has to generate
> patch-ids for everything that happened on "A" to compare against).
>
> Dropping the computation of the merge commits got it down to about 4
> seconds. I also noticed that it was doing rename detection (which also
> seems like a bad idea). Disabling renames dropped another half second or
> so.
That makes for a really nice improvement!
> This is marked as "RFC" because I don't feel entirely confident that I'm
> not missing some clever need for these options. But in both cases my gut
> feeling is that they are simply unintended effects that nobody ever
> noticed, because it would be very rare that they would affect the
> output. And that if they _did_ affect the output, they would probably be
> doing the wrong thing.
Given that the patch ID is *wrong* for merge commits (it only looks at the
first parent, so each "-s ours" merge will have the same patch ID!), I
would say that we can get away with re-defining the patch ID of merge
commits.
The only case where it might change things that I can think of would be a
`git rebase --preserve-merges`: it would probably have worked *by chance*
before (or not, in case of "-s ours" merges), and now it would try to pick
the merge commits even if rebased versions were already merged upstream.
If I read the --preserve-merges code correctly, that would result in the
merge commit's parents to be 'rewritten' to HEAD. And as both parents
would be rewritten to HEAD, they would be condensed into a single new
parent, resulting in a cherry-pick that fails (because it tries to
cherry-pick a merge commit without any -n option).
Of course, what we could do is to introduce a modifier, e.g.
--cherry-pick=first-parent, that would trigger the old behavior and would
be asked-for in the --preserve-merges mode.
But quite frankly, personally I would not worry about it *that* much. As
you pointed out, the patch ID for merge commits is incorrect to begin
with, and we may just redeclare all merge commits to be incomparable to
one another when it comes to patch IDs.
In short: I would be fine with the change of behavior.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] patch-ids: turn off rename detection
From: Johannes Schindelin @ 2016-09-07 12:53 UTC (permalink / raw)
To: Jeff King; +Cc: git, Michael Haggerty, Kevin Willford
In-Reply-To: <20160907075411.cr67cbvmy7gxv2om@sigill.intra.peff.net>
Hi Peff,
On Wed, 7 Sep 2016, Jeff King wrote:
> The patch-id code may be running inside another porcelain
> like "git log" or "git format-patch", and therefore may have
> set diff_detect_rename_default, either via the diff-ui
> config, or by default since 5404c11 (diff: activate
> diff.renames by default, 2016-02-25). This is the case even
> if a command is run with `--no-renames`, as that is applied
> only to the diff-options used by the command itself.
>
> Rename detection doesn't help the patch-id results. It
> _may_ actually hurt, as minor differences in the files that
> would be overlooked by patch-id's canonicalization might
> result in different renames (though I'd doubt that it ever
> comes up in practice).
>
> But mostly it is just a waste of CPU to compute these
> renames.
>
> Note that we don't have to worry about compatibility here.
> This patch disables renames just for the internal patch-id
> comparison run by "log --cherry-pick", etc. The user-visible
> "git patch-id" output depends on the patch that it is fed
> (so it is up to the diff generator to use --no-renames if
> they wish).
Sounds obviously good to me.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] patch-ids: skip merge commits
From: Johannes Schindelin @ 2016-09-07 12:52 UTC (permalink / raw)
To: Jeff King; +Cc: git, Michael Haggerty, Kevin Willford
In-Reply-To: <20160907075425.6jgamuwm66xbklu3@sigill.intra.peff.net>
Hi Peff,
On Wed, 7 Sep 2016, Jeff King wrote:
> [...]
> This patch just ignores merge commits entirely when
> generating patch-ids, meaning they will never be matched
> (from either side of a symmetric-diff traversal).
... except it does not ignore merge commits:
> diff --git a/patch-ids.c b/patch-ids.c
> index 77e4663..b1f8514 100644
> --- a/patch-ids.c
> +++ b/patch-ids.c
> @@ -7,10 +7,12 @@
> int commit_patch_id(struct commit *commit, struct diff_options *options,
> unsigned char *sha1, int diff_header_only)
> {
> - if (commit->parents)
> + if (commit->parents) {
> + if (commit->parents->next)
> + return 0;
> diff_tree_sha1(commit->parents->item->object.oid.hash,
> commit->object.oid.hash, "", options);
> - else
> + } else
With this change, commit_patch_id() will return 0 for merge commits
(indicating success) but it will not have touched the sha1! Which means it
may very well have all kinds of crap in the sha1 that may, or may not,
match another, real patch ID randomly.
See e.g. the call site in builtin/log.c's prepare_bases():
[...]
if (commit_patch_id(commit, &diffopt, sha1, 0))
die(_("cannot get patch id"));
ALLOC_GROW(bases->patch_id, bases->nr_patch_id + 1, bases->alloc_patch_id);
patch_id = bases->patch_id + bases->nr_patch_id;
hashcpy(patch_id->hash, sha1);
bases->nr_patch_id++;
So the sha1 is actually used, even if it was not initialized.
I would suggest to simply copy the merge commit's SHA-1. It is no patch
ID, of course, but collisions are as unlikely as commit name collisions,
and it would make the "patch ID" of a merge commit deterministic again.
I.e. something like
if (commit->parents) {
- if (commit->parents->next)
+ if (commit->parents->next) {
+ hashcpy(sha1, commit->object.oid.hash);
return 0;
+ }
diff_tree_sha1(commit->parents->item->object.oid.hash,
on top.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2 6/6] git-gui: Update Japanese information
From: Satoshi Yasushima @ 2016-09-07 11:47 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narębski, Pat Thoyts,
Satoshi Yasushima
In-Reply-To: <1473177741-9576-6-git-send-email-s.yasushima@gmail.com>
Hmmm.
Although I noticed now become PATCH 3/6 has lost.
There seems to be a cause in the following taboo.
Sure, PATCH 3/6 is little too great.
http://vger.kernel.org/majordomo-info.html#taboo
>Taboo things to be done when discussing at VGER lists
: (abbr.)
> * Message size exceeding 100 000 characters causes blocking.
To somehow.
^ permalink raw reply
* Re: [PATCH v2] t6026-merge-attr: clean up background process at end of test case
From: Johannes Schindelin @ 2016-09-07 11:35 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <1953cc16-7577-16dd-fe7e-f557e7a74f58@kdbg.org>
Hi Hannes,
On Wed, 7 Sep 2016, Johannes Sixt wrote:
> I did not extend the sleep time because it requires to change the file name
> in the same patch.
Yeah, I was just concerned that maybe we would take longer than that
second to finish the test. But I guess I am just too paranoid here.
Thanks for the patch!
Dscho
^ permalink raw reply
* Re: Fixup of a fixup not working right
From: Johannes Schindelin @ 2016-09-07 11:31 UTC (permalink / raw)
To: Philip Oakley; +Cc: Junio C Hamano, Robert Dailey, Git
In-Reply-To: <6C5AB39424064692A416A490B861D330@PhilipOakley>
Hi Philip,
On Tue, 6 Sep 2016, Philip Oakley wrote:
> From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
> >
> > On Sun, 4 Sep 2016, Philip Oakley wrote:
> >
> > > I suspect that some use cases have intermediate repositories that
> > > contain a 'master' branch (it's just a name ;-) that isn't blessed
> > > and golden, e.g. at the team review repo level. In such cases it is
> > > possible for a fixup! to be passed up as part of the review, though
> > > it's not the current norm/expectation.
> >
> > In such a case (which can totally arise when criss-crossing Pull
> > Requests on GitHub, for example, where a Pull Request's purpose may be
> > to fix up commits in another Pull Request before the latter is
> > merged), the most appropriate course of action is... to not reorder
> > the fixup!s prematurely.
>
> We just need to be careful about that plural just there.
>
> If it is multiple fixup!s for the same commit, then I believe they should be
> grouped together at the same point as the first fixup! commit (in their
> original order).
We should they be grouped together? In the final rebase (the one that
actually also includes the commit that is to be rewritten), they will be
grouped together anyway.
And it is not like users cannot regroup manually if they choose to perform
an intermediate rebase. In that case, the user will also choose whether
she wants to simply regroup the fixups, or squash them into a single
fixup, too.
> > > > In short, I am opposed to this change.
> > >
> > > It's not like G4W doesn't need fixup!s on the side branches e.g.
> > > 5eaffe9 ("fixup! Handle new t1501 test case properly with MinGW",
> > > 2016-07-12)
>
> I note that you don't have two fixup!s for that commit
Not for that one, no. But there have been cases where I had to add two or
more fixups for the same commit, in preparation for the next merging
rebase.
> > Yeah, well, Git for Windows' `master` branch is special, in that it is
> > constantly rebased (as "merging rebases", to keep
> > fast-forwardability). I would not necessarily use Git for Windows as a
> > role model in this respect.
>
> I don't see GfW as 'special', rather as being a representative of a
> broader realpolitik where some of the rugged individualism of open
> source is moderated in some way or another.
Sure, it is an example of a project that needs to solve the problem where
patch series are accumulated, to be submitted to an upstream project, and
so we have to keep fast-forwardability at the same time as we have to
rebase.
But Git for Windows is special in the way it solves the problem. I am not
aware of anybody else performing merging rebases.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 3/3] checkout: fix ambiguity check in subdir
From: Nguyễn Thái Ngọc Duy @ 2016-09-07 11:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <20160907111941.2342-1-pclouds@gmail.com>
The two functions in parse_branchname_arg(), verify_non_filename and
check_filename, need correct prefix in order to reconstruct the paths
and check for their existence. With NULL prefix, they just check paths
at top dir instead.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/checkout.c | 4 ++--
t/t2010-checkout-ambiguous.sh | 9 +++++++++
t/t2024-checkout-dwim.sh | 12 ++++++++++++
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 1f71d06..53c7284 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -985,7 +985,7 @@ static int parse_branchname_arg(int argc, const char **argv,
int recover_with_dwim = dwim_new_local_branch_ok;
if (!has_dash_dash &&
- (check_filename(NULL, arg) || !no_wildcard(arg)))
+ (check_filename(opts->prefix, arg) || !no_wildcard(arg)))
recover_with_dwim = 0;
/*
* Accept "git checkout foo" and "git checkout foo --"
@@ -1046,7 +1046,7 @@ static int parse_branchname_arg(int argc, const char **argv,
* it would be extremely annoying.
*/
if (argc)
- verify_non_filename(NULL, arg);
+ verify_non_filename(opts->prefix, arg);
} else {
argcount++;
argv++;
diff --git a/t/t2010-checkout-ambiguous.sh b/t/t2010-checkout-ambiguous.sh
index e76e84a..2e47fe0 100755
--- a/t/t2010-checkout-ambiguous.sh
+++ b/t/t2010-checkout-ambiguous.sh
@@ -41,6 +41,15 @@ test_expect_success 'check ambiguity' '
test_must_fail git checkout world all
'
+test_expect_success 'check ambiguity in subdir' '
+ mkdir sub &&
+ # not ambiguous because sub/world does not exist
+ git -C sub checkout world ../all &&
+ echo hello >sub/world &&
+ # ambiguous because sub/world does exist
+ test_must_fail git -C sub checkout world ../all
+'
+
test_expect_success 'disambiguate checking out from a tree-ish' '
echo bye > world &&
git checkout world -- world &&
diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh
index 468a000..3e5ac81 100755
--- a/t/t2024-checkout-dwim.sh
+++ b/t/t2024-checkout-dwim.sh
@@ -174,6 +174,18 @@ test_expect_success 'checkout of branch with a file having the same name fails'
test_branch master
'
+test_expect_success 'checkout of branch with a file in subdir having the same name fails' '
+ git checkout -B master &&
+ test_might_fail git branch -D spam &&
+
+ >spam &&
+ mkdir sub &&
+ mv spam sub/spam &&
+ test_must_fail git -C sub checkout spam &&
+ test_must_fail git rev-parse --verify refs/heads/spam &&
+ test_branch master
+'
+
test_expect_success 'checkout <branch> -- succeeds, even if a file with the same name exists' '
git checkout -B master &&
test_might_fail git branch -D spam &&
--
2.8.2.524.g6ff3d78
^ permalink raw reply related
* [PATCH 2/3] checkout.txt: document a common case that ignores ambiguation rules
From: Nguyễn Thái Ngọc Duy @ 2016-09-07 11:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <20160907111941.2342-1-pclouds@gmail.com>
Normally we err on the safe side: if something can be seen as both an
SHA1 and a pathspec, we stop and scream. In checkout, there is one
exception added in 859fdab (git-checkout: improve error messages, detect
ambiguities. - 2008-07-23), to allow the common case "git checkout
branch". Let's document this exception.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/git-checkout.txt | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 7a2201b..94eb238 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -419,6 +419,15 @@ $ git reflog -2 HEAD # or
$ git log -g -2 HEAD
------------
+ARGUMENT AMBIGUATION
+--------------------
+
+When there is only one argument given and it is not `--` (e.g. "git
+checkout abc"), "abc" could be seen as either a `<tree-ish>` or a
+`<pathspec>`, but Git will assume the argument is a `<tree-ish>`, which is
+a common case for switching branches. Use `git checkout -- <pathspec>`
+form if you mean it to be a pathspec.
+
EXAMPLES
--------
--
2.8.2.524.g6ff3d78
^ permalink raw reply related
* [PATCH 1/3] checkout: add some spaces between code and comment
From: Nguyễn Thái Ngọc Duy @ 2016-09-07 11:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <20160907111941.2342-1-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin/checkout.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 8672d07..1f71d06 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1038,7 +1038,7 @@ static int parse_branchname_arg(int argc, const char **argv,
if (!*source_tree) /* case (1): want a tree */
die(_("reference is not a tree: %s"), arg);
- if (!has_dash_dash) {/* case (3).(d) -> (1) */
+ if (!has_dash_dash) { /* case (3).(d) -> (1) */
/*
* Do not complain the most common case
* git checkout branch
--
2.8.2.524.g6ff3d78
^ permalink raw reply related
* [PATCH 0/3] fix checkout ambiguation in subdir
From: Nguyễn Thái Ngọc Duy @ 2016-09-07 11:19 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nguyễn Thái Ngọc Duy
In-Reply-To: <20160822123502.3521-1-pclouds@gmail.com>
I need some more time (which I don't have) to convince myself about
the "git checkout :/abc" patch. But these look like good bug
fix/improvement.
Nguyễn Thái Ngọc Duy (3):
checkout: add some spaces between code and comment
checkout.txt: document a common case that ignores ambiguation rules
checkout: fix ambiguity check in subdir
Documentation/git-checkout.txt | 9 +++++++++
builtin/checkout.c | 6 +++---
t/t2010-checkout-ambiguous.sh | 9 +++++++++
t/t2024-checkout-dwim.sh | 12 ++++++++++++
4 files changed, 33 insertions(+), 3 deletions(-)
--
2.8.2.524.g6ff3d78
^ permalink raw reply
* Re: Why patch is not showed at log?
From: Kevin Daudt @ 2016-09-07 10:28 UTC (permalink / raw)
To: KES; +Cc: git
In-Reply-To: <46301473235989@web8j.yandex.ru>
On Wed, Sep 07, 2016 at 11:13:09AM +0300, KES wrote:
>
> Why I do not see changes at log when 'new line' was added at the end of file?
I'm not sure what you exactly mean, but do you want to see the actual
change the patch introduces in the log output? In that case, you can use
git log --patch to include the diff.
If not, could you please explain what you mean?
Kevin
^ permalink raw reply
* Re: [PATCH] gpg-interface: reflect stderr to stderr
From: Michael J Gruber @ 2016-09-07 9:32 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <20160907083947.b7q7ebe62xsr6447@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 07.09.2016 10:39:
> On Wed, Sep 07, 2016 at 10:27:34AM +0200, Michael J Gruber wrote:
>
>> Now, I can't reproduce C on Linux[*], so there is more involved. It
>> could be that my patch just exposes a problem in our start_command()
>> etc.: run-command.c contains a lot of ifdefing, so possibly quite
>> different code is run on different platforms.
>
> Maybe, though my blind guess is that it is simply that on Linux we can
> open /dev/tty directly, and console-IO on Windows is a bit more
> complicated.
>
> You might also check your GPG versions; between gpg1.x and gpg2, the
> passphrase input handling has been completely revamped.
That's a good point to note.
gpg1 asks for the passphrase (without use-agent), gpg2 always delegates
to gpg-agent (and starts it on demand).
On Linux, gpg-agent says you should
export GPG_TTY=$(tty)
to make gpg-agent find the tty, and claims it's not necessary on Win.
In fact, it's not necessary on Linux either unless you want to use
pinentry-curses.
Alas, be it gpg1.4.21 or gpg2.1.13, whatever pinentry, I do get the
passphrase prompt, even with curses (if GPG_TTY is set, which was
necessary before any patches already).
I put up a request for more input from the reporters in the github
issue. I guess that's the best way to reach them.
>> It would be great if someone with a Windows environment could help our
>> efforts in resolving issue C, by checking what is actually behind[**]: I
>> can't believe that capturing stderr keeps gpg from reading stdin, but
>> who knows. Maybe Jeff of pipe_command() fame? I'll put him on cc.
>
> I know nothing about Windows, but I'd be surprised if gpg is reading
> from stdin, as opposed to /dev/tty. It's probably more to do with how
> gpg finds the "tty" on Windows (presumably it looks at stderr for that).
>
> Anyway, I wrote pipe_command() in such a way as to be prepared for
> exactly this kind of thing, so it would be trivial to extend it to an
> extra descriptor. The trouble is that run_command() doesn't understand
> anything except stdin/stdout/stderr. We can open an extra pipe() before
> calling run_command(), and make sure it is not marked CLOEXEC. I don't
> know if there are other portability concerns, though.
My suggestion to try "--status-fd=3" was meant to test whether the above
could help: If fd=3 helps, then our capturing stderr is not the problem.
(If fd=3 does not help then we still don't know...)
Michael
^ permalink raw reply
* Re: [PATCH v2] rebase -i: improve advice on bad instruction lines
From: Dennis Kaarsemaker @ 2016-09-07 9:28 UTC (permalink / raw)
To: Ralf Thielow, git; +Cc: gitster
In-Reply-To: <20160906185918.21286-1-ralf.thielow@gmail.com>
Hi Ralf,
There are quite a few patch series in flight these days around
interactive rebase. Have you checked for conflicts with those?
On di, 2016-09-06 at 20:59 +0200, Ralf Thielow wrote:
> If we found bad instruction lines in the instruction sheet
> of interactive rebase, we give the user advice on how to
> fix it. However, we don't tell the user what to do afterwards.
> Give the user advice to run 'git rebase --continue' after
> the fix.
>
> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
> ---
> Changes in v2:
> - adjust tests
>
> git-rebase--interactive.sh | 2 +-
> t/t3404-rebase-interactive.sh | 6 +++---
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index b1ba21c..029594e 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -1041,7 +1041,7 @@ The possible behaviours are: ignore, warn,
> error.")"
> # placed before the commit of the next action
> checkout_onto
>
> - warn "$(gettext "You can fix this with 'git rebase
> --edit-todo'.")"
> + warn "$(gettext "You can fix this with 'git rebase
> --edit-todo' and then run 'git rebase --continue'.")"
> die "$(gettext "Or you can abort the rebase with
> 'git rebase --abort'.")"
> fi
> }
> diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-
> interactive.sh
> index 597e94e..e38e296 100755
> --- a/t/t3404-rebase-interactive.sh
> +++ b/t/t3404-rebase-interactive.sh
> @@ -1195,7 +1195,7 @@ To avoid this message, use "drop" to explicitly
> remove a commit.
> Use 'git config rebase.missingCommitsCheck' to change the level of
> warnings.
> The possible behaviours are: ignore, warn, error.
>
> -You can fix this with 'git rebase --edit-todo'.
> +You can fix this with 'git rebase --edit-todo' and then run 'git
> rebase --continue'.
> Or you can abort the rebase with 'git rebase --abort'.
> EOF
>
> @@ -1219,7 +1219,7 @@ cat >expect <<EOF
> Warning: the command isn't recognized in the following line:
> - badcmd $(git rev-list --oneline -1 master~1)
>
> -You can fix this with 'git rebase --edit-todo'.
> +You can fix this with 'git rebase --edit-todo' and then run 'git
> rebase --continue'.
> Or you can abort the rebase with 'git rebase --abort'.
> EOF
>
> @@ -1254,7 +1254,7 @@ cat >expect <<EOF
> Warning: the SHA-1 is missing or isn't a commit in the following
> line:
> - edit XXXXXXX False commit
>
> -You can fix this with 'git rebase --edit-todo'.
> +You can fix this with 'git rebase --edit-todo' and then run 'git
> rebase --continue'.
> Or you can abort the rebase with 'git rebase --abort'.
> EOF
>
^ permalink raw reply
* Re: How to simulate a real checkout to test a new smudge filter?
From: Michael J Gruber @ 2016-09-07 8:52 UTC (permalink / raw)
To: john smith, Torsten Bögershausen; +Cc: git
In-Reply-To: <CAKmQUfbemaid61xPyvNheLM2jVGXGjiyF_x=NZnxkZ=5wccQ=Q@mail.gmail.com>
john smith venit, vidit, dixit 06.09.2016 23:01:
> On 9/6/16, Torsten Bögershausen <tboegi@web.de> wrote:
>> On 06.09.16 19:47, john smith wrote:
>>> I am looking for a way to force smudge filter to run by simulating a
>>> real life checkout. Let's say I just created a new branch and did not
>>> modify any files but want to test my new smudge filter. According to
>>> some answers such as
>>> https://stackoverflow.com/questions/22909620/git-smudge-clean-filter-between-branches
>>> and
>>> https://stackoverflow.com/questions/21652242/git-re-checkout-files-after-creating-smudge-filter
>>> it should be possible by running:
>>>
>>> git checkout HEAD --
>>>
>>> but in doesn't work with git 2.9.0. Method suggested in accepted
>>> answer here
>>> https://stackoverflow.com/questions/17223527/how-do-i-force-git-to-checkout-the-master-branch-and-remove-carriage-returns-aft
>>> works but I don't like because it seems fragile. Is there a safe way
>>> to do what I want to do in Git still today?
>>>
>> It depends what you mean with "safe way".
>
> I want to store all my dotfiles in a single repoitory. The problem is
> that that some specific pieces of these files are different on
> different machines. I have a special .conf file that is different on
> every branch and contains machine-specific definitions of some
> variables such as EMAIL or SMTP server. In my smudge filter I call a
> script which parses .conf file and replace all template variable
> definitions saved in the given file with correct definitions. For
> example in my ~/.bashrc I have this on all branches:
>
> export EMAIL="@EMAIL@"
>
> and in my .conf file on `home' branch
>
> EMAIL=home@address.com
>
> and on `work' branch:
>
> EMAIL=work@address.com
>
> And in .gitattributes on both branches:
>
> bash/.bashrc filter=make-usable
>
> I also have single `master' branch that only contains template
> dotfiles and no .conf. When setting up a new machine I could just
> create a new branch off master branch and add a new .conf.
>
> In turn, clean filter replace all correct definitions in the given
> dotfiles back into template definitions.
>
> I'd prefer smudge/clean filters instead of `make' scripts etc. to
> convert template dotfiles into something usable and back because
> filters:
>
> 1. could be run automatically
>
> 2. do not modify files as shown by `git show HEAD:<file>' and
> therefore no files are reported as modified by git status and also
> there are not conflicts when merging master into work/home branch.
>
> I have problems because with point 1 because apparently smudge filter
> is not run automatically every time when branch is changed if files
> listed in .gitattributes do not change. As the last resort I could
> force smudge/clean filter to run just to keep advantage specified in
> point 2.
I'm afraid smudge/clean are not a good match for your use case:
smudge can do anything that clean removes again, i.e.: if you smudge a
blob, then clean it, it has to be the same blob.
Your smudge filter seems to give different results for the same blob
depending on other variables (your .conf), but git doesn't care as long
as clean output is the same. Also, git cannot possibly know when "it is
time" to rerun smudge.
Maybe "source"-ing .conf files would be an alternative approach for you,
or using hooks?
Cheers
Michael
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox