[PATCH] systemd socket activation support
From: Shawn Landden shawnland...@gmail.com
v1.1: actually test...
Signed-off-by: Shawn Landden sh...@churchofgit.com
---
daemon.c | 35 +++---
git-daemon.service | 7 +++
git-daemon.socket | 9
sd-daemon.c| 132 +
sd-daemon.h| 91
5 files changed, 268 insertions(+), 6 deletions(-)
create mode 100644 git-daemon.service
create mode 100644 git-daemon.socket
create mode 100644 sd-daemon.c
create mode 100644 sd-daemon.h
diff --git a/daemon.c b/daemon.c
index 9ee2187..4677058 100644
--- a/daemon.c
+++ b/daemon.c
@@ -5,6 +5,8 @@
#include strbuf.h
#include string-list.h
+#include sd-daemon.c
+
#ifndef HOST_NAME_MAX
#define HOST_NAME_MAX 256
#endif
@@ -29,6 +31,7 @@ static const char daemon_usage[] =
[--access-hook=path]\n
[--inetd | [--listen=host_or_ipaddr] [--port=n]\n
[--detach] [--user=user [--group=group]]\n
+ [--systemd]\n
[directory...];
/* List of acceptable pathname prefixes */
@@ -1176,11 +1179,21 @@ static void store_pid(const char *path)
}
static int serve(struct string_list *listen_addr, int listen_port,
-struct credentials *cred)
+struct credentials *cred, int systemd_mode)
{
struct socketlist socklist = { NULL, 0, 0 };
+ int i;
+ int n;
+
+ if (systemd_mode) {
+ n = sd_listen_fds(0);
+ ALLOC_GROW(socklist.list, socklist.nr + n, socklist.alloc);
+ for (i = 0; i n; i++)
+ socklist.list[socklist.nr++] = SD_LISTEN_FDS_START + i;
+ }
- socksetup(listen_addr, listen_port, socklist);
+ if (listen_addr-nr 0 || !systemd_mode)
+ socksetup(listen_addr, listen_port, socklist);
if (socklist.nr == 0)
die(unable to allocate any listen sockets on port %u,
listen_port);
@@ -1196,7 +1209,7 @@ int main(int argc, char **argv)
{
int listen_port = 0;
struct string_list listen_addr = STRING_LIST_INIT_NODUP;
- int serve_mode = 0, inetd_mode = 0;
+ int serve_mode = 0, inetd_mode = 0, systemd_mode = 0;
const char *pid_file = NULL, *user_name = NULL, *group_name = NULL;
int detach = 0;
struct credentials *cred = NULL;
@@ -1331,6 +1344,10 @@ int main(int argc, char **argv)
informative_errors = 0;
continue;
}
+ if (!strcmp(arg, --systemd)) {
+ systemd_mode = 1;
+ continue;
+ }
if (!strcmp(arg, --)) {
ok_paths = argv[i+1];
break;
@@ -1349,14 +1366,20 @@ int main(int argc, char **argv)
/* avoid splitting a message in the middle */
setvbuf(stderr, NULL, _IOFBF, 4096);
- if (inetd_mode (detach || group_name || user_name))
- die(--detach, --user and --group are incompatible with
--inetd);
+ if ((inetd_mode || systemd_mode) (detach || group_name || user_name))
+ die(--detach, --user and --group are incompatible with --inetd
and --systemd);
+
+ if (systemd_mode inetd_mode)
+ die(--inetd is incompatible with --systemd);
if (inetd_mode (listen_port || (listen_addr.nr 0)))
die(--listen= and --port= are incompatible with --inetd);
else if (listen_port == 0)
listen_port = DEFAULT_GIT_PORT;
+ if (systemd_mode !sd_booted())
+ die(--systemd passed and not running from systemd);
+
if (group_name !user_name)
die(--group supplied without --user);
@@ -1395,5 +1418,5 @@ int main(int argc, char **argv)
cld_argv[i+1] = argv[i];
cld_argv[argc+1] = NULL;
- return serve(listen_addr, listen_port, cred);
+ return serve(listen_addr, listen_port, cred, systemd_mode);
}
diff --git a/git-daemon.service b/git-daemon.service
new file mode 100644
index 000..b0c99f3
--- /dev/null
+++ b/git-daemon.service
@@ -0,0 +1,7 @@
+[Unit]
+Description=Git Daemon
+
+[Service]
+ExecStart=/usr/lib/git-core/git-daemon --systemd --reuseaddr
--base-path=/var/lib /var/lib/git
+User=gitdaemon
+
diff --git a/git-daemon.socket b/git-daemon.socket
new file mode 100644
index 000..b3dd981
--- /dev/null
+++ b/git-daemon.socket
@@ -0,0 +1,9 @@
+[Unit]
+Description=Git Daemon socket
+
+[Socket]
+ListenStream=9418
+
+[Install]
+WantedBy=sockets.target
+
diff --git a/sd-daemon.c b/sd-daemon.c
new file mode 100644
index 000..653fbf5
--- /dev/null
+++ b/sd-daemon.c
@@ -0,0 +1,132 @@
+/* stripped down version */
+/***
+ Copyright 2010 Lennart Poettering
+
+ Permission is hereby granted, free of charge, to any person
+ obtaining a copy of this software and associated documentation files
+ (the
Re: [PATCH] docs: Clarify what git-rebase's --preserve-merges does
Junio C Hamano gits...@pobox.com writes: Sergey Organov s.orga...@javad.com writes: Nope. It seems like cherry-pick takes care of that: ... What do I miss? The fact that cherry-pick did not flag it as a potential conflict situation where a manual verification is required (the cherry-pick process can be fooled by textual similarity and either add the same thing twice or fail to add one thing that is needed). Well, it was not required in the simple case I tested, and cherry-pick did the right thing. I suspect it will do the right thing (flag a conflict) where manual verification is required. A test-case demonstrating the problem you have in mind, maybe? Anyway, how is it different to cherry-pick merge commit compared to any other commit? I mean, provided we cherry-pick other commits, we already accepted all the possible negative consequences of cherry-picking. How cherry-picking merge commits make this worse? I.e., do you think we have a show-stopper, or just that there are ways to handle merge commits event better than simple cherry-pick -m1? The latter is probably true, but simple cherry-pick still looks much better than what we have now, no? -- Sergey. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] systemd socket activation support
On Wed, Apr 1, 2015 at 9:23 PM, Shawn Landden sh...@churchofgit.com wrote:
From: Shawn Landden shawnland...@gmail.com
[PATCH] systemd socket activation support
This patch feels like an RFC rather than a properly fleshed-out
submission. If so, indicate such in the subject. Also, mention the
area you're touching, followed by a colon, followed by the summary of
the change:
[PATCH/RFC] daemon: add systemd support
The commit message may be a bit lacking. You might want to explain why
this is desirable, perhaps mentioning that this complements existing
inetd support, and (for the uninitiated) how it differs from inetd
support (possibly citing documentation). It might also be a good idea
to mention that sd-daemon.[ch] are foreign imports (possibly citing
the source).
Signed-off-by: Shawn Landden sh...@churchofgit.com
The Signed-off-by: email address differs from your From: address.
---
daemon.c | 38 ---
git-daemon.service | 6 +++
git-daemon.socket | 9
sd-daemon.c| 132
+
sd-daemon.h| 91
Necessary Documentation/git-daemon.txt changes are missing.
Makefile changes are likely missing.
More below.
diff --git a/daemon.c b/daemon.c
index 9ee2187..56b3cd4 100644
--- a/daemon.c
+++ b/daemon.c
@@ -5,6 +5,8 @@
#include strbuf.h
#include string-list.h
+#include sd-daemon.c
This is kind of weird. Why this rather than the more typical approach
of including sd-daemon.h here, compiling sd-daemon.c separately, and
then combining them at link time? If there really is a good reason for
this arrangement, it's probably worthwhile explaining it in the commit
message.
#ifndef HOST_NAME_MAX
#define HOST_NAME_MAX 256
#endif
@@ -29,6 +31,7 @@ static const char daemon_usage[] =
[--access-hook=path]\n
[--inetd | [--listen=host_or_ipaddr] [--port=n]\n
[--detach] [--user=user [--group=group]]\n
+ [--systemd]\n
[directory...];
/* List of acceptable pathname prefixes */
@@ -1176,11 +1179,21 @@ static void store_pid(const char *path)
}
static int serve(struct string_list *listen_addr, int listen_port,
-struct credentials *cred)
+struct credentials *cred, int systemd_mode)
{
struct socketlist socklist = { NULL, 0, 0 };
+ int i;
+ int n;
These variables are used only within the 'if (systemd_mode)' scope,
thus can be declared there.
More below.
- socksetup(listen_addr, listen_port, socklist);
+ if (systemd_mode) {
+ n = sd_listen_fds(0);
+ ALLOC_GROW(socklist.list, socklist.nr + n, socklist.alloc);
+ for (i = 0; i n; i++)
+ socklist.list[socklist.nr++] = SD_LISTEN_FDS_START +
i;
+ }
+
+ if (listen_addr || !systemd_mode)
+ socksetup(listen_addr, listen_port, socklist);
if (socklist.nr == 0)
die(unable to allocate any listen sockets on port %u,
listen_port);
@@ -1196,7 +1209,7 @@ int main(int argc, char **argv)
{
int listen_port = 0;
struct string_list listen_addr = STRING_LIST_INIT_NODUP;
- int serve_mode = 0, inetd_mode = 0;
+ int serve_mode = 0, inetd_mode = 0, systemd_mode = 0;
const char *pid_file = NULL, *user_name = NULL, *group_name = NULL;
int detach = 0;
struct credentials *cred = NULL;
@@ -1331,6 +1344,10 @@ int main(int argc, char **argv)
informative_errors = 0;
continue;
}
+ if (!strcmp(arg, --systemd)) {
+ systemd_mode = 1;
+ continue;
+ }
if (!strcmp(arg, --)) {
ok_paths = argv[i+1];
break;
@@ -1349,14 +1366,23 @@ int main(int argc, char **argv)
/* avoid splitting a message in the middle */
setvbuf(stderr, NULL, _IOFBF, 4096);
- if (inetd_mode (detach || group_name || user_name))
- die(--detach, --user and --group are incompatible with
--inetd);
+ if ((inetd_mode || systemd-mode) (detach || group_name ||
user_name))
I can't see how a variable named 'systemd-mode' would ever have compiled.
+ die(--detach, --user and --group are incompatible with
--inetd and --systemd);
+
+ if (systemd_mode inetd_mode)
+ die(--inetd is incompatible with --systemd);
if (inetd_mode (listen_port || (listen_addr.nr 0)))
die(--listen= and --port= are incompatible with --inetd);
else if (listen_port == 0)
listen_port = DEFAULT_GIT_PORT;
+ if (systemd_mode) {
+ i = sd_listen_fds(0);
+ if (i = 0)
+
Re: git 2.3.4, ssh: Could not resolve hostname
Jeff King p...@peff.net writes: but this does not: $ git push ssh://does-not-exist:/repo.git ssh: Could not resolve hostname does-not-exist:: No address associated with hostname (note the doubled colon). v2.3.3 did strip off that extra colon, but I am not sure the URL above (i.e., a colon with no hostname) is actually sane. IOW, it may have happened to work in older versions, but I'm not sure we would want to promise to keep it working. Can you show us what your URL looks like, obfuscating the names but keeping the syntax the same? Also, are you using the insteadOf config syntax at all (which could easily lead to funny splicing, I imagine). Everything Jeff said ;-) Depending on the nature of '' in the original, Torsten's response may be different. '' could stand for [:::], a.host.in.domain.xz, 127.0.0.1, or all the other things and it is a bit too vague to help us tell which codepath will pick up what and possibly screw it up. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 2.3.4, ssh: Could not resolve hostname
2015-04-02 22:06 GMT+02:00 Reid Woodbury Jr. re...@rawsound.com: I'm sure I've seen it other places but I can't remember right now. What you mean is the scp-like syntax: user@host:path/relative/to/home – but if you write user@host:/path/to/something, it’s relative to /. You can also achieve paths relative to the home directory with the other syntax: ssh://user@host/~/path/relative/to/home. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gitk: Remove mc parameter from proc show_error
This partially reverts commit 8d849957d81fc0480a52570d66cc3c2a688ecb1b.
This change makes the string OK translatable and the string mc not
translatable. It will take effect the next time `make update-po` is run.
Signed-off-by: Alex Henrie alexhenri...@gmail.com
---
gitk | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitk b/gitk
index 30fcd30..7193f6f 100755
--- a/gitk
+++ b/gitk
@@ -1894,13 +1894,13 @@ proc make_transient {window origin} {
}
}
-proc show_error {w top msg {mc mc}} {
+proc show_error {w top msg} {
global NS
if {![info exists NS]} {set NS }
if {[wm state $top] eq withdrawn} { wm deiconify $top }
message $w.m -text $msg -justify center -aspect 400
pack $w.m -side top -fill x -padx 20 -pady 20
-${NS}::button $w.ok -default active -text [$mc OK] -command destroy $top
+${NS}::button $w.ok -default active -text [mc OK] -command destroy $top
pack $w.ok -side bottom -fill x
bind $top Visibility grab $top; focus $top
bind $top Key-Return destroy $top
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] gitk: Fix bad English grammar Matches none Commit Info
Signed-off-by: Alex Henrie alexhenri...@gmail.com
---
gitk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 9a2daf3..30fcd30 100755
--- a/gitk
+++ b/gitk
@@ -4066,7 +4066,7 @@ set known_view_options {
{committer t15 . --committer=* {mc Committer:}}
{loginfo t15 .. --grep=* {mc Commit Message:}}
{allmatch b.. --all-match{mc Matches all Commit Info
criteria}}
-{igrep b.. --invert-grep {mc Matches none Commit Info
criteria}}
+{igrep b.. --invert-grep {mc Matches no Commit Info criteria}}
{changes_l l+ {} {mc Changes to Files:}}
{pickaxe_s r0 . {} {mc Fixed String}}
{pickaxe_t r1 . --pickaxe-regex {mc Regular Expression}}
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-p4: fix filetype detection on files opened exclusively
Luke Diamand l...@diamand.org writes: (+Pete for interest). On 31 March 2015 at 22:54, Holloway, Blair blair_hollo...@playstation.sony.com wrote: If a Perforce server is configured to automatically set +l (exclusive lock) on add of certain file types, git p4 submit will fail during getP4OpenedType, as the regex doesn't expect the trailing '*exclusive*' from p4 opened: Thanks - that actually fixes a part of the long-standing problem of handling locked files which Pete identified about a year ago. There's a test case for handling of locked files, t9816-git-p4-locked.sh, which needs updating now as a bit more of it passes. Junio, I'll submit a followup patch to update those tests once I get back from vacation. Thanks. Lest I forget, I'd prefer this patch resent from you in a two (or more) patch series, with this one marked as 1/N with your Acked-by:, and your follow-up patches 2/N...N/N. If it is not a too much work for you, that is. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 2.3.4, ssh: Could not resolve hostname
Ah, understand. Here's my project URL for 'remote origin' with a more meaningful representation of their internal FQDN: url = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git The online is their literal internal TLD. Reid On Apr 2, 2015, at 12:24 PM, Junio C Hamano gits...@pobox.com wrote: Jeff King p...@peff.net writes: but this does not: $ git push ssh://does-not-exist:/repo.git ssh: Could not resolve hostname does-not-exist:: No address associated with hostname (note the doubled colon). v2.3.3 did strip off that extra colon, but I am not sure the URL above (i.e., a colon with no hostname) is actually sane. IOW, it may have happened to work in older versions, but I'm not sure we would want to promise to keep it working. Can you show us what your URL looks like, obfuscating the names but keeping the syntax the same? Also, are you using the insteadOf config syntax at all (which could easily lead to funny splicing, I imagine). Everything Jeff said ;-) Depending on the nature of '' in the original, Torsten's response may be different. '' could stand for [:::], a.host.in.domain.xz, 127.0.0.1, or all the other things and it is a bit too vague to help us tell which codepath will pick up what and possibly screw it up. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 2.3.4, ssh: Could not resolve hostname
Yup, removing the colon works in both 2.3.3 and 2.3.4. And I see that the manual doesn't use the colon! (eg. $ git clone ssh://user@server/project.git). The usage of the colon looks normal to my eyes because, for instance, SFTP uses it to set the path on login so this wasn't something I would have even considered. I'm sure I've seen it other places but I can't remember right now. Thanks all for your time. On Apr 2, 2015, at 12:35 PM, Jeff King p...@peff.net wrote: On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote: Ah, understand. Here's my project URL for 'remote origin' with a more meaningful representation of their internal FQDN: url = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git The online is their literal internal TLD. Thanks. The problem is the extra : after online; your URL is malformed. You can just drop that colon entirely. I do not think we need to support this syntax going forward (the colon is meaningless here, and our documentation is clear that it should go with a port number), but on the other hand, it might be nice to be more liberal, as we were in v2.3.3 and prior. I'll leave it to Torsten to see whether supporting that would hurt some of the other cases, or whether it would make the code too awkward. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] Add test for showing discarded changes with diff --cc
If a hunk has been changed in both branches and conflict resolution fully takes one of branches, discarding all changes that are in the other, then the merge is not shown in 3-way diff which git uses by default. The advice is to use flag --cc and and explicitly add the mergebase was given in $gmane/191557. It was discovered though that it does not always work. If the whole file has not changed at all compared to one of branches then no difference is shown for this file. This looks inconsistent and for particular scenario of viewing discarded changes is undesirable. Add the test which demonstrates the issue. Signed-off-by: Max Kirillov m...@max630.net --- t/t4059-diff-merge-with-base.sh | 100 1 file changed, 100 insertions(+) create mode 100755 t/t4059-diff-merge-with-base.sh diff --git a/t/t4059-diff-merge-with-base.sh b/t/t4059-diff-merge-with-base.sh new file mode 100755 index 000..e650a33 --- /dev/null +++ b/t/t4059-diff-merge-with-base.sh @@ -0,0 +1,100 @@ +#!/bin/sh + +test_description='Diff aware of merge base' + +. ./test-lib.sh + +test_expect_success setup ' + mkdir short + mkdir long + for fn in win1 win2 merge delete base only1 only2; do + test_seq 3 short/$fn + git add short/$fn + test_seq 11 long/$fn + git add long/$fn + done + git commit -m mergebase + git branch mergebase + + for fn in win1 win2 merge delete base only1; do + for dir in short long; do + sed -e s/^2/2change1/ -e s/^7/7change1/ $dir/$fn sed.new + mv sed.new $dir/$fn + git add $dir/$fn + done + done + sed -e s/^7/7change1/ long/only2 sed.new + mv sed.new long/only2 + git add long/only2 + git commit -m branch1 + git branch branch1 + + git reset --hard mergebase + for fn in win1 win2 merge delete base only2; do + for dir in short long; do + sed -e s/^2/2change2/ -e s/^11/11change2/ $dir/$fn sed.new + mv sed.new $dir/$fn + git add $dir/$fn + done + done + sed -e s/^11/11change2/ long/only1 sed.new + mv sed.new long/only1 + git add long/only1 + git commit -m branch2 + git branch branch2 + + test_must_fail git merge branch1 + git checkout mergebase -- . + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ long/base + git add long/base + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e s/^2/2change1/ long/win1 + git add long/win1 + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e s/^2/2change2/ long/win2 + git add long/win2 + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e s/^2/2merged/ long/merge + git add long/merge + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e /^2/d long/delete + git add long/delete + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e s/^2/2change1/ long/only1 + git add long/only1 + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e s/^2/2change2/ long/only2 + git add long/only2 + test_seq 3 short/base + git add short/base + test_seq 3 | sed -e s/^2/2change1/ short/win1 + git add short/win1 + test_seq 3 | sed -e s/^2/2change2/ short/win2 + git add short/win2 + test_seq 3 | sed -e s/^2/2merged/ short/merge + git add short/merge + test_seq 3 | sed -e /^2/d short/delete + git add short/delete + test_seq 3 | sed -e s/^2/2change1/ short/only1 + git add short/only1 + test_seq 3 | sed -e s/^2/2change2/ short/only2 + git add short/only2 + git commit -m merge + git branch merge +' + +test_expect_success 'diff with mergebase shows discarded change from parent 2 in merged file' ' + git diff --cc merge branch1 branch2 mergebase -- long/win1 actual + test -s actual +' + +test_expect_success 'diff with mergebase shows discarded change from parent 1 in merged file' ' + git diff --cc merge branch1 branch2 mergebase -- long/win2 actual + test -s actual +' + +test_expect_failure 'diff with mergebase shows fully discarded file from parent 2' ' + git diff --cc merge branch1 branch2 mergebase -- short/win1 actual + test -s actual +' + +test_expect_failure 'diff with mergebase shows fully discarded file from parent 1' ' + git diff --cc merge branch1 branch2 mergebase -- short/win2 actual + test -s actual +' + +test_done -- 2.3.4.2801.g3d0809b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] diff --cc: relax too strict paths picking
For diff --cc, paths fitering used to select only paths which have
changed in all parents, while diffing itself output hunks which are
changed in as few as 2 parents.
Fix intersect_paths() to add paths which have at least 2 changed
parents. In this new functionality does not require special treatment of
first pass, because path can be added from any parent, not just the
first one.
Signed-off-by: Max Kirillov m...@max630.net
---
combine-diff.c | 56 -
t/t4059-diff-merge-with-base.sh | 4 +--
2 files changed, 41 insertions(+), 19 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index a236bb5..fd752e7 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -25,6 +25,7 @@ static int compare_paths(const struct combine_diff_path *one,
static void insert_path(struct combine_diff_path **pos, const char* path, int
n, int num_parent, struct diff_filepair *queue_item)
{
int len;
+ int parent_idx;
struct combine_diff_path *p;
len = strlen(path);
@@ -41,43 +42,64 @@ static void insert_path(struct combine_diff_path **pos,
const char* path, int n,
hashcpy(p-parent[n].oid.hash, queue_item-one-sha1);
p-parent[n].mode = queue_item-one-mode;
p-parent[n].status = queue_item-status;
+ for (parent_idx = 0; parent_idx n; ++parent_idx) {
+ hashcpy(p-parent[parent_idx].oid.hash, p-oid.hash);
+ p-parent[parent_idx].mode = p-mode;
+ p-parent[parent_idx].status = ' ';
+ }
*pos = p;
}
+static int changed_parents(struct combine_diff_path *p, int n)
+{
+ int parent_idx;
+ int result = 0;
+
+ for (parent_idx = 0; parent_idx n; ++parent_idx) {
+ if (p-parent[parent_idx].status != ' ')
+ ++result;
+ }
+
+ return result;
+}
+
static struct combine_diff_path *intersect_paths(struct combine_diff_path
*curr, int n, int num_parent)
{
struct diff_queue_struct *q = diff_queued_diff;
struct combine_diff_path *p, **tail = curr;
int i, cmp;
- if (!n) {
- for (i = 0; i q-nr; i++) {
- if (diff_unmodified_pair(q-queue[i]))
- continue;
- insert_path(tail, q-queue[i]-two-path, n,
num_parent, q-queue[i]);
- tail = (*tail)-next;
- }
- return curr;
- }
-
/*
* paths in curr (linked list) and q-queue[] (array) are
* both sorted in the tree order.
*/
i = 0;
- while ((p = *tail) != NULL) {
- cmp = ((i = q-nr)
- ? -1 : compare_paths(p, q-queue[i]-two));
+ while ((p = *tail) != NULL || i q-nr) {
+ cmp = (i = q-nr) ? -1
+ : (p == NULL) ? 1
+ : compare_paths(p, q-queue[i]-two);
if (cmp 0) {
- /* p-path not in q-queue[]; drop it */
- *tail = p-next;
- free(p);
+ /* p-path not in q-queue[] */
+ if (num_parent 2 2 - changed_parents(p, n) =
num_parent - n - 1) {
+ /* still can get 2 changed parents */
+ hashcpy(p-parent[n].oid.hash, p-oid.hash);
+ p-parent[n].mode = p-mode;
+ p-parent[n].status = ' ';
+ tail = p-next;
+ } else {
+ *tail = p-next;
+ free(p);
+ }
continue;
}
if (cmp 0) {
- /* q-queue[i] not in p-path; skip it */
+ /* q-queue[i] not in p-path */
+ if (1 = num_parent - n - 1) {
+ insert_path(tail, q-queue[i]-two-path, n,
num_parent, q-queue[i]);
+ tail = (*tail)-next;
+ }
i++;
continue;
}
diff --git a/t/t4059-diff-merge-with-base.sh b/t/t4059-diff-merge-with-base.sh
index e650a33..6341f7c 100755
--- a/t/t4059-diff-merge-with-base.sh
+++ b/t/t4059-diff-merge-with-base.sh
@@ -87,12 +87,12 @@ test_expect_success 'diff with mergebase shows discarded
change from parent 1 in
test -s actual
'
-test_expect_failure 'diff with mergebase shows fully discarded file from
parent 2' '
+test_expect_success 'diff with mergebase shows fully discarded file from
parent 2' '
git diff --cc merge branch1 branch2 mergebase -- short/win1 actual
test -s actual
'
-test_expect_failure 'diff with mergebase shows fully discarded file from
parent 1' '
+test_expect_success 'diff with mergebase shows fully discarded file from
parent
[PATCH 0/4] diff --cc: relax path filtering
For diff --cc, paths fitering used to select only paths which have changed in all parents, while diffing itself output hunks which are changed in as few as 2 parents. Fix intersect_paths() to add paths which have at least 2 changed parents. Intersects with branch 'bc/object-id' which is not yet in master. This is rebased on top of it. Max Kirillov (4): Add test for showing discarded changes with diff --cc combine-diff.c: refactor: extract insert_path() diff --cc: relax too strict paths picking t4059: rewrite to be adaptive to hunk filtering combine-diff.c | 95 ++--- t/t4059-diff-merge-with-base.sh | 132 2 files changed, 193 insertions(+), 34 deletions(-) create mode 100755 t/t4059-diff-merge-with-base.sh -- 2.3.4.2801.g3d0809b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] combine-diff.c: refactor: extract insert_path()
Signed-off-by: Max Kirillov m...@max630.net
---
combine-diff.c | 43 ---
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 8eb7278..a236bb5 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -22,6 +22,28 @@ static int compare_paths(const struct combine_diff_path *one,
two-path, strlen(two-path), two-mode);
}
+static void insert_path(struct combine_diff_path **pos, const char* path, int
n, int num_parent, struct diff_filepair *queue_item)
+{
+ int len;
+ struct combine_diff_path *p;
+
+ len = strlen(path);
+ p = xmalloc(combine_diff_path_size(num_parent, len));
+ p-path = (char *) (p-parent[num_parent]);
+ memcpy(p-path, path, len);
+ p-path[len] = 0;
+ p-next = *pos;
+ memset(p-parent, 0,
+ sizeof(p-parent[0]) * num_parent);
+
+ hashcpy(p-oid.hash, queue_item-two-sha1);
+ p-mode = queue_item-two-mode;
+ hashcpy(p-parent[n].oid.hash, queue_item-one-sha1);
+ p-parent[n].mode = queue_item-one-mode;
+ p-parent[n].status = queue_item-status;
+ *pos = p;
+}
+
static struct combine_diff_path *intersect_paths(struct combine_diff_path
*curr, int n, int num_parent)
{
struct diff_queue_struct *q = diff_queued_diff;
@@ -30,27 +52,10 @@ static struct combine_diff_path *intersect_paths(struct
combine_diff_path *curr,
if (!n) {
for (i = 0; i q-nr; i++) {
- int len;
- const char *path;
if (diff_unmodified_pair(q-queue[i]))
continue;
- path = q-queue[i]-two-path;
- len = strlen(path);
- p = xmalloc(combine_diff_path_size(num_parent, len));
- p-path = (char *) (p-parent[num_parent]);
- memcpy(p-path, path, len);
- p-path[len] = 0;
- p-next = NULL;
- memset(p-parent, 0,
- sizeof(p-parent[0]) * num_parent);
-
- hashcpy(p-oid.hash, q-queue[i]-two-sha1);
- p-mode = q-queue[i]-two-mode;
- hashcpy(p-parent[n].oid.hash, q-queue[i]-one-sha1);
- p-parent[n].mode = q-queue[i]-one-mode;
- p-parent[n].status = q-queue[i]-status;
- *tail = p;
- tail = p-next;
+ insert_path(tail, q-queue[i]-two-path, n,
num_parent, q-queue[i]);
+ tail = (*tail)-next;
}
return curr;
}
--
2.3.4.2801.g3d0809b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] t4059: rewrite to be adaptive to hunk filtering
Looks like there is no exact specification what `diff -c` and
`diff --cc` should output. Considering this it is not reasonable to
hardcode any specific output in test. Rather, it should verify that file
selection behaves the same as hunk selection.
Rewrite test so that it makes sure that a short file is shown if and
only if the corresponding long file's contains the changed hunk.
Signed-off-by: Max Kirillov m...@max630.net
---
t/t4059-diff-merge-with-base.sh | 84 -
1 file changed, 58 insertions(+), 26 deletions(-)
diff --git a/t/t4059-diff-merge-with-base.sh b/t/t4059-diff-merge-with-base.sh
index 6341f7c..75a3820 100755
--- a/t/t4059-diff-merge-with-base.sh
+++ b/t/t4059-diff-merge-with-base.sh
@@ -1,13 +1,22 @@
#!/bin/sh
-test_description='Diff aware of merge base'
+test_description='combined diff filtering is not affected by preliminary path
filtering'
. ./test-lib.sh
+. $TEST_DIRECTORY/diff-lib.sh
+# history is:
+# (mergebase) -- (branch1) --\
+# | V
+# \ -- (branch2) --(merge)
+# there are files in 2 subdirectories, long and short
+# each file in long subdirecty has exactly same history as same file in
short one,
+# but it has added lines with changes in both branches which merge without
conflict
+# so the long files are always selected at path filtering
test_expect_success setup '
mkdir short
mkdir long
- for fn in win1 win2 merge delete base only1 only2; do
+ for fn in win1 win2 merge delete base only1 only2 only1discard
only2discard; do
test_seq 3 short/$fn
git add short/$fn
test_seq 11 long/$fn
@@ -23,9 +32,11 @@ test_expect_success setup '
git add $dir/$fn
done
done
- sed -e s/^7/7change1/ long/only2 sed.new
- mv sed.new long/only2
- git add long/only2
+ for fn in only2 only2discard; do
+ sed -e s/^7/7change1/ long/$fn sed.new
+ mv sed.new long/$fn
+ git add long/$fn
+ done
git commit -m branch1
git branch branch1
@@ -37,9 +48,11 @@ test_expect_success setup '
git add $dir/$fn
done
done
- sed -e s/^11/11change2/ long/only1 sed.new
- mv sed.new long/only1
- git add long/only1
+ for fn in only1 only1discard; do
+ sed -e s/^11/11change2/ long/$fn sed.new
+ mv sed.new long/$fn
+ git add long/$fn
+ done
git commit -m branch2
git branch branch2
@@ -47,6 +60,10 @@ test_expect_success setup '
git checkout mergebase -- .
test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ long/base
git add long/base
+ test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/
long/only1discard
+ git add long/only1discard
+ test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/
long/only2discard
+ git add long/only2discard
test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e
s/^2/2change1/ long/win1
git add long/win1
test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e
s/^2/2change2/ long/win2
@@ -61,6 +78,10 @@ test_expect_success setup '
git add long/only2
test_seq 3 short/base
git add short/base
+ test_seq 3 short/only1discard
+ git add short/only1discard
+ test_seq 3 short/only2discard
+ git add short/only2discard
test_seq 3 | sed -e s/^2/2change1/ short/win1
git add short/win1
test_seq 3 | sed -e s/^2/2change2/ short/win2
@@ -77,24 +98,35 @@ test_expect_success setup '
git branch merge
'
-test_expect_success 'diff with mergebase shows discarded change from parent 2
in merged file' '
- git diff --cc merge branch1 branch2 mergebase -- long/win1 actual
- test -s actual
-'
-
-test_expect_success 'diff with mergebase shows discarded change from parent 1
in merged file' '
- git diff --cc merge branch1 branch2 mergebase -- long/win2 actual
- test -s actual
-'
+# the difference in short file must be returned if and only if it is shown in
long file
+for fn in win1 win2 merge delete base only1 only2 only1discard only2discard; do
+ if git diff --cc merge branch1 branch2 mergebase -- long/$fn | grep -q
'^[ +-]\{3\}2\(change[12]|merge\)\?$'
+ then
+ test_expect_success diff --cc contains short/$fn '
+ git diff --cc merge branch1 branch2 mergebase --
short/'$fn' actual
+ test -s actual
+ '
+ else
+ test_expect_success diff --cc does not contain short/$fn '
+ git diff --cc merge branch1 branch2 mergebase --
short/'$fn' actual
+ ! test -s actual
+ '
+ fi
+done
-test_expect_success 'diff with mergebase shows
Re: [BUG] 'git merge --quiet' is not always quiet
On Thu, Apr 02, 2015 at 02:42:30PM +0200, Carl Mäsak wrote: In the following session, a 'git merge' command shows some output even with the '--quiet' flag supplied. ~/tmp $ git init example Initialized empty Git repository in /tmp/example/.git/ ~/tmp $ cd example/ ~/tmp/example $ git commit --allow-empty -m'initial commit' [master (root-commit) a7329b5] initial commit ~/tmp/example $ git checkout -b b1 Switched to a new branch 'b1' ~/tmp/example $ git commit --allow-empty -m'commit on branch' [b1 d15e5ac] commit on branch ~/tmp/example $ git checkout master Switched to branch 'master' ~/tmp/example $ git merge --quiet --no-ff --no-edit b1 Already up-to-date! ~/tmp/example $ My expectation is that '--quiet' would suppress all output, even this one. It looks like we end up calling into merge-recursive here, but the --quiet flag is not passed down. This patch seems to fix it for me. -- 8 -- Subject: merge: pass verbosity flag down to merge-recursive This makes git merge --quiet really quiet when we call into merge-recursive. Note that we can't just pass our flag down as-is; the two parts of the code use different scales. We center at 0 as normal for git-merge (with --quiet giving a negative value), but merge-recursive uses 2 as its center. This patch passes a negative value to merge-recursive rather than 1, though, as otherwise the user would have to use -qqq to squelch all messages (but the downside is that the user cannot distinguish between levels 0-2 if without resorting to the GIT_MERGE_VERBOSITY variable). We may want to review and renormalize the message severities in merge-recursive, but that does not have to happen now. This is at least in improvement in the sense that we are respecting --quiet at all. Signed-off-by: Jeff King p...@peff.net --- builtin/merge.c | 4 1 file changed, 4 insertions(+) diff --git a/builtin/merge.c b/builtin/merge.c index 3b0f8f9..068a83b 100644 --- a/builtin/merge.c +++ b/builtin/merge.c @@ -684,6 +684,10 @@ static int try_merge_strategy(const char *strategy, struct commit_list *common, o.subtree_shift = ; o.renormalize = option_renormalize; + if (verbosity 0) + o.verbosity = verbosity; + else if (verbosity 0) + o.verbosity += verbosity; o.show_rename_progress = show_progress == -1 ? isatty(2) : show_progress; -- 2.4.0.rc0.363.gf9f328b -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Dr Harry Thomas
Dr Harry Thomas Brondesbury, North West Londyn Anglia Drogi Przyjacielu. Jestem dr Harry Thomas z Brondesbury, North West London, tutaj w Anglii. Pracuję dla UBS Investment Bank Londyn. Piszę wam o propozycji biznesowych, które będą z ogromną korzyścią dla nas obu. W moim departamencie, jako członek Komitetu Wykonawczego UBS Investment Bank i również Officer Chief Risk tutaj (Greater London Regional Office). Odkryłem opuszczonej sumę 15 milionów Great British funtach (piętnaście milionów Great British Pounds Sterling) na koncie należącym do jednego z naszych zagranicznych klientów zmarłego, miliarder Business Man (Late Pan Mojżesz Saba Masri) z Meksyku, który był ofiarą katastrofy lotniczej, w wyniku jego śmierci i członków jego rodziny. Saba był 51-letni. Również w katastrofie lotniczej był z żoną i synem Abrahama (Saba) i jego córka-in-law. Wybór kontaktowania się budzi z charakter geograficzny, gdzie mieszkasz, w szczególności ze względu na wrażliwość transakcji i poufność w niniejszym wynalazku. Teraz nasz bank został czeka na którykolwiek z krewnymi, aby przyjść się do roszczenia, ale nikt tego nie zrobił. Ja osobiście przegrali sprawę w odnalezieniu krewnych do 10 miesięcy teraz, szukam Twojej zgody, aby zaprezentować Państwu jak najbliższych krewnych / Will Beneficjenta do zmarłego tak, że wpływy z tego konta wyceniono na 15 milionów funtów funtów może być wypłacona do Ciebie , To będzie wypłacane lub udostępniane w tych procentów, 60% do 40% mnie i dla Ciebie. Mam zabezpieczone wszystkie niezbędne dokumenty prawne, które mogą być wykorzystane do wykonania kopii zapasowej tego twierdzenia jest uczynienie. Wszystko, co musisz zrobić, to wypełnić swoje nazwiska do dokumentów i zalegalizować go w sądzie, aby udowodnić Ci za prawowitego beneficjenta. All I wymagają teraz jest uczciwy współpracy, poufności i zaufania w celu umożliwienia nam patrz poprzez tę transakcję. Gwarantuję, że będzie to wykonane zgodnie z prawem rozwiązanie, które będzie chronić komputer z wszelkich przypadków naruszenia prawa. Proszę dostarczyć mi następujące: jak mamy 7 dni, aby go uruchomić poprzez. To jest bardzo pilne PLEASE. 1. Imię i nazwisko: 2. Twój numer telefonu komórkowego: 3. Twój Adres kontaktowy: 4. Twój Wiek: 5. Płeć: Po przejściu przez metodyczne wyszukiwania, postanowiłem skontaktować się z Tobą nadzieję, że znajdziesz to propozycja interesująca. Na potwierdzenie tej wiadomości i wskazując zainteresowanie dostarczą Państwu więcej informacji. Starania, aby dać mi znać swojej decyzji zamiast trzymać mnie czeka. Pozdrawiam, Dr Harry Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] Git v2.4.0-rc1
A release candidate Git v2.4.0-rc1 is now available for testing at the usual places. The changes since the early preview 2.4.0-rc0 is minimum. Please give it a good testing. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.4.0-rc1' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = https://code.google.com/p/git-core/ url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git Git 2.4 Release Notes (draft) = Backward compatibility warning(s) - This release has a few changes in the user-visible output from Porcelain commands. These are not meant to be parsed by scripts, but the users still may want to be aware of the changes: * Output from git log --decorate (and %d format specifier used in the userformat --format=string parameter git log family of command takes) used to list HEAD just like other tips of branch names, separated with a comma in between. E.g. $ git log --decorate -1 master commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD, master) ... This release updates the output slightly when HEAD refers to the tip of a branch whose name is also shown in the output. The above is shown as: $ git log --decorate -1 master commit bdb0f6788fa5e3cacc4315e9ff318a27b2676ff4 (HEAD - master) ... * The phrasing git branch uses to describe a detached HEAD has been updated to match that of git status: - When the HEAD is at the same commit as it was originally detached, they now both show detached at commit object name. - When the HEAD has moved since it was originally detached, they now both show detached from commit object name. Earlier git branch always used from Updates since v2.3 -- Ports * Our default I/O size (8 MiB) for large files was too large for some platforms with smaller SSIZE_MAX, leading to read(2)/write(2) failures. * We did not check the curl library version before using CURLOPT_PROXYAUTH feature that may not exist. * We now detect number of CPUs on older BSD-derived systems. * Portability fixes and workarounds for shell scripts have been added to help BSD-derived systems. UI, Workflows Features * The command usage info strings given by git cmd -h and in documentation have been tweaked for consistency. * The sync subcommand of git p4 now allows users to exclude subdirectories like its clone subcommand does. * git log --invert-grep --grep=WIP will show only commits that do not have the string WIP in their messages. * git push has been taught a --atomic option that makes push to update more than one ref an all-or-none affair. * Extending the push to deploy added in 2.3, the behaviour of git push when updating the branch that is checked out can now be tweaked by push-to-checkout hook. * Using environment variable LANGUAGE and friends on the client side, HTTP-based transports now send Accept-Language when making requests. * git send-email used to accept a mistaken y (or yes) as an answer to What encoding do you want to use [UTF-8]? without questioning. Now it asks for confirmation when the answer looks too short to be a valid encoding name. * When git apply --whitespace=fix fixed whitespace errors in the common context lines, the command reports that it did so. * git status now allows the -v to be given twice to show the differences that are left in the working tree not to be committed. * git cherry-pick used to clean-up the log message even when it is merely replaying an existing commit. It now replays the message verbatim unless you are editing the message of resulting commits. * git archive can now be told to set the 'text' attribute in the resulting zip archive. * Output from git log --decorate mentions HEAD when it points at a tip of an branch differently from a detached HEAD. This is a potentially backward-incompatible change. * git branch on a detached HEAD always said (detached from xyz), even when git status would report detached at xyz. The HEAD is actually at xyz and haven't been moved since it was detached in such a case, but the user cannot read what the current value of HEAD is when detached from is used. * git -C '' subcmd refused to work in the current directory, unlike cd '' which silently behaves as a no-op. (merge 6a536e2 kn/git-cd-to-empty later to maint). * The versionsort.prerelease configuration variable can be used to specify that v1.0-pre1 comes before v1.0. * A new push.followTags configuration turns the
Re: [PATCH] protocol upload-pack-v2
The current protocol has the following problems that limit us: - It is not easy to make it resumable, because we recompute every time. This is especially problematic for the initial fetch aka clone as we will be talking about a large transfer. Redirection to a bundle hosted on CDN might be something we could do transparently. - The protocol extension has a fairly low length limit. - Because the protocol exchange starts by the server side advertising all its refs, even when the fetcher is interested in a single ref, the initial overhead is nontrivial, especially when you are doing a small incremental update. The worst case is an auto-builder that polls every five minutes, even when there is no new commits to be fetched. A lot of focus about the problems with ref advertisement is about the obvious problem mentioned above (a bad problem indeed). I would like to add that there is another related problem that all potential solutions to the above problem do not neccessarily improve. When polling regularly there is also no current efficient way to check on the current state of all refs. It would be nice to also be able to get an incremental update on large refs spaces. Thanks, -Martin -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-p4: fix filetype detection on files opened exclusively
(+Pete for interest). On 31 March 2015 at 22:54, Holloway, Blair blair_hollo...@playstation.sony.com wrote: If a Perforce server is configured to automatically set +l (exclusive lock) on add of certain file types, git p4 submit will fail during getP4OpenedType, as the regex doesn't expect the trailing '*exclusive*' from p4 opened: Thanks - that actually fixes a part of the long-standing problem of handling locked files which Pete identified about a year ago. There's a test case for handling of locked files, t9816-git-p4-locked.sh, which needs updating now as a bit more of it passes. Junio, I'll submit a followup patch to update those tests once I get back from vacation. (Fixing t9816 is very slightly non-trivial because test #4 is subtly broken and so incorrectly passes). Ack, Luke -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] standardize usage strings that were missed the first time
This is a follow-up to commit 9c9b4f2f8b7f27f3984e80d053106d5d41cbb03b.
Signed-off-by: Alex Henrie alexhenri...@gmail.com
---
builtin/blame.c | 2 +-
builtin/log.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 06484c2..0b2f4ed 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -27,7 +27,7 @@
#include line-range.h
#include line-log.h
-static char blame_usage[] = N_(git blame [options] [rev-opts] [rev]
[--] file);
+static char blame_usage[] = N_(git blame [options] [rev-opts] [rev]
[--] file);
static const char *blame_opt_usage[] = {
blame_usage,
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..4c4e6be 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -38,7 +38,7 @@ static const char *fmt_patch_subject_prefix = PATCH;
static const char *fmt_pretty;
static const char * const builtin_log_usage[] = {
- N_(git log [options] [revision range] [[--] path...]),
+ N_(git log [options] [revision-range] [[--] path...]),
N_(git show [options] object...),
NULL
};
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] branch: fix funny-sounding error message
Signed-off-by: Alex Henrie alexhenri...@gmail.com
---
builtin/branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 1d15037..c0b4bae 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -972,7 +972,7 @@ int cmd_branch(int argc, const char **argv, const char
*prefix)
if (!branch) {
if (!argc || !strcmp(argv[0], HEAD))
- die(_(could not set upstream of HEAD to %s
when
+ die(_(could not set upstream of HEAD to %s
because
it does not point to any branch.),
new_upstream);
die(_(no such branch '%s'), argv[0]);
--
2.3.5
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] standardize usage strings that were missed the first time
Alex Henrie alexhenri...@gmail.com writes:
This is a follow-up to commit 9c9b4f2f8b7f27f3984e80d053106d5d41cbb03b.
Signed-off-by: Alex Henrie alexhenri...@gmail.com
---
Thanks, but please no more _(string) changes for the rest of the
cycle, as that would impact i18n folks who will be starting from
tagged -rc releases.
Please hold them off, and resend them after 2.4.0 final.
Thanks.
builtin/blame.c | 2 +-
builtin/log.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 06484c2..0b2f4ed 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -27,7 +27,7 @@
#include line-range.h
#include line-log.h
-static char blame_usage[] = N_(git blame [options] [rev-opts] [rev]
[--] file);
+static char blame_usage[] = N_(git blame [options] [rev-opts] [rev]
[--] file);
static const char *blame_opt_usage[] = {
blame_usage,
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..4c4e6be 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -38,7 +38,7 @@ static const char *fmt_patch_subject_prefix = PATCH;
static const char *fmt_pretty;
static const char * const builtin_log_usage[] = {
- N_(git log [options] [revision range] [[--] path...]),
+ N_(git log [options] [revision-range] [[--] path...]),
N_(git show [options] object...),
NULL
};
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 2.3.4, ssh: Could not resolve hostname
On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote: Ah, understand. Here's my project URL for 'remote origin' with a more meaningful representation of their internal FQDN: url = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git The online is their literal internal TLD. Thanks. The problem is the extra : after online; your URL is malformed. You can just drop that colon entirely. I do not think we need to support this syntax going forward (the colon is meaningless here, and our documentation is clear that it should go with a port number), but on the other hand, it might be nice to be more liberal, as we were in v2.3.3 and prior. I'll leave it to Torsten to see whether supporting that would hurt some of the other cases, or whether it would make the code too awkward. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
gitk won't show notes?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I can't seem to get gitk to show notes, even when I give it --notes. Does it just not handle notes? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJVHZm5AAoJENRVrw2cjl5RT0wIAJVfE2cDQODUCoOsIwhVDiMf CNeTKy1VxCgwVy8KDoYxY2hBlDIRELkcVIkN5ueNVu57LZ+1z/iBUhgr3mmzH9br z2viRjkKRlNSqP/b+HwK0+GxBIbN/FpIEyKTPe558SMcUjCkeINfxfcgYYbmY4Rv aY60j4LMQCEgltkmyDJ/kRX1I7Pr4YCfwNfoIQj3LxvCY5WL7VGn7QmM56Qh9m8P DVvTdMHBnhLOTCSa79/uAAZKJxVNE7z8YnHw1aimNXs/uwm7DYl4coxXVGDxyUfm DnEDcqtLfFst58UtLDRn7f3YawT7heeeXJ7tKUAizX3YQuTTRp9WrN12yE7Crxo= =Z23X -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] Add test for showing discarded changes with diff --cc
Max Kirillov m...@max630.net writes: If a hunk has been changed in both branches and conflict resolution fully takes one of branches, discarding all changes that are in the other, then the merge is not shown in 3-way diff which git uses by default. The advice is to use flag --cc and and explicitly add the mergebase was given in $gmane/191557. It was discovered though that it does not always work. If the whole file has not changed at all compared to one of branches then no difference is shown for this file. This looks inconsistent and for particular scenario of viewing discarded changes is undesirable. Add the test which demonstrates the issue. Signed-off-by: Max Kirillov m...@max630.net Thanks. I will not have time to review this properly at the moment while preparing 2.4-rc1, and I do not want to spend time figuring out if the parent culling you are chaning was done deliberately (in which case this patch may be breaking things) or not. So I'll give a preliminary nitpicks first ;-) Subject: Re: [PATCH 1/4] Add test for showing discarded changes with diff --cc Subject: t4059: test 'diff --cc' with a change from only few parents or something? area: what you did without capitalization of the beginning of what you did and the full-stop at the end. --- t/t4059-diff-merge-with-base.sh | 100 1 file changed, 100 insertions(+) create mode 100755 t/t4059-diff-merge-with-base.sh diff --git a/t/t4059-diff-merge-with-base.sh b/t/t4059-diff-merge-with-base.sh new file mode 100755 index 000..e650a33 --- /dev/null +++ b/t/t4059-diff-merge-with-base.sh @@ -0,0 +1,100 @@ +#!/bin/sh + +test_description='Diff aware of merge base' + +. ./test-lib.sh + +test_expect_success setup ' + mkdir short + mkdir long + for fn in win1 win2 merge delete base only1 only2; do + test_seq 3 short/$fn + git add short/$fn + test_seq 11 long/$fn + git add long/$fn + done Two nits: - Style: have do on its own line. A good rule of thumb is that you shouldn't have to type ';' when you are writing a shell script, unless you are terminating a case arm with ';;'. for fn in ... do ... done - Correctness: aside from missing after test_seq 3, if the last step git add long/$fn failed in an earlier iteration, you would not notice any breakage. Either ( for fn in ... do ... ... ... || exit $? done ) or for fn in ... do ... ... ... || return $? done The latter is only valid in our test scripts, where the test framework gives you an artificial caller of the subroutine you are writing as the test body. + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ long/base + git add long/base + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e s/^2/2change1/ long/win1 + git add long/win1 + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e s/^2/2change2/ long/win2 + git add long/win2 + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e s/^2/2merged/ long/merge + git add long/merge + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e /^2/d long/delete + git add long/delete + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e s/^2/2change1/ long/only1 + git add long/only1 + test_seq 11 | sed -e s/^7/7change1/ -e s/^11/11change2/ -e s/^2/2change2/ long/only2 + git add long/only2 Patch is line-wrapped around here? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] diff --cc: relax path filtering
On Thu, Apr 02, 2015 at 11:34:09PM +0300, Max Kirillov wrote: For diff --cc, paths fitering used to select only paths which have changed in all parents, while diffing itself output hunks which are changed in as few as 2 parents. I'm confused about used to here. Is this a regression due to the combine-diff rewriting that happened in 2.0, or do you just mean before this patch series, we used to do this other thing. Fix intersect_paths() to add paths which have at least 2 changed parents. I'd worry a little that this is increasing the cost to do log --cc, as it means we will have to open and look at extra files, and we may find in many cases that there aren't any interesting hunks. Which would imply we might want to put it behind a flag, rather than as the default (--cc-me-harder). But if I'm understanding the issue correctly, this should only matter for octopus merges. That is, the old rule for looking at a path was is there at least one parent whose content we took verbatim, but the new one is are there are at least 2 parents whose content we did not take verbatim. With only two parents, those would be the same thing, I think. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] diff --cc: relax too strict paths picking
Max Kirillov m...@max630.net writes:
Again, just surface nitpicks.
[side: Kirill Smelkov k...@mns.spb.ru removed from CC, as the
ddress just bounced for me]
+static int changed_parents(struct combine_diff_path *p, int n)
+{
+ int parent_idx;
+ int result = 0;
+
+ for (parent_idx = 0; parent_idx n; ++parent_idx) {
+ if (p-parent[parent_idx].status != ' ')
+ ++result;
We write C (not C++) and favor post_increment++ over ++pre_increment
when there is no valid reason to do otherwise (e.g. the result of
increment getting used in a larger expression).
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Apr 2015, #01; Thu, 2)
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
The first release candidate 2.4-rc1 has been tagged. I'll still
take small and trivial fixes and documentation updates but let's
really shift our focus to find and fix (or revert) regressions
that may have happened during this cycle.
You can find the changes described here in the integration branches
of the repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--
[New Topics]
* va/fix-git-p4-tests (2015-03-28) 2 commits
- git-p4: fix copy detection test
- t9814: fix broken shell syntax in git-p4 rename test
Test fixes for git-p4
Will merge to 'next'.
* va/p4-client-path (2015-03-28) 2 commits
- git-p4: improve client path detection when branches are used
- t9801: check git-p4's branch detection and client view together
Attempt to better handle branches in perforce by git p4
Reviews by git-p4 experts are very much appreciated.
* iu/fix-parse-options-h-comment (2015-03-29) 1 commit
(merged to 'next' on 2015-04-02 at 7fd3cef)
+ parse-options.h: OPTION_{BIT,SET_INT} do not store pointer to defval
Will merge to 'master'.
* jk/at-push-sha1 (2015-03-31) 6 commits
- sha1_name: implement @{push} shorthand
- sha1_name: refactor upstream_mark
- remote.c: provide per-branch pushremote name
- remote.c: hoist branch.*.remote lookup out of remote_get_1
- remote.c: drop remote pointer from struct branch
- remote.c: drop default_remote_name variable
* jk/cherry-pick-docfix (2015-03-30) 1 commit
(merged to 'next' on 2015-04-02 at 40da1d7)
+ cherry-pick: fix docs describing handling of empty commits
Will merge to 'master'.
* jk/sha1-file-reduce-useless-warnings (2015-03-30) 1 commit
- sha1_file: squelch packfile cannot be accessed warnings
* jz/gitweb-conf-doc-fix (2015-03-31) 1 commit
(merged to 'next' on 2015-04-02 at 237d1bc)
+ gitweb.conf.txt: say build-time, not built-time
Will merge to 'master'.
* mh/show-branch-topic (2015-03-31) 1 commit
- show-branch: show all local heads when only giving one rev along --topics
git show-branch --topics HEAD (with no other arguments) did not
do anything interesting. Instead, contrast the given revision
against all the local branches by default.
Will merge to 'next'.
* pt/enter-repo-comment-fix (2015-03-31) 1 commit
(merged to 'next' on 2015-04-02 at 276ad7e)
+ enter_repo(): fix docs to match code
Will merge to 'master'.
* sb/line-log-plug-pairdiff-leak (2015-03-30) 1 commit
- line-log.c: fix a memleak
Will merge to 'next'.
* sb/plug-wt-shortstatus-tracking-leak (2015-03-30) 1 commit
- wt-status.c: fix a memleak
Will merge to 'next'.
* jc/push-cert (2015-04-02) 1 commit
- push --signed: tighten what the receiving end can ask to sign
The git push --signed protocol extension did not limit what the
nonce that is a server-chosen string can contain or how long it
can be, which was unnecessarily lax. Limit both the length and the
alphabet to a reasonably small space that can still have enough
entropy.
Will merge to 'next'.
* jc/update-instead-into-void (2015-04-01) 1 commit
- push-to-deploy: allow pushing into an unborn branch and updating it
A push into an unborn branch, with receive.denyCurrentBranch set
to updateInstead, did not check out the working tree as expected.
Will merge to 'next'.
* jk/init-core-worktree-at-root (2015-04-02) 1 commit
- init: don't set core.worktree when initializing /.git
We avoid setting core.worktree when the repository location is the
.git directory directly at the top level of the working tree, but
the code misdetected the case in which the working tree is at the
root level of the filesystem (which arguably is a silly thing to
do, but still valid).
Will merge to 'next'.
* jk/pack-corruption-post-mortem (2015-04-01) 1 commit
- howto: document more tools for recovery corruption
Documentation update.
Will merge to 'next'.
* jn/doc-fast-import-no-16-octopus-limit (2015-03-31) 1 commit
- fast-import doc: remove suggested 16-parent limit
Documentation update.
Will merge to 'next'.
* sb/plug-streaming-leak (2015-03-31) 1 commit
- streaming.c: fix a memleak
Will merge to 'next'.
* ts/checkout-advice-plural (2015-04-01) 1 commit
- checkout: call a single commit “it” instead of “th
Will merge to 'next'.
--
[Graduated to master]
* ph/push-doc-cas (2015-03-26) 1 commit
(merged to 'next' on 2015-03-27 at 0737697)
+ git-push.txt: clean up force-with-lease wording
Documentation update.
* sb/leaks (2015-03-24) 10 commits
(merged to 'next' on 2015-03-24 at bdbc0c7)
+ http: release the memory of a http pack request as well
(merged to 'next' on 2015-03-23 at 5397daf)
+ read-cache: fix memleak
+ add_to_index(): free unused cache-entry
+ commit.c: fix
[PATCH] push --signed: tighten what the receiving end can ask to sign
Instead of blindly trusting the receiving side to give us a sensible
nonce to sign, limit the length (max 256 bytes) and the alphabet
(alnum and a few selected punctuations, enough to encode in base64)
that can be used in nonce.
Noticed-by: Jann Horn j...@thejh.net
Signed-off-by: Junio C Hamano gits...@pobox.com
---
send-pack.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/send-pack.c b/send-pack.c
index 7ad1a59..2249808 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -279,6 +279,28 @@ free_return:
return update_seen;
}
+#define NONCE_LEN_LIMIT 256
+
+static void reject_invalid_nonce(const char *nonce, int len)
+{
+ int i = 0;
+
+ if (NONCE_LEN_LIMIT = len)
+ die(the receiving end asked to sign an invalid nonce %.*s,
+ len, nonce);
+
+ for (i = 0; i len; i++) {
+ int ch = nonce[i] 0xFF;
+ if (isalnum(ch) ||
+ ch == '-' || ch == '.' ||
+ ch == '/' || ch == '+' ||
+ ch == '=' || ch == '_')
+ continue;
+ die(the receiving end asked to sign an invalid nonce %.*s,
+ len, nonce);
+ }
+}
+
int send_pack(struct send_pack_args *args,
int fd[], struct child_process *conn,
struct ref *remote_refs,
@@ -321,6 +343,7 @@ int send_pack(struct send_pack_args *args,
push_cert_nonce = server_feature_value(push-cert, len);
if (!push_cert_nonce)
die(_(the receiving end does not support --signed
push));
+ reject_invalid_nonce(push_cert_nonce, len);
push_cert_nonce = xmemdupz(push_cert_nonce, len);
}
--
2.4.0-rc1-147-g8712228
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] push --signed: tighten what the receiving end can ask to sign
On Thu, Apr 02, 2015 at 03:09:15PM -0700, Junio C Hamano wrote: + if (isalnum(ch) || + ch == '-' || ch == '.' || + ch == '/' || ch == '+' || + ch == '=' || ch == '_') + continue; I think this looks good. Earlier I suggested reducing the set of allowable punctuation characters, but if we want to allow base64, that's +/= right there. We use - ourselves, leaving only . and _ as possible extras. But both of those are as useful as - for separators, and are fairly innocuous, so I don't mind leaving them. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] protocol upload-pack-v2
Martin Fick mf...@codeaurora.org writes: The current protocol has the following problems that limit us: - It is not easy to make it resumable, because we recompute every time. This is especially problematic for the initial fetch aka clone as we will be talking about a large transfer. Redirection to a bundle hosted on CDN might be something we could do transparently. - The protocol extension has a fairly low length limit. - Because the protocol exchange starts by the server side advertising all its refs, even when the fetcher is interested in a single ref, the initial overhead is nontrivial, especially when you are doing a small incremental update. The worst case is an auto-builder that polls every five minutes, even when there is no new commits to be fetched. A lot of focus about the problems with ref advertisement is about the obvious problem mentioned above (a bad problem indeed). I would like to add that there is another related problem that all potential solutions to the above problem do not neccessarily improve. When polling regularly there is also no current efficient way to check on the current state of all refs. It would be nice to also be able to get an incremental update on large refs spaces. Yes, incremental ref update is an important problem to solve. I think one potential solution was indeed mentioned to improve that exact issue, e.g. footnote #3 in $gmane/264000. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] protocol upload-pack-v2
On Thu, Apr 2, 2015 at 3:18 PM, Martin Fick mf...@codeaurora.org wrote: The current protocol has the following problems that limit us: - It is not easy to make it resumable, because we recompute every time. This is especially problematic for the initial fetch aka clone as we will be talking about a large transfer. Redirection to a bundle hosted on CDN might be something we could do transparently. - The protocol extension has a fairly low length limit. - Because the protocol exchange starts by the server side advertising all its refs, even when the fetcher is interested in a single ref, the initial overhead is nontrivial, especially when you are doing a small incremental update. The worst case is an auto-builder that polls every five minutes, even when there is no new commits to be fetched. A lot of focus about the problems with ref advertisement is about the obvious problem mentioned above (a bad problem indeed). I would like to add that there is another related problem that all potential solutions to the above problem do not neccessarily improve. When polling regularly there is also no current efficient way to check on the current state of all refs. It would be nice to also be able to get an incremental update on large refs spaces. I think once the new protocol is in place, the server could advertise the capability to send a differential of refs. To make sure that works the capability phase should be strictly separated from the rest, so you can think of any new fancy scheme to transmit refs or objects, and once both client and server agree on that fancy scheme both know when to expect the new changed protocol. So from a high level perspective it should look like: Phase 1) negotiation of capabilities Phase 2) ref advertisement (i.e. changes in the DAG end points) Phase 3) transmitting the missing blobs. The crucial point now is to make sure Phase 1) is not growing to large in transmission size / required compute power (/ complexity). And as everybody out there wants to invent new schemes how to do 2) and 3) efficient, I wonder if we need to do Phase 1) as a differential as well, so I'd presume the optimum could look like Client: Last time we talked the capabilities you advertised hashed to $SHA Server: That's right, but additionally I have push_cert_nonce=$value In the non-optimal case: Client: Last time we talked the capabilities you advertised hashed to $SHA Server: I don't know that value, here comes the list of all capabilities I can do: ... ... I like that approach as it would really break down to transmitting the minimal amount of information most of the time. The downside is to know which capabilities are cache-able and then hash-able, such that the remote side only needs to maintain only a very small set of advertised capability lists and their hash. For example the nonce for signed pushes will hopefully never be the same, so it makes no sense to have them inside the capabilities cache. Having such a capabilities cache would give us a long time until the phase to negotiate the capabilities will grow too large again (most of the capabilities I'd assume are rather static per server) And the way I understand the current situation, it's all about talking this early negotiation phase, which then allows us to model the refs advertisement and the blob transmission later on as a response to upcoming problems in the future. Thanks, -Martin -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] checkout: Say “it” instead of “them” for one commit
Junio – I see you changed my commit message a bit, but some mistakes seem to have slipped in: checkout: call a single commit “it” instead of “th “them” was cut off, including the trailing quotation mark. […] them ...” even for only one commit. Two quotation marks? I always use the “right” quotation marks instead of or ' and “…” instead of “...”, should I have used the latter ones? Thanks, Thomas -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 2.3.4, ssh: Could not resolve hostname
On Fri, Apr 03, 2015 at 02:02:15AM +0200, Torsten Bögershausen wrote: But not this one: ./git fetch-pack --diag-url ssh://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git Diag: url=ssh://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git Diag: protocol=ssh Diag: userandhost=git.kernel.org: Diag: port=NONE Spontaneously I would say that a trailing ':' at the end of a hostname in the ssh:// scheme can be safely ignored, what do you think ? I think instead of ignoring it we can just produce an error. The user might have meant to specify a port, but forgotten. I've done similar things before. I generally prefer being a bit stricter and giving helpful error messages rather than trying to intuit what the user meant. The user is always going to come up with a new way to break the code. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Re: [PATCH] diff-highlight: Fix broken multibyte string
On Thu, Apr 02, 2015 at 05:49:24PM -0700, Kyle J. McKay wrote: Subject: [PATCH v2] diff-highlight: do not split multibyte characters When the input is UTF-8 and Perl is operating on bytes instead of characters, a diff that changes one multibyte character to another that shares an initial byte sequence will result in a broken diff display as the common byte sequence prefix will be separated from the rest of the bytes in the multibyte character. Thanks, I had a feeling we should be able to do something with perl's builtin utf8 support. This doesn't help people with other encodings, but I'm not sure the original was all that helpful either (in that we don't actually _know_ the file encodings in the first place). I briefly confirmed that this seems to do the right thing on po/bg.po, which has a couple of sheared characters when viewed with the existing code. I timed this one versus the existing diff-highlight. It's about 7% slower. That's not great, but is acceptable to me. The String::Multibyte version was a lot faster, which was nice (but I'm still unclear on _why_). Fix this by putting Perl into character mode when splitting the line and then back into byte mode after the split is finished. I also wondered if we could simply put stdin into utf8 mode. But it looks like it will barf whenever it gets invalid utf8. Checking for valid utf8 and only doing the multi-byte split in that case (as you do here) is a lot more robust. While the utf8::xxx functions are built-in and do not require any 'use' statement, the utf8::is_utf8 function did not appear until Perl 5.8.1, but is identical to the Encode::is_utf8 function which is available in 5.8 so we use that instead of utf8::is_utf8. Makes sense. I'm happy enough listing perl 5.8 as a dependency. EungJun, does this version meet your needs? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff-highlight: Fix broken multibyte string
On Apr 2, 2015, at 18:24, Jeff King wrote: On Thu, Apr 02, 2015 at 05:49:24PM -0700, Kyle J. McKay wrote: Subject: [PATCH v2] diff-highlight: do not split multibyte characters When the input is UTF-8 and Perl is operating on bytes instead of characters, a diff that changes one multibyte character to another that shares an initial byte sequence will result in a broken diff display as the common byte sequence prefix will be separated from the rest of the bytes in the multibyte character. Thanks, I had a feeling we should be able to do something with perl's builtin utf8 support. This doesn't help people with other encodings, It should work as well as the original did for any 1-byte encoding. That is, if it's not valid UTF-8 it should pass through unchanged and any single byte encoding should just work. But, as you point out, multibyte encodings other than UTF-8 won't work, but they should behave the same as they did before. but I'm not sure the original was all that helpful either (in that we don't actually _know_ the file encodings in the first place). I think it should work fine on any single byte encoding (i.e. ISO-8859- x, WINDOWS-1252, etc.). I timed this one versus the existing diff-highlight. It's about 7% slower. I'd expect that, we're doing extra work we weren't doing before. That's not great, but is acceptable to me. The String::Multibyte version was a lot faster, which was nice (but I'm still unclear on _why_). Must be the mbcs-strsplit routine has special case code for splitting on '' to just split on character boundaries. Fix this by putting Perl into character mode when splitting the line and then back into byte mode after the split is finished. I also wondered if we could simply put stdin into utf8 mode. But it looks like it will barf whenever it gets invalid utf8. Checking for valid utf8 and only doing the multi-byte split in that case (as you do here) is a lot more robust. While the utf8::xxx functions are built-in and do not require any 'use' statement, the utf8::is_utf8 function did not appear until Perl 5.8.1, but is identical to the Encode::is_utf8 function which is available in 5.8 so we use that instead of utf8::is_utf8. Makes sense. I'm happy enough listing perl 5.8 as a dependency. Maybe that should be added. The rest of Git's perl code seems to have a 'use 5.008;' already, so I figured that was a reasonable dependency. :) -Kyle -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff-highlight: Fix broken multibyte string
On Mar 30, 2015, at 15:16, Jeff King wrote:
Yeah, I agree the current output is not ideal, and this should address
the problem. I was worried that multi-byte splitting would make things
slower, but in my tests, it actually speeds things up!
[...]
Unfortunately, String::Multibyte is not a standard module, and is not
even packed for Debian systems (I got mine from CPAN). Can we make
this
a conditional include (e.g., 'eval require String::Multibyte' in
get_mbcs, and return undef if that fails?). Then people without it can
still use the script.
[...]
Yuck. This is a lot more intimate with String::Multibyte's
implementation than I'd like to be.
So I was curious about this and played with it and was able to
reproduce the problem as described.
Here's an alternate fix that should work for everyone with Perl 5.8
or later.
-Kyle
-- 8 --
Subject: [PATCH v2] diff-highlight: do not split multibyte characters
When the input is UTF-8 and Perl is operating on bytes instead
of characters, a diff that changes one multibyte character to
another that shares an initial byte sequence will result in a
broken diff display as the common byte sequence prefix will be
separated from the rest of the bytes in the multibyte character.
For example, if a single line contains only the unicode
character U+C9C4 (encoded as UTF-8 0xEC, 0xA7, 0x84) and that
line is then changed to the unicode character U+C9C0 (encoded as
UTF-8 0xEC, 0xA7, 0x80), when operating on bytes diff-highlight
will show only the single byte change from 0x84 to 0x80 thus
creating invalid UTF-8 and a broken diff display.
Fix this by putting Perl into character mode when splitting the
line and then back into byte mode after the split is finished.
While the utf8::xxx functions are built-in and do not require
any 'use' statement, the utf8::is_utf8 function did not appear
until Perl 5.8.1, but is identical to the Encode::is_utf8
function which is available in 5.8 so we use that instead of
utf8::is_utf8.
Reported-by: Yi EungJun semtlen...@gmail.com
Signed-off-by: Kyle J. McKay mack...@gmail.com
---
contrib/diff-highlight/diff-highlight | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/contrib/diff-highlight/diff-highlight
b/contrib/diff-highlight/diff-highlight
index 08c88bbc..8e9b5ada 100755
--- a/contrib/diff-highlight/diff-highlight
+++ b/contrib/diff-highlight/diff-highlight
@@ -2,6 +2,7 @@
use warnings FATAL = 'all';
use strict;
+use Encode ();
# Highlight by reversing foreground and background. You could do
# other things like bold or underline if you prefer.
@@ -164,8 +165,10 @@ sub highlight_pair {
sub split_line {
local $_ = shift;
- return map { /$COLOR/ ? $_ : (split //) }
- split /($COLOR*)/;
+ utf8::decode($_);
+ return map { utf8::encode($_) if Encode::is_utf8($_); $_ }
+ map { /$COLOR/ ? $_ : (split //) }
+ split /($COLOR*)/;
}
sub highlight_line {
---
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: What's cooking in git.git (Apr 2015, #01; Thu, 2)
On Apr 2, 2015, at 15:09, Junio C Hamano wrote: * jc/show-branch (2014-03-24) 5 commits - show-branch: use commit slab to represent bitflags of arbitrary width - show-branch.c: remove all_mask - show-branch.c: abstract out flags operation - show-branch.c: lift all_mask/all_revs to a global static - show-branch.c: update comment style Waiting for the final step to lift the hard-limit before sending it out. May I ask, now that this topic is over 1-year old, please, what is the final step? Perhaps someone might submit a patch... ;) -Kyle -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] protocol upload-pack-v2
After looking at $gmane/264000 again, maybe the client should talk first stating all the relevant information it wants to get, though I realize this is not part of capabilities so maybe it could even before, such as: Client: All I want to do is an ls-remote, so only Phase 2, no transmission of blobs phase 3 Server: ok Client[as in the previous mail]: Last time we talked you advertised hashed to $SHA Server: that's correct! As the server knows the client doesn't want to know about Phase3, it can omit things relevant to that phase such as the signed push nonce. So from a high level perspective we'd maybe need 4 phases like Phase 0) declare the intent (fetch/push all or partial parts) Phase 1) negotiation of capabilities Phase 2) ref advertisement (i.e. changes in the DAG end points) Phase 3) transmitting the missing blobs. The problem may be that phase 0 and 1 may require mixing, as you may want to declare new things to do in 0) which you would have needed to advertise as a capability in 1). So maybe we need to swap that around: Phase 1a) negotiation of capabilities Phase 1b) negotiation of intent (fetch/push of all/few branches in full/shallow/narrow fashion) Phase 2) ref advertisement (i.e. changes in the DAG end points) Phase 3) transmitting the missing blobs. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 2.3.4, ssh: Could not resolve hostname
On 2015-04-02 21.35, Jeff King wrote: On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote: Ah, understand. Here's my project URL for 'remote origin' with a more meaningful representation of their internal FQDN: url = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git The online is their literal internal TLD. Thanks. The problem is the extra : after online; your URL is malformed. You can just drop that colon entirely. I do not think we need to support this syntax going forward (the colon is meaningless here, and our documentation is clear that it should go with a port number), but on the other hand, it might be nice to be more liberal, as we were in v2.3.3 and prior. I'll leave it to Torsten to see whether supporting that would hurt some of the other cases, or whether it would make the code too awkward. -Peff Thanks for digging. This makes my think that it is a) non-standard to have the extra colon b) The error message could be better c) We don't have a test case d) This reminds my of an improvement from Linus: 608d48b2207a61528 .. So when somebody passes me a please pull request pointing to something like the following git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git (note the extraneous colon at the end of the host name), git would happily try to connect to port 0, which would generally just cause the remote to not even answer, and the connect() will take a long time to time out. . Sorry guys for the regression, the old parser handled the extra colon as port 0, the new one looks for the / as the end of the hostname (and the beginning of the path) Either we accept the extra colon as before, or the parser puts out a better error message, (because the OS doesn't seem to do so): ./git clone git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git Cloning into 'v4l-dvb'... fatal: unable to connect to git.kernel.org:: git.kernel.org:[0: 62.157.140.133]: errno=Connection refused git.kernel.org:[1: 80.156.86.78]: errno=Connection refused (Especially the :: is a little bit funny: the first ':' is the extra one, the second one comes from the error message: unable to connect to %s:\n%s That is not really user-friendly, so I put it onto my TODO-list It seems as if it comes from the repair of another regression, which re-allows the usage of IPV6 addresses without []: ./git fetch-pack --diag-url ssh://::1/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git Diag: url=ssh://::1/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git Diag: protocol=ssh Diag: userandhost=::1 Diag: port=NONE Diag: path=/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git And this makes sense too: ./git fetch-pack --diag-url ssh://git.kernel.org:1/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git Diag: url=ssh://git.kernel.org:1/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git Diag: protocol=ssh Diag: userandhost=git.kernel.org Diag: port=1 Diag: path=/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git But not this one: ./git fetch-pack --diag-url ssh://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git Diag: url=ssh://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git Diag: protocol=ssh Diag: userandhost=git.kernel.org: Diag: port=NONE Spontaneously I would say that a trailing ':' at the end of a hostname in the ssh:// scheme can be safely ignored, what do you think ? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kickoff for Git 2.4.0 l10n round 2
Hi, Today after I merged pull request from Ralf, I found there is one new l10n update from Git 2.4.0-rc1. I also checked the 4 potential feature branches (Will merge to master) documented in whats-cooking.txt, and I guess this is the last round for 2.4.0 l10n. The new git.pot is generated in the master branch of git-l10n/git-po. l10n: git.pot: v2.4.0 round 2 (1 update) Generate po/git.pot from v2.4.0-rc1 for git v2.4.0 l10n round 2. Signed-off-by: Jiang Xin worldhello@gmail.com You can get it from the usual place: https://github.com/git-l10n/git-po/ As how to update your XX.po and help to translate Git, please see Updating a XX.po file and other sections in po/README file. -- Jiang Xin -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] diff-highlight: Fix broken multibyte string
I timed this one versus the existing diff-highlight. It's about 7%
slower. That's not great, but is acceptable to me. The String::Multibyte
version was a lot faster, which was nice (but I'm still unclear on
_why_).
I think the reason is here:
sub split_line {
local $_ = shift;
return map { /$COLOR/ ? $_ : ($mbcs ? $mbcs-strsplit('', $_) : split //) }
split /($COLOR)/;
}
I removed * from split /($COLOR*)/. Actually I don't know why *
was required but I need to remove it to make my patch works correctly.
On Fri, Apr 3, 2015 at 10:24 AM, Jeff King p...@peff.net wrote:
On Thu, Apr 02, 2015 at 05:49:24PM -0700, Kyle J. McKay wrote:
Subject: [PATCH v2] diff-highlight: do not split multibyte characters
When the input is UTF-8 and Perl is operating on bytes instead
of characters, a diff that changes one multibyte character to
another that shares an initial byte sequence will result in a
broken diff display as the common byte sequence prefix will be
separated from the rest of the bytes in the multibyte character.
Thanks, I had a feeling we should be able to do something with perl's
builtin utf8 support. This doesn't help people with other encodings,
but I'm not sure the original was all that helpful either (in that we
don't actually _know_ the file encodings in the first place).
I briefly confirmed that this seems to do the right thing on po/bg.po,
which has a couple of sheared characters when viewed with the existing
code.
I timed this one versus the existing diff-highlight. It's about 7%
slower. That's not great, but is acceptable to me. The String::Multibyte
version was a lot faster, which was nice (but I'm still unclear on
_why_).
Fix this by putting Perl into character mode when splitting the
line and then back into byte mode after the split is finished.
I also wondered if we could simply put stdin into utf8 mode. But it
looks like it will barf whenever it gets invalid utf8. Checking for
valid utf8 and only doing the multi-byte split in that case (as you do
here) is a lot more robust.
While the utf8::xxx functions are built-in and do not require
any 'use' statement, the utf8::is_utf8 function did not appear
until Perl 5.8.1, but is identical to the Encode::is_utf8
function which is available in 5.8 so we use that instead of
utf8::is_utf8.
Makes sense. I'm happy enough listing perl 5.8 as a dependency.
EungJun, does this version meet your needs?
-Peff
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/4] t1006: add tests for git cat-file --literally
Signed-off-by: Karthik Nayak karthik@gmail.com --- t/t1006-cat-file.sh | 27 +++ 1 file changed, 27 insertions(+) diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh index a72e700..3015062 100755 --- a/t/t1006-cat-file.sh +++ b/t/t1006-cat-file.sh @@ -47,6 +47,18 @@ $content test_cmp expect actual ' +test_expect_success Type of $type is correct using --literally ' + echo $type expect + git cat-file -t --literally $sha1 actual + test_cmp expect actual +' + +test_expect_success Size of $type is correct using --literally ' + echo $size expect + git cat-file -s --literally $sha1 actual + test_cmp expect actual +' + test -z $content || test_expect_success Content of $type is correct ' maybe_remove_timestamp $content $no_ts expect @@ -296,4 +308,19 @@ test_expect_success '%(deltabase) reports packed delta bases' ' } ' +bogus_type=bogus +bogus_sha1=$(git hash-object -t $bogus_type --literally -w --stdin /dev/null) + +test_expect_success Type of broken object is correct ' + echo $bogus_type expect + git cat-file -t --literally $bogus_sha1 actual + test_cmp expect actual +' + +test_expect_success Size of broken object is correct ' + echo 0 expect + git cat-file -s --literally $bogus_sha1 actual + test_cmp expect actual +' + test_done -- 2.3.1.172.g04a1281 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] protocol upload-pack-v2
On Wed, Apr 1, 2015 at 2:58 AM, Junio C Hamano gits...@pobox.com wrote: This is a follow-up on $gmane/264553, which is a continuation of $gmane/264000, but instead of giving two required readings to readers, I'll start with reproduction of the two, and add a few more things the current protocol lacks that I would want to see in the updated protocol. I think the important thing to get v2 started is making sure we do not need v3 to get rid of any of these limitations. In other words v2 should be extensible enough to implement them later. I'm looking from this perspective. The current protocol has the following problems that limit us: - It is not easy to make it resumable, because we recompute every time. This is especially problematic for the initial fetch aka clone as we will be talking about a large transfer. Redirection to a bundle hosted on CDN might be something we could do transparently. Sending multiple packs or some redirection instructions could be done even with v1. The only recompute part that is unavoidable in v1 is ref advertisement, which I think is solved. - The protocol extension has a fairly low length limit. One pkt-line per protocol extension should do it. - Because the protocol exchange starts by the server side advertising all its refs, even when the fetcher is interested in a single ref, the initial overhead is nontrivial, especially when you are doing a small incremental update. The worst case is an auto-builder that polls every five minutes, even when there is no new commits to be fetched. One of the reason v2 is started, should be ok with current v2 design. - Because we recompute every time, taking into account of what the fetcher has, in addition to what the fetcher obtained earlier from us in order to reduce the transferred bytes, the payload for incremental updates become tailor-made for each fetch and cannot be easily reused. Well, we reuse at a lower level, pack-objects would try to copy existing deltas instead of making new ones. We can cache new deltas in hope that they may be useful for the next fetch. But that has nothing to do with the protocol.. - The semantics of the side-bands are unclear. - Is band #2 meant only for progress output (I think the current protocol handlers assume that and unconditionally squelch it under --quiet)? Do we rather want a dedicated progress and error message sidebands instead? - Is band #2 meant for human consumption, or do we expect the other end to interpret and act on it? If the former, would it make sense to send locale information from the client side and ask the server side to produce its output with _(message)? The interpretation of side-band could be changed by introducing a new extension, couldn't it? - The semantics of packet_flush() is suboptimal, and this shortcoming seeps through to the protocol mapped to the smart-HTTP transport. ... I don't have an answer to this one. So the reaction is, if it is not broken (in pratice, not in theory), don't touch it. I know I'm burying my head in the sand.. - The fetch-pack direction does the common-parent discovery but the push-pack direction does not. This is OK for the normal fast-forward push, in which case we will see a known commit on the tip of the branch we are pushing into, but makes forced push inefficient. Introducing the ref exchange in push-pack could be done in an extension too, I think. - The existing common-parent discovery done on the fetch-pack side enumerates commits contiguously traversing the history to the past. We might want to go exponential or Fibonacci to quickly find an ancient common commit and bisect the history from there (or it might turn out not to be worth it). Hm.. i'm wondering if we can already do this with v1 if we have enough man power. - We may want to revamp the builtin/receive-pack.c::report() that reports the final result of a push back to the pusher to tell the exact object name that sits at the updated tips of refs, not just refnames. It will allow the server side to accept a push of commit X to a branch, do some magic on X (e.g. rebase it on top of the current tip, merge it with the current tip, or let a hook to rewrite the commit in any way it deems appropriate) and put the resulting commit Y at the tip of the branch. Without such a revamp, it is currently not possible to sensibly allow the server side to rewrite what got pushed. Sounds more coding than changing the protocol, which should be possible with another extension. - If we were to start allowing the receiver side to rewrite pushed commits, the updated send-pack protocol must be able to send the new objects created by that magic back to the pusher. The current protocol does not allow the receive-pack to send packdata back to send-pack. Is it
[PATCH v6 0/4] cat-file: add a '--literally' option
The changes made in this version are : * unpack_sha1_header_to_strbuf() now checks for Z_STREAM_END and also the return is not changed to status (as per Junios suggestion) as this breaks the check done in sha1_loose_object_info() as the return is sometimes Z_BUF_ERROR (-5). * In sha1_loose_object_info() if the status is set, then change the type to status. Also check for this in cat-file.c * Add documentation and tests for the same. Thanks for your suggestions. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/4] cat-file: add documentation for '--literally' option.
Signed-off-by: Karthik Nayak karthik@gmail.com --- Documentation/git-cat-file.txt | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt index f6a16f4..8bac7bd 100644 --- a/Documentation/git-cat-file.txt +++ b/Documentation/git-cat-file.txt @@ -9,7 +9,7 @@ git-cat-file - Provide content or type and size information for repository objec SYNOPSIS [verse] -'git cat-file' (-t | -s | -e | -p | type | --textconv ) object +'git cat-file' (-t [--literally]| -s [--literally]| -e | -p | type | --textconv ) object 'git cat-file' (--batch | --batch-check) list-of-objects DESCRIPTION @@ -69,6 +69,10 @@ OPTIONS not be combined with any other options or arguments. See the section `BATCH OUTPUT` below for details. +--literally:: + Print information of broken/corrupt objects of unknown type without + throwing an error. To be used combined with '-s' or '-t' option. + OUTPUT -- If '-t' is specified, one of the type. -- 2.3.1.172.g04a1281 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/4] cat-file: teach cat-file a '--literally' option
Currently 'git cat-file' throws an error while trying to
print the type or size of a broken/corrupt object which is
created using 'git hash-object --literally'. This is
because these objects are usually of unknown types.
Teach git cat-file a '--literally' option where it prints
the type or size of a broken/corrupt object without throwing
an error.
Modify '-t' and '-s' options to call sha1_object_info_extended()
directly to support the '--literally' option.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Eric Sunshine sunshine@sunshineco
Signed-off-by: Karthik Nayak karthik@gmail.com
---
builtin/cat-file.c | 38 +-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index df99df4..91ceae0 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -9,13 +9,20 @@
#include userdiff.h
#include streaming.h
-static int cat_one_file(int opt, const char *exp_type, const char *obj_name)
+static int cat_one_file(int opt, const char *exp_type, const char *obj_name,
+ int literally)
{
unsigned char sha1[20];
enum object_type type;
char *buf;
unsigned long size;
struct object_context obj_context;
+ struct object_info oi = {NULL};
+ struct strbuf sb = STRBUF_INIT;
+ unsigned flags = LOOKUP_REPLACE_OBJECT;
+
+ if (literally)
+ flags |= LOOKUP_LITERALLY;
if (get_sha1_with_context(obj_name, 0, sha1, obj_context))
die(Not a valid object name %s, obj_name);
@@ -23,16 +30,24 @@ static int cat_one_file(int opt, const char *exp_type,
const char *obj_name)
buf = NULL;
switch (opt) {
case 't':
- type = sha1_object_info(sha1, NULL);
- if (type 0) {
- printf(%s\n, typename(type));
+ oi.typep = type;
+ oi.typename = sb;
+ if (sha1_object_info_extended(sha1, oi, flags) 0)
+ die(git cat-file: could not get object info);
+ if (type = 0 sb.len) {
+ printf(%s\n, sb.buf);
+ strbuf_release(sb);
return 0;
}
break;
case 's':
- type = sha1_object_info(sha1, size);
- if (type 0) {
+ oi.typep = type;
+ oi.typename = sb;
+ oi.sizep = size;
+ if (sha1_object_info_extended(sha1, oi, flags) 0)
+ die(git cat-file: could not get object info);
+ if (type = 0 sb.len) {
printf(%lu\n, size);
return 0;
}
@@ -323,7 +338,7 @@ static int batch_objects(struct batch_options *opt)
}
static const char * const cat_file_usage[] = {
- N_(git cat-file (-t | -s | -e | -p | type | --textconv) object),
+ N_(git cat-file (-t [--literally]|-s
[--literally]|-e|-p|type|--textconv) object),
N_(git cat-file (--batch | --batch-check) list-of-objects),
NULL
};
@@ -359,6 +374,7 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
int opt = 0;
const char *exp_type = NULL, *obj_name = NULL;
struct batch_options batch = {0};
+ int literally = 0;
const struct option options[] = {
OPT_GROUP(N_(type can be one of: blob, tree, commit, tag)),
@@ -369,6 +385,8 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
OPT_SET_INT('p', NULL, opt, N_(pretty-print object's
content), 'p'),
OPT_SET_INT(0, textconv, opt,
N_(for blob objects, run textconv on object's
content), 'c'),
+ OPT_BOOL( 0, literally, literally,
+ N_(get information about corrupt objects for
debugging Git)),
{ OPTION_CALLBACK, 0, batch, batch, format,
N_(show info and content of objects fed from the
standard input),
PARSE_OPT_OPTARG, batch_option_callback },
@@ -380,7 +398,7 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
git_config(git_cat_file_config, NULL);
- if (argc != 3 argc != 2)
+ if (argc 2 || argc 4)
usage_with_options(cat_file_usage, options);
argc = parse_options(argc, argv, prefix, options, cat_file_usage, 0);
@@ -405,5 +423,7 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
if (batch.enabled)
return batch_objects(batch);
- return cat_one_file(opt, exp_type, obj_name);
+ if (literally opt != 't' opt != 's')
+ die(git cat-file --literally: use with -s or -t);
+ return cat_one_file(opt, exp_type, obj_name, literally);
}
--
2.3.1.172.g04a1281
--
To unsubscribe from this list: send the line unsubscribe
[BUG] 'git merge --quiet' is not always quiet
In the following session, a 'git merge' command shows some output even with the '--quiet' flag supplied. ~/tmp $ git init example Initialized empty Git repository in /tmp/example/.git/ ~/tmp $ cd example/ ~/tmp/example $ git commit --allow-empty -m'initial commit' [master (root-commit) a7329b5] initial commit ~/tmp/example $ git checkout -b b1 Switched to a new branch 'b1' ~/tmp/example $ git commit --allow-empty -m'commit on branch' [b1 d15e5ac] commit on branch ~/tmp/example $ git checkout master Switched to branch 'master' ~/tmp/example $ git merge --quiet --no-ff --no-edit b1 Already up-to-date! ~/tmp/example $ My expectation is that '--quiet' would suppress all output, even this one. I'm on Git 1.9.1, but I've been informed on IRC that this happens even on latest. // Carl -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/4] sha1_file.c: support reading from a loose object of unknown type
Update sha1_loose_object_info() to optionally allow it to read
from a loose object file of unknown/bogus type; as the function
usually returns the type of the object it read in the form of enum
for known types, add an optional typename field to receive the
name of the type in textual form and a flag to indicate the reading
of a loose object file of unknown/bogus type.
Add parse_sha1_header_extended() which acts as a wrapper around
parse_sha1_header() allowing more information to be obtained.
Add unpack_sha1_header_to_strbuf() to unpack sha1 headers of
unknown/corrupt objects which have a unknown sha1 header size to
a strbuf structure. This was written by Junio C Hamano but tested
by me.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
Signed-off-by: Karthik Nayak karthik@gmail.com
---
cache.h | 2 ++
sha1_file.c | 111
2 files changed, 91 insertions(+), 22 deletions(-)
diff --git a/cache.h b/cache.h
index 4d02efc..949ef4c 100644
--- a/cache.h
+++ b/cache.h
@@ -830,6 +830,7 @@ extern int is_ntfs_dotgit(const char *name);
/* object replacement */
#define LOOKUP_REPLACE_OBJECT 1
+#define LOOKUP_LITERALLY 2
extern void *read_sha1_file_extended(const unsigned char *sha1, enum
object_type *type, unsigned long *size, unsigned flag);
static inline void *read_sha1_file(const unsigned char *sha1, enum object_type
*type, unsigned long *size)
{
@@ -1296,6 +1297,7 @@ struct object_info {
unsigned long *sizep;
unsigned long *disk_sizep;
unsigned char *delta_base_sha1;
+ struct strbuf *typename;
/* Response */
enum {
diff --git a/sha1_file.c b/sha1_file.c
index 69a60ec..8b58b94 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1564,6 +1564,34 @@ int unpack_sha1_header(git_zstream *stream, unsigned
char *map, unsigned long ma
return git_inflate(stream, 0);
}
+static int unpack_sha1_header_to_strbuf(git_zstream *stream, unsigned char
*map,
+ unsigned long mapsize,
+ struct strbuf *header)
+{
+ unsigned char buffer[32], *cp;
+ unsigned long bufsiz = sizeof(buffer);
+ int status;
+
+ status = unpack_sha1_header(stream, map, mapsize, buffer, bufsiz);
+
+ if (status) {
+ strbuf_add(header, buffer, stream-next_out - buffer);
+ return status;
+ }
+
+ do {
+ status = git_inflate(stream, 0);
+ strbuf_add(header, buffer, stream-next_out - buffer);
+ for (cp = buffer; cp stream-next_out; cp++)
+ if (!*cp)
+ /* Found the NUL at the end of the header */
+ return 0;
+ stream-next_out = buffer;
+ stream-avail_out = bufsiz;
+ } while (status != Z_STREAM_END);
+ return -1;
+}
+
static void *unpack_sha1_rest(git_zstream *stream, void *buffer, unsigned long
size, const unsigned char *sha1)
{
int bytes = strlen(buffer) + 1;
@@ -1614,27 +1642,24 @@ static void *unpack_sha1_rest(git_zstream *stream, void
*buffer, unsigned long s
* too permissive for what we want to check. So do an anal
* object header parse by hand.
*/
-int parse_sha1_header(const char *hdr, unsigned long *sizep)
+int parse_sha1_header_extended(const char *hdr, struct object_info *oi,
+ unsigned int flags)
{
- char type[10];
- int i;
+ struct strbuf typename = STRBUF_INIT;
unsigned long size;
+ int type;
/*
* The type can be at most ten bytes (including the
* terminating '\0' that we add), and is followed by
* a space.
*/
- i = 0;
for (;;) {
char c = *hdr++;
if (c == ' ')
break;
- type[i++] = c;
- if (i = sizeof(type))
- return -1;
+ strbuf_addch(typename, c);
}
- type[i] = 0;
/*
* The length must follow immediately, and be in canonical
@@ -1652,12 +1677,39 @@ int parse_sha1_header(const char *hdr, unsigned long
*sizep)
size = size * 10 + c;
}
}
- *sizep = size;
+ type = type_from_string_gently(typename.buf, typename.len, 1);
+ if (oi-sizep)
+ *oi-sizep = size;
+ if (oi-typename)
+ strbuf_addbuf(oi-typename, typename);
+ strbuf_release(typename);
+
+ /*
+* Set type to 0 if its an unknown object and
+* we're obtaining the type using '--literally'
+* option.
+*/
+ if ((flags LOOKUP_LITERALLY) (type == -1))
+ type = 0;
+ else if (type == -1)
+ die(invalid object type);
+ if (oi-typep)
+ *oi-typep =
Re: git 2.3.4, ssh: Could not resolve hostname
Peff The colons were part of the output. The '' replaces the domain in the response. The domain is an internal one that my client would rather keep private. But this got me to think that this might be an important detail: I am using GIT from a remote node on a Cisco AnyConnect VPN with DNS served by ActiveDirectory. Reid On Apr 2, 2015, at 11:09 AM, Jeff King p...@peff.net wrote: On Thu, Apr 02, 2015 at 10:18:33AM -0700, Reid Woodbury Jr. wrote: After upgrading from GIT 2.3.3 to 2.3.4 (on Mac OS X 10.10.2, installed with MacPorts) I received this error message when doing a push: $ git push ssh: Could not resolve hostname :: nodename nor servname provided, or not known fatal: Could not read from remote repository. It is hard to tell from the obfuscated output, but perhaps the problem is the two colons (i.e., git is feeding a hostname like foo: when it should be just foo). There were some changes in v2.3.4 related to parsing ssh URLs. +cc Torsten, who worked on that code. Can you show us your git config (presumably the host is defined in remote.origin.url in .git/config of the repository)? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 2/4] cat-file: teach cat-file a '--literally' option
Karthik Nayak karthik@gmail.com writes:
Currently 'git cat-file' throws an error while trying to
print the type or size of a broken/corrupt object which is
created using 'git hash-object --literally'. This is
because these objects are usually of unknown types.
Teach git cat-file a '--literally' option where it prints
the type or size of a broken/corrupt object without throwing
an error.
Modify '-t' and '-s' options to call sha1_object_info_extended()
directly to support the '--literally' option.
Helped-by: Junio C Hamano gits...@pobox.com
Helped-by: Eric Sunshine sunshine@sunshineco
s/$/.com/ perhaps?
Signed-off-by: Karthik Nayak karthik@gmail.com
---
builtin/cat-file.c | 38 +-
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index df99df4..91ceae0 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -9,13 +9,20 @@
#include userdiff.h
#include streaming.h
-static int cat_one_file(int opt, const char *exp_type, const char *obj_name)
+static int cat_one_file(int opt, const char *exp_type, const char *obj_name,
+ int literally)
{
unsigned char sha1[20];
enum object_type type;
char *buf;
unsigned long size;
struct object_context obj_context;
+ struct object_info oi = {NULL};
+ struct strbuf sb = STRBUF_INIT;
+ unsigned flags = LOOKUP_REPLACE_OBJECT;
+
+ if (literally)
+ flags |= LOOKUP_LITERALLY;
if (get_sha1_with_context(obj_name, 0, sha1, obj_context))
die(Not a valid object name %s, obj_name);
@@ -23,16 +30,24 @@ static int cat_one_file(int opt, const char *exp_type,
const char *obj_name)
buf = NULL;
switch (opt) {
case 't':
- type = sha1_object_info(sha1, NULL);
- if (type 0) {
- printf(%s\n, typename(type));
+ oi.typep = type;
+ oi.typename = sb;
+ if (sha1_object_info_extended(sha1, oi, flags) 0)
+ die(git cat-file: could not get object info);
+ if (type = 0 sb.len) {
+ printf(%s\n, sb.buf);
+ strbuf_release(sb);
return 0;
}
break;
case 's':
- type = sha1_object_info(sha1, size);
- if (type 0) {
+ oi.typep = type;
+ oi.typename = sb;
+ oi.sizep = size;
+ if (sha1_object_info_extended(sha1, oi, flags) 0)
+ die(git cat-file: could not get object info);
+ if (type = 0 sb.len) {
printf(%lu\n, size);
return 0;
}
@@ -323,7 +338,7 @@ static int batch_objects(struct batch_options *opt)
}
static const char * const cat_file_usage[] = {
- N_(git cat-file (-t | -s | -e | -p | type | --textconv) object),
+ N_(git cat-file (-t [--literally]|-s
[--literally]|-e|-p|type|--textconv) object),
N_(git cat-file (--batch | --batch-check) list-of-objects),
NULL
};
@@ -359,6 +374,7 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
int opt = 0;
const char *exp_type = NULL, *obj_name = NULL;
struct batch_options batch = {0};
+ int literally = 0;
const struct option options[] = {
OPT_GROUP(N_(type can be one of: blob, tree, commit, tag)),
@@ -369,6 +385,8 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
OPT_SET_INT('p', NULL, opt, N_(pretty-print object's
content), 'p'),
OPT_SET_INT(0, textconv, opt,
N_(for blob objects, run textconv on object's
content), 'c'),
+ OPT_BOOL( 0, literally, literally,
+ N_(get information about corrupt objects for
debugging Git)),
{ OPTION_CALLBACK, 0, batch, batch, format,
N_(show info and content of objects fed from the
standard input),
PARSE_OPT_OPTARG, batch_option_callback },
@@ -380,7 +398,7 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
git_config(git_cat_file_config, NULL);
- if (argc != 3 argc != 2)
+ if (argc 2 || argc 4)
usage_with_options(cat_file_usage, options);
argc = parse_options(argc, argv, prefix, options, cat_file_usage, 0);
@@ -405,5 +423,7 @@ int cmd_cat_file(int argc, const char **argv, const char
*prefix)
if (batch.enabled)
return batch_objects(batch);
- return cat_one_file(opt, exp_type, obj_name);
+ if (literally opt != 't' opt != 's')
+ die(git cat-file --literally: use with -s or -t);
+ return cat_one_file(opt, exp_type, obj_name, literally);
}
--
To unsubscribe from this
Re: [PATCH v6 1/4] sha1_file.c: support reading from a loose object of unknown type
Karthik Nayak karthik@gmail.com writes:
+static int unpack_sha1_header_to_strbuf(git_zstream *stream, unsigned char
*map,
+ unsigned long mapsize,
+ struct strbuf *header)
+{
+ unsigned char buffer[32], *cp;
+ unsigned long bufsiz = sizeof(buffer);
+ int status;
+
+ status = unpack_sha1_header(stream, map, mapsize, buffer, bufsiz);
I briefly wondered if this can return Z_BUF_ERROR, but it is OK
because we do not call inflate with Z_FINISH in unpack_sha1_header()
for obvious reasons ;-)
+ if (status) {
+ strbuf_add(header, buffer, stream-next_out - buffer);
+ return status;
+ }
+ do {
+ status = git_inflate(stream, 0);
+ strbuf_add(header, buffer, stream-next_out - buffer);
+ for (cp = buffer; cp stream-next_out; cp++)
+ if (!*cp)
+ /* Found the NUL at the end of the header */
+ return 0;
+ stream-next_out = buffer;
+ stream-avail_out = bufsiz;
+ } while (status != Z_STREAM_END);
+ return -1;
+}
OK.
@@ -1614,27 +1642,24 @@ static void *unpack_sha1_rest(git_zstream *stream,
void *buffer, unsigned long s
* too permissive for what we want to check. So do an anal
* object header parse by hand.
*/
-int parse_sha1_header(const char *hdr, unsigned long *sizep)
+int parse_sha1_header_extended(const char *hdr, struct object_info *oi,
+unsigned int flags)
{
- char type[10];
- int i;
+ struct strbuf typename = STRBUF_INIT;
unsigned long size;
+ int type;
/*
* The type can be at most ten bytes (including the
Is this still a valid comment?
* terminating '\0' that we add), and is followed by
* a space.
*/
- i = 0;
for (;;) {
char c = *hdr++;
if (c == ' ')
break;
- type[i++] = c;
- if (i = sizeof(type))
- return -1;
+ strbuf_addch(typename, c);
}
- type[i] = 0;
/*
* The length must follow immediately, and be in canonical
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 2.3.4, ssh: Could not resolve hostname
On Thu, Apr 02, 2015 at 11:58:13AM -0700, Reid Woodbury Jr. wrote: The colons were part of the output. The '' replaces the domain in the response. OK, if the double colons are correct, then that is almost certainly the problem: $ ssh does-not-exist ssh: Could not resolve hostname does-not-exist: No address associated with hostname $ ssh does-not-exist: ssh: Could not resolve hostname does-not-exist:: No address associated with hostname The domain is an internal one that my client would rather keep private. Can you give us a hint as to the format of your remote URL? This works: $ git push does-not-exist:repo.git ssh: Could not resolve hostname does-not-exist: No address associated with hostname in the sense that it looks up the right hostname (which is of course nonsense, but note the single colon in the error message). So does: $ git push ssh://does-not-exist/repo.git ssh: Could not resolve hostname does-not-exist: No address associated with hostname but this does not: $ git push ssh://does-not-exist:/repo.git ssh: Could not resolve hostname does-not-exist:: No address associated with hostname (note the doubled colon). v2.3.3 did strip off that extra colon, but I am not sure the URL above (i.e., a colon with no hostname) is actually sane. IOW, it may have happened to work in older versions, but I'm not sure we would want to promise to keep it working. Can you show us what your URL looks like, obfuscating the names but keeping the syntax the same? Also, are you using the insteadOf config syntax at all (which could easily lead to funny splicing, I imagine). But this got me to think that this might be an important detail: I am using GIT from a remote node on a Cisco AnyConnect VPN with DNS served by ActiveDirectory. If the extra colon is indeed the problem, I don't think the DNS setup is relevant. The name git is feeding to ssh is bogus. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kernel bug caused by 'git apply' misapplying a patch with ambiguous chunk
Hello everyone, we recently ran into a kernel bug caused by git misapplying this patch: https://lkml.org/lkml/2014/7/3/896 . The chunk '@@ -653,6 +655,7 @@' in tegra124.dtsi (the second file in the patch) has ambiguous context (there are several almost identical PHY nodes in the file). Git applied the chunk to the second PHY node when it should have been applied to the first node. You can reproduce this by checking out, for example, version 3.16 of the Linux kernel and applying the patch from the above link and then looking at arch/arm/boot/dts/tegra124.dtsi and verifying that git has added the 'nvidia,has-utmi-pad-registers' property to the second, instead of the first 'phy' node. Of course this is probably rather hard to fix on the applying end; but perhaps format-patch could check for ambiguous chunks and either warn the user or increase the context size automatically, or apply could warn about the chunk being ambiguous? Thanks, Mikko Perttunen -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] systemd socket activation support
Eric Sunshine sunsh...@sunshineco.com writes: On Wed, Apr 1, 2015 at 9:23 PM, Shawn Landden sh...@churchofgit.com wrote: From: Shawn Landden shawnland...@gmail.com [PATCH] systemd socket activation support This patch feels like an RFC rather than a properly fleshed-out submission. If so, indicate such in the subject. Also, mention the area you're touching, followed by a colon, followed by the summary of the change: [PATCH/RFC] daemon: add systemd support ... Everything Eric said ;-) Another thing is that this must be a build-time conditional. Not all platforms can use systemd in the first place, and some people may choose not to use it even if the platform is capable of. I was somewhat surprised that sd-daemon.c needed to be built on our side, not used from systemd support library, as what it did looked very common and not specific to our needs. I would have expected to see inclusion of sd-daemon.h with -lsystemd-daemon or something on the command line. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel bug caused by 'git apply' misapplying a patch with ambiguous chunk
Mikko Perttunen mikko.perttu...@kapsi.fi writes: Of course this is probably rather hard to fix on the applying end; but perhaps format-patch could check for ambiguous chunks and either warn the user or increase the context size automatically, or apply could warn about the chunk being ambiguous? Interesting thought. Let me rephrase to make sure I got your thought process correctly. Imagine you started from an original that had two cut-and-pasted codeblocks A and B in the same file and updated one of them, say A, and then sent out the patch that turns A into A1. Meanwhile, somebody started from the same original and updated the same codeblock A in the upstream already to A2. Your patch applies cleanly to codeblock B and turns it to A1, which is a mispatch. And you cannot even detect the problem while applying. But if you are starting from the original with idential A and B, format-patch can see that the resulting patch to turn A to A1 can be misunderstood to be a patch to change B to A1 instead. So in that case, you _could_ detect. But imagine if you started from an original that had A and C, that are clearly different. Your change turns A into A1. In the meantime, the upstream started from the same original, and changed C into B that looks identical to A. The same thing would happen to your patch when you try to apply it. git apply could try to diagnose this situation and warn. But you cannot check when your format-patch produces a patch that turns A,C into A1,C, as there is no ambiguity in the original. So, - format-patch could try to help, but it won't be a complete solution. - apply could try to help, but it won't be a complete solution. I am not sure if having both would make it complete, but I doubt it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] protocol upload-pack-v2
Duy Nguyen pclo...@gmail.com writes: On Wed, Apr 1, 2015 at 2:58 AM, Junio C Hamano gits...@pobox.com wrote: This is a follow-up on $gmane/264553, which is a continuation of $gmane/264000, but instead of giving two required readings to readers, I'll start with reproduction of the two, and add a few more things the current protocol lacks that I would want to see in the updated protocol. I think the important thing to get v2 started is making sure we do not need v3 to get rid of any of these limitations. In other words v2 should be extensible enough to implement them later. Yes. ... I don't have an answer to this one. So the reaction is,... broken (in pratice, not in theory), don't touch it. I know I'm burying my head in the sand.. ... Introducing the ref exchange in push-pack could be done in an extension too, I think. Thanks, but you do not have to solve these sample issues here. As you said above, your primary goal at this stage is to make sure v2 is extensible to cover future needs, and in order to do so, you need to make sure what's lacking list is fairly complete. You are not helping from that point of view. I'd like to see a new protocol that lets us overcome the limitations (did I miss others? I am sure people can help here) sometime this year. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel bug caused by 'git apply' misapplying a patch with ambiguous chunk
On 04/02/2015 06:59 PM, Junio C Hamano wrote: Mikko Perttunen mikko.perttu...@kapsi.fi writes: Of course this is probably rather hard to fix on the applying end; but perhaps format-patch could check for ambiguous chunks and either warn the user or increase the context size automatically, or apply could warn about the chunk being ambiguous? Interesting thought. Let me rephrase to make sure I got your thought process correctly. Imagine you started from an original that had two cut-and-pasted codeblocks A and B in the same file and updated one of them, say A, and then sent out the patch that turns A into A1. Meanwhile, somebody started from the same original and updated the same codeblock A in the upstream already to A2. Your patch applies cleanly to codeblock B and turns it to A1, which is a mispatch. And you cannot even detect the problem while applying. But if you are starting from the original with idential A and B, format-patch can see that the resulting patch to turn A to A1 can be misunderstood to be a patch to change B to A1 instead. So in that case, you _could_ detect. But imagine if you started from an original that had A and C, that are clearly different. Your change turns A into A1. In the meantime, the upstream started from the same original, and changed C into B that looks identical to A. The same thing would happen to your patch when you try to apply it. git apply could try to diagnose this situation and warn. But you cannot check when your format-patch produces a patch that turns A,C into A1,C, as there is no ambiguity in the original. So, - format-patch could try to help, but it won't be a complete solution. - apply could try to help, but it won't be a complete solution. I am not sure if having both would make it complete, but I doubt it. I agree. I think you can also create a situation where neither would detect the problem, if the upstream changes C such that A-A1 can be applied on it and at the same time changes A such that A-A1 no longer applies. However, such a situation should be rare, so I think these checks would be useful. In this case, the ambiguity existed the whole time both on the submitter's end and in upstream. Upstream just added more stuff into the file causing the line numbers to shift. So in this case a check in either subcommand would have caught it. Mikko -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2] systemd socket activation support
On Thu, Apr 2, 2015 at 12:15 PM, Shawn Landden sh...@churchofgit.com wrote: [RFC 2] systemd socket activation support Rephrase this as: [PATCH/RFC v2] daemon: add systemd support systemd support git-daemon's --inetd mode as well. Unable to make sense of this sentence (fragment). A better commit message would explain the purpose of the change, its justification, and any important issues which readers need to know to understand and review the patch. See my previous review[1] for some ideas. [1]: http://article.gmane.org/gmane.comp.version-control.git/266631 v2: actually test... It is indeed a good idea to explain what changed between versions of the patch, however, this isn't telling us much. To ease the task of reviewers, explain changes between versions with sufficient detail so that readers don't need to guess. Also, it is very helpful to provide a link to the previous version of the patch and its discussion since this is a high-traffic list, and reviewers won't necessarily remember the details of the previous version. Also, you don't generally want this sort of commentary recorded in the permanent project history, so it doesn't belong in the commit message proper. Instead, place it below the --- line following your sign-off, just above the diffstat. Signed-off-by: Shawn Landden sh...@churchofgit.com --- This is where you should place commentary which you don't want in the permanent project history. diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt index a69b361..898e01f 100644 --- a/Documentation/git-daemon.txt +++ b/Documentation/git-daemon.txt @@ -20,6 +20,7 @@ SYNOPSIS [--inetd | [--listen=host_or_ipaddr] [--port=n] [--user=user [--group=group]]] + [--systemd] [directory...] DESCRIPTION @@ -190,6 +191,12 @@ Git configuration files in that directory are readable by `user`. exiting with a zero status). It can also look at the $REMOTE_ADDR and $REMOTE_PORT environment variables to learn about the requestor when making this decision. +--systemd:: + For running git-daemon under systemd(1) which will pass + an open connection. This is similar to --inetd, except + that more than one address/port can be listened to at once + both through systemd and through --listen, and git-daemon doesn't get + invoked for every connection. For more details see systemd.socket(5). The documentation for the --inetd option mentions other options with which it is incompatible. This new documentation probably ought to do the same. Moreover, you should update the --inetd documentation to mention that it is incompatible with --systemd. Unfortunately, you plopped this new text right in the middle of the the description of --access-hook (which is continued by the + line and the left-justified paragraph below). If you format the documentation and look at the before and after output, you will see the problem. + The external command can optionally write a single line to its standard output to be sent to the requestor as an error message when @@ -304,7 +311,25 @@ selectively enable/disable services per repository:: uploadpack = false uploadarch = true Unfortunately, the new example you've added (below) doesn't format properly, and results in Asciidoc warnings. To ensure correctness, follow the other examples more closely, and try formatting it yourself. ++ This + line incorrectly ties your new example to the preceding selectively enable/disable services per repository item. Just insert a blank line here rather than a + line. +systemd configuration example: This item must end with ::, not just :. + Instead of a blank line, this should be a + line in order to tie the example (below) to the systemd configuration example item. +# /etc/systemd/system/git-daemon.socket +[Unit] +Description=Git Daemon socket + +[Socket] +ListenStream=9418 + +[Install] +WantedBy=sockets.target +# /etc/systemd/system/git-daemon.service +[Unit] +Description=Git Daemon +[Service] +ExecStart=/usr/lib/git-core/git-daemon --systemd --reuseaddr --base-path=/var/lib /var/lib/git +User=gitdaemon The example block must be delimited by -- lines to be formatted correctly as literal text. (Both -- lines should have the same number of dashes in order to satisfy all versions of Asciidoc). Also, indent the text as other examples in git-daemon.txt. More below. ENVIRONMENT --- diff --git a/daemon.c b/daemon.c index 9ee2187..e809a4c 100644 --- a/daemon.c +++ b/daemon.c @@ -4,6 +4,7 @@ #include run-command.h #include strbuf.h #include string-list.h +#include sd-daemon.h #ifndef HOST_NAME_MAX #define HOST_NAME_MAX 256 @@ -29,6 +30,7 @@ static const char daemon_usage[] = [--access-hook=path]\n
[RFC 2] systemd socket activation support
systemd support git-daemon's --inetd mode as well.
v2: actually test...
Signed-off-by: Shawn Landden sh...@churchofgit.com
---
Documentation/git-daemon.txt | 25 +++
Makefile | 1 +
daemon.c | 35 --
sd-daemon.c | 152 +++
sd-daemon.h | 104 +
5 files changed, 311 insertions(+), 6 deletions(-)
create mode 100644 sd-daemon.c
create mode 100644 sd-daemon.h
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index a69b361..898e01f 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -20,6 +20,7 @@ SYNOPSIS
[--inetd |
[--listen=host_or_ipaddr] [--port=n]
[--user=user [--group=group]]]
+ [--systemd]
[directory...]
DESCRIPTION
@@ -190,6 +191,12 @@ Git configuration files in that directory are readable by
`user`.
exiting with a zero status). It can also look at the $REMOTE_ADDR
and $REMOTE_PORT environment variables to learn about the
requestor when making this decision.
+--systemd::
+ For running git-daemon under systemd(1) which will pass
+ an open connection. This is similar to --inetd, except
+ that more than one address/port can be listened to at once
+ both through systemd and through --listen, and git-daemon doesn't get
+ invoked for every connection. For more details see systemd.socket(5).
+
The external command can optionally write a single line to its
standard output to be sent to the requestor as an error message when
@@ -304,7 +311,25 @@ selectively enable/disable services per repository::
uploadpack = false
uploadarch = true
++
+systemd configuration example:
+
+# /etc/systemd/system/git-daemon.socket
+[Unit]
+Description=Git Daemon socket
+
+[Socket]
+ListenStream=9418
+
+[Install]
+WantedBy=sockets.target
+# /etc/systemd/system/git-daemon.service
+[Unit]
+Description=Git Daemon
+[Service]
+ExecStart=/usr/lib/git-core/git-daemon --systemd --reuseaddr
--base-path=/var/lib /var/lib/git
+User=gitdaemon
ENVIRONMENT
---
diff --git a/Makefile b/Makefile
index 5f3987f..4a813b9 100644
--- a/Makefile
+++ b/Makefile
@@ -765,6 +765,7 @@ LIB_OBJS += rerere.o
LIB_OBJS += resolve-undo.o
LIB_OBJS += revision.o
LIB_OBJS += run-command.o
+LIB_OBJS += sd-daemon.o
LIB_OBJS += send-pack.o
LIB_OBJS += sequencer.o
LIB_OBJS += server-info.o
diff --git a/daemon.c b/daemon.c
index 9ee2187..e809a4c 100644
--- a/daemon.c
+++ b/daemon.c
@@ -4,6 +4,7 @@
#include run-command.h
#include strbuf.h
#include string-list.h
+#include sd-daemon.h
#ifndef HOST_NAME_MAX
#define HOST_NAME_MAX 256
@@ -29,6 +30,7 @@ static const char daemon_usage[] =
[--access-hook=path]\n
[--inetd | [--listen=host_or_ipaddr] [--port=n]\n
[--detach] [--user=user [--group=group]]\n
+ [--systemd]\n
[directory...];
/* List of acceptable pathname prefixes */
@@ -1176,11 +1178,22 @@ static void store_pid(const char *path)
}
static int serve(struct string_list *listen_addr, int listen_port,
-struct credentials *cred)
+struct credentials *cred, int systemd_mode)
{
struct socketlist socklist = { NULL, 0, 0 };
- socksetup(listen_addr, listen_port, socklist);
+ if (systemd_mode) {
+ int i;
+ int n;
+
+ n = sd_listen_fds(0);
+ ALLOC_GROW(socklist.list, socklist.nr + n, socklist.alloc);
+ for (i = 0; i n; i++)
+ socklist.list[socklist.nr++] = SD_LISTEN_FDS_START + i;
+ }
+
+ if (listen_addr-nr 0 || !systemd_mode)
+ socksetup(listen_addr, listen_port, socklist);
if (socklist.nr == 0)
die(unable to allocate any listen sockets on port %u,
listen_port);
@@ -1196,7 +1209,7 @@ int main(int argc, char **argv)
{
int listen_port = 0;
struct string_list listen_addr = STRING_LIST_INIT_NODUP;
- int serve_mode = 0, inetd_mode = 0;
+ int serve_mode = 0, inetd_mode = 0, systemd_mode = 0;
const char *pid_file = NULL, *user_name = NULL, *group_name = NULL;
int detach = 0;
struct credentials *cred = NULL;
@@ -1331,6 +1344,10 @@ int main(int argc, char **argv)
informative_errors = 0;
continue;
}
+ if (!strcmp(arg, --systemd)) {
+ systemd_mode = 1;
+ continue;
+ }
if (!strcmp(arg, --)) {
ok_paths = argv[i+1];
break;
@@ -1349,14 +1366,20 @@ int main(int argc, char **argv)
/* avoid splitting a message in
Re: RFC: Renaming git rebase --onto
Junio C Hamano venit, vidit, dixit 30.03.2015 23:12: Jonathon Mah m...@jonathonmah.com writes: During a few years of discussing git operations with colleagues, I’ve found the “git rebase --onto” operation particularly ambiguous. The reason is that I always describe a rebase operation as “onto” something else (because of the English phrase “A is based on B”). For example: $ git rebase new-base # “Rebase HEAD onto new-base (from merge-base of HEAD and new-base) $ git rebase new-base my-branch # “Rebase my-branch onto new-base (from merge-base of my-branch and new-base)” Personally, I understand “git-rebase --onto new-base old-base” as meaning “rebase from old-base to new-base”. Some prepositions that might make this clearer: $ git rebase --from old-base new-base # “Rebase HEAD onto new-base, from old-base $ git rebase --after old-base new-base # “Rebase commits on HEAD after old-base HEAD onto new-base $ git rebase --excluding old-base new-base # “Rebase HEAD onto new-base, excluding commit old-base (and its parents) In all cases this would change the order of the arguments compared to --onto, making it more consistent with the no-option rebase. The bog-standard rebase is git rebase U which rebases the current history that has diverged from the history leading to U on to U. Or git rebase U BRANCH which rebases BRANCH that has diverged from the history leading to U on to U. In both of these invocations, these arguments define which part of the local history is replayed. Now, git rebase [--onto O] $other_args is just a way to say $other_args still define which part of the local history is replayed, but you are replaying on something that is different from the usual default case (which is U). Which feels very consistent between the cases with and without the extra --onto parameter, at least to me. Hence, if you change order in any way, I would think you would break the existing consistency. I suspect that this thread is a symptom of something unrelated, though. There might be something wrong in your workflow if you find yourself using --onto too often, for example, and that may be the issue we should be focusing on, not on how rebase --onto is spelled. What do others think? Is my view of “onto” common or unusual? common or unusual is a question we cannot answer, I would say. People who are used to rebase may be so used to it that it might feel natural to them but cannot tell if that is only because they already know how rebase spells its arguments, or they would still find it natural if they did not know anything about rebase. The basic confusion comes from the natural desire to read a command as a sentence, and the lack of the rebase UI in that respect: git rebase foo does not rebase foo! git rebase foo bar does not rebase foo either! I think it's a UI design mistake that comes from making the common use-case as short as possible. In the invocations above, foo is neither the ref that is being rebased nor a rev notation for the affected commits. That would have been foo.. or ^foo. I seem to recall that we've talked about range notations for rebase. Maybe we can start accepting them, and once we start teaching git rebase ^foo or git rebase foo.. it will become clearer that that argument is not the ref being rebased, but a description of the commits being rebased. And then it would be natural to talk about onto foo for these cases, as well as leave the --onto argument named the way it is (since it defaults to foo, or rather the fork-point). Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] send-pack: unify error messages for unsupported capabilities
If --signed is not supported, the error message names the remote
receiving end. If --atomic is not supported, the error message
names the remote server. Unify the naming to receiving end
as we're in the context of push.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
send-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/send-pack.c b/send-pack.c
index 9d2b0c5..189bdde 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -356,21 +356,21 @@ int send_pack(struct send_pack_args *args,
die(_(the receiving end does not support --signed
push));
push_cert_nonce = xmemdupz(push_cert_nonce, len);
}
if (!remote_refs) {
fprintf(stderr, No refs in common and none specified; doing
nothing.\n
Perhaps you should specify a branch such as
'master'.\n);
return 0;
}
if (args-atomic !atomic_supported)
- die(_(server does not support --atomic push));
+ die(_(the receiving end does not support --atomic push));
use_atomic = atomic_supported args-atomic;
if (status_report)
strbuf_addstr(cap_buf, report-status);
if (use_sideband)
strbuf_addstr(cap_buf, side-band-64k);
if (quiet_supported (args-quiet || !args-progress))
strbuf_addstr(cap_buf, quiet);
if (use_atomic)
--
2.4.0.rc0.243.g0be2dd7
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] systemd socket activation support
On Thu, Apr 2, 2015 at 8:47 AM, Junio C Hamano gits...@pobox.com wrote: Eric Sunshine sunsh...@sunshineco.com writes: On Wed, Apr 1, 2015 at 9:23 PM, Shawn Landden sh...@churchofgit.com wrote: From: Shawn Landden shawnland...@gmail.com [PATCH] systemd socket activation support This patch feels like an RFC rather than a properly fleshed-out submission. If so, indicate such in the subject. Also, mention the area you're touching, followed by a colon, followed by the summary of the change: [PATCH/RFC] daemon: add systemd support ... Everything Eric said ;-) Another thing is that this must be a build-time conditional. Not all platforms can use systemd in the first place, and some people may choose not to use it even if the platform is capable of. I was somewhat surprised that sd-daemon.c needed to be built on our side, not used from systemd support library, as what it did looked very common and not specific to our needs. I would have expected to see inclusion of sd-daemon.h with -lsystemd-daemon or something on the command line. There is a libsystemd, but when we are using so little of it it seems cleaner to being it to us instead. I can do that in the next patch along with build conditional. -- Shawn Landden -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git 2.3.4, ssh: Could not resolve hostname
Dear Sirs After upgrading from GIT 2.3.3 to 2.3.4 (on Mac OS X 10.10.2, installed with MacPorts) I received this error message when doing a push: $ git push ssh: Could not resolve hostname :: nodename nor servname provided, or not known fatal: Could not read from remote repository. It was working previously and nothing in ~/.gitconfig nor .git/config was changed. I rolled back to 2.3.3 and it is working again. Reid Woodbury https://github.com/diskerror-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] init: don't set core.worktree when initializing /.git
On Tue, Mar 31, 2015 at 12:14:20PM -0700, Jonathan Nieder wrote:
No tests, as we would need to be able to write to / to do
so.
t1509-root-worktree.sh is supposed to test the repository-at-/ case.
But I wouldn't be surprised if it's bitrotted, since people don't set
up a throwaway chroot or VM for tests too often.
Thanks, I had thought we had such a test script, but for some reason had
trouble finding it earlier. I couldn't get it to run using the included
t1509/prepare-chroot.sh helper; the resulting chroot was missing several
tools we rely on in test-lib.sh (perl, expr, tr, and mv).
I gave up for now; I don't think rescuing that script is worth the
effort for this minor bug.
The current behavior isn't _wrong_, in the sense that it's OK to set
core.worktree when we don't need to. But I think it is unnecessarily
confusing to users who expect to be able to move .git directories
around, because it usually just works. So I'd call this an extremely
minor bug.
This belongs in the commit message.
It's mostly a restatement of what is already in the first paragraph of
the commit message. I folded it into that paragraph.
+static int needs_work_tree_config(const char *git_dir, const char
*work_tree)
+{
+ /* special case that is missed by the general rule below */
(optional) I'd leave out this comment --- it seems obvious enough in
context and the purpose of the comment is unobvious without looking
at the history.
OK, dropped. Here's the re-roll.
-- 8 --
Subject: [PATCH] init: don't set core.worktree when initializing /.git
If you create a git repository in the root directory with
git init /, we erroneously write a core.worktree entry.
This isn't _wrong_, in the sense that it's OK to set
core.worktree when we don't need to. But it is unnecessarily
surprising if you later move the .git directory to another
path (which usually moves the relative working tree, but is
foiled if there is an explicit worktree set).
The problem is that we check whether core.worktree is
necessary by seeing if we can make the git_dir by
concatenating /.git onto the working tree. That would lead
to //.git in this instance, but we actually have /.git
(without the doubled slash).
We can fix this by special-casing the root directory. I also
split the logic out into its own function to make the
conditional a bit more readable (and used skip_prefix, which
I think makes it a little more obvious what is going on).
No tests, as we would need to be able to write to / to do
so. I did manually confirm that:
sudo git init /
cd /
git rev-parse --show-toplevel
git config core.worktree
still finds the top-level correctly (as /), and does not
set any core.worktree variable.
Signed-off-by: Jeff King p...@peff.net
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
---
builtin/init-db.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 6723d39..ab9f86b 100644
--- a/builtin/init-db.c
+++ b/builtin/init-db.c
@@ -182,6 +182,20 @@ static int git_init_db_config(const char *k, const char
*v, void *cb)
return 0;
}
+/*
+ * If the git_dir is not directly inside the working tree, then git will not
+ * find it by default, and we need to set the worktree explicitly.
+ */
+static int needs_work_tree_config(const char *git_dir, const char *work_tree)
+{
+ if (!strcmp(work_tree, /) !strcmp(git_dir, /.git))
+ return 0;
+ if (skip_prefix(git_dir, work_tree, git_dir)
+ !strcmp(git_dir, /.git))
+ return 0;
+ return 1;
+}
+
static int create_default_files(const char *template_path)
{
const char *git_dir = get_git_dir();
@@ -274,10 +288,8 @@ static int create_default_files(const char *template_path)
/* allow template config file to override the default */
if (log_all_ref_updates == -1)
git_config_set(core.logallrefupdates, true);
- if (!starts_with(git_dir, work_tree) ||
- strcmp(git_dir + strlen(work_tree), /.git)) {
+ if (needs_work_tree_config(git_dir, work_tree))
git_config_set(core.worktree, work_tree);
- }
}
if (!reinit) {
--
2.4.0.rc0.363.gf9f328b
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] init: don't set core.worktree when initializing /.git
Jeff King wrote: OK, dropped. Here's the re-roll. Thanks. -- 8 -- Subject: [PATCH] init: don't set core.worktree when initializing /.git [...] No tests, as we would need to be able to write to / to do so. This is confusing in the light of t1509-root-worktree.sh existing, but anyone curious can dig up this mailing list thread so I don't mind. :) [...] Signed-off-by: Jeff King p...@peff.net Reviewed-by: Jonathan Nieder jrnie...@gmail.com Yep - still looks good. Regards, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git 2.3.4, ssh: Could not resolve hostname
On Thu, Apr 02, 2015 at 10:18:33AM -0700, Reid Woodbury Jr. wrote: After upgrading from GIT 2.3.3 to 2.3.4 (on Mac OS X 10.10.2, installed with MacPorts) I received this error message when doing a push: $ git push ssh: Could not resolve hostname :: nodename nor servname provided, or not known fatal: Could not read from remote repository. It is hard to tell from the obfuscated output, but perhaps the problem is the two colons (i.e., git is feeding a hostname like foo: when it should be just foo). There were some changes in v2.3.4 related to parsing ssh URLs. +cc Torsten, who worked on that code. Can you show us your git config (presumably the host is defined in remote.origin.url in .git/config of the repository)? -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] send-pack: unify error messages for unsupported capabilities
Ralf Thielow ralf.thie...@gmail.com writes:
If --signed is not supported, the error message names the remote
receiving end. If --atomic is not supported, the error message
names the remote server. Unify the naming to receiving end
as we're in the context of push.
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
Sounds very sensible. Let's do this before -rc1, so that i18n has
time to adjust.
send-pack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/send-pack.c b/send-pack.c
index 9d2b0c5..189bdde 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -356,21 +356,21 @@ int send_pack(struct send_pack_args *args,
die(_(the receiving end does not support --signed
push));
push_cert_nonce = xmemdupz(push_cert_nonce, len);
}
if (!remote_refs) {
fprintf(stderr, No refs in common and none specified; doing
nothing.\n
Perhaps you should specify a branch such as
'master'.\n);
return 0;
}
if (args-atomic !atomic_supported)
- die(_(server does not support --atomic push));
+ die(_(the receiving end does not support --atomic push));
use_atomic = atomic_supported args-atomic;
if (status_report)
strbuf_addstr(cap_buf, report-status);
if (use_sideband)
strbuf_addstr(cap_buf, side-band-64k);
if (quiet_supported (args-quiet || !args-progress))
strbuf_addstr(cap_buf, quiet);
if (use_atomic)
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/4] cat-file: add a '--literally' option
When merged to 'pu', this seems to break at least 5309 and 5300 tests (there might be others, but I didn't check). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
