Output from rev-parse --resolve-git-dir changed: two lines (prints original argument)
I have noticed that the output from git rev-parse --resolve-git-dir changed. While it used to only print the resolved git dir, it now prints the argument passed to it itself: % git rev-parse --resolve-git-dir .git /path/to/root/.git/modules/vim/bundle/reporoot .git This is with Git version 1.8.5.3, but also happens with master. You can use --flags to avoid this (git rev-parse --flags --resolve-git-dir .git), but it is unclear from the documentation if that's the intended beahviour. It seems like the --resolve-git-dir subcommand needs to consume the argument passed to it. Regards, Daniel. -- http://daniel.hahler.de/ signature.asc Description: OpenPGP digital signature
[PATCH] rev-parse: fix --resolve-git-dir argument handling
There are two problems here:
1) If no argument is provided, then the command segfaults
2) The argument is not consumed, so there will be excess output
Fix both of these in one go by restructuring the handler for this
option.
Reported-by: Daniel Hahler genml+git-2...@thequod.de
Signed-off-by: John Keeping j...@keeping.me.uk
---
builtin/rev-parse.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c
index aaeb611..645cc4a 100644
--- a/builtin/rev-parse.c
+++ b/builtin/rev-parse.c
@@ -738,9 +738,12 @@ int cmd_rev_parse(int argc, const char **argv, const char
*prefix)
continue;
}
if (!strcmp(arg, --resolve-git-dir)) {
- const char *gitdir = resolve_gitdir(argv[i+1]);
+ const char *gitdir;
+ if (++i = argc)
+ die(--resolve-git-dir requires an
argument);
+ gitdir = resolve_gitdir(argv[i]);
if (!gitdir)
- die(not a gitdir '%s', argv[i+1]);
+ die(not a gitdir '%s', argv[i]);
puts(gitdir);
continue;
}
--
1.9.0.6.g037df60.dirty
--
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: Bug: relative core.worktree is resolved from symlink and not its target
On 09.02.2014 10:08, Duy Nguyen wrote: On Tue, Feb 04, 2014 at 11:20:39AM +0100, Daniel Hahler wrote: Thanks for looking into this. when using a submodule sm, there is a relative worktree in its config: .git/modules/sm/config: [core] worktree = ../../../smworktree git-new-worktree (from contrib) symlinks this config the new worktree. From inside the new worktree, git reads the config, but resolves the relative worktree setting based on the symlink's location. Hmm.. core.worktree is relative to $GIT_DIR. Whether config is a symlink should have no effects. If config is a symlink, the relative path for worktree is meant to be resolved based on the config file's location, and not from the symlink ($GIT_DIR). Here is a test case to reproduce it: # Create a submodule repo mkdir /tmp/t-sm cd /tmp/t-sm git init touch foo git add foo git commit -m init # Create the root repo mkdir /tmp/t-root cd /tmp/t-root git init mkdir submodules git submodule add /tmp/t-sm submodules/sm git commit -m init # Create a new worktree from the submodule cd /tmp/t-root/submodules/sm git-new-workdir . /tmp/new-workdir This then fails when checking out: + git checkout -f fatal: Could not chdir to '../../../../submodules/sm': No such file or directory % ls -l /tmp/new-workdir/.git/config […] /tmp/new-workdir/.git/config - /tmp/t-root/.git/modules/submodules/sm/config % cat /tmp/new-workdir/.git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true worktree = ../../../../submodules/sm From inside of /tmp/new-workdir `git rev-parse --git-dir` fails already (with the same cannot chdir error). The problem appears to be that it tries to chdir based on /tmp/new-workdir/.git, but should do so based on $(readlink -f .git/config). I recognize that this case is constructed anyway, because even if `worktree` would get resolved correctly, it would not be what you'd expect: the point of git-new-workdir is to get a separate worktree, and not use the existing one. Therefore I see two problems here: 1. worktree is not resolved correctly by git itself (with .git/config being a symlink) 2. git-new-workdir should handle this better, e.g. by creating a copy of the config file with the worktree setting removed and printing a warning about it. The workaround appears to be to explicitly set GIT_WORK_TREE=/tmp/new-workdir. Regards, Daniel. -- http://daniel.hahler.de/ signature.asc Description: OpenPGP digital signature
Re: diff weirdness (bug?)
Dario Bertini berda...@gmail.com writes: On 02/14/2014 09:03 PM, Junio C Hamano wrote: This is a combined diff, and yaml-related lines are added relative to your _other_ branch you are merging (notice these + are indented by one place). Relative to what you had at the tip of your branch before you started this operation that ended up conflicted, the half-merged result removes if/else that sets DIST_MODULE_PATH and replaces it with a single line (their +/- are on the first column, signifying that these are differences relative to the first parent, i.e. your state before you started the operation). if we remove these 3 lines, we'll get this diff: With that understanding, I think the output after removing these three lines is perfectlyh understandable and correct. You are looking at the three lines that used to exist in the version you started from, that were missing from the other side. If you remoe them, it will show as removal from _your_ version (notice these - that shows what _you_ did manually are on the first column, saying that that is relative to _your_ version). Thank you, I was completely unaware of combined diffs. Still: I can't see how this would explain the empty diff when deleting 4 lines instead of 3. With a --cc diff (which it is: it says 'diff --cc' in the file headers) git doesn't show the combined diff for hunks that fully agree with one side. So if you (even manually) resolve the merge so that it fully matches one side, that will not show up in a --cc diff. -- Thomas Rast t...@thomasrast.ch -- 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: Is there something like a blamed diff?
David Kastrup d...@gnu.org writes: When comparing two branches, decorating the flat diff with the respectively responsible commits seems like it would be nice to do/have (the blame on the identical parts, in contrast, is not really interesting). Is there any tool that provides something like that? This seems to come up every year or so: http://thread.gmane.org/gmane.comp.version-control.git/110369/focus=110383 -- Thomas Rast t...@thomasrast.ch -- 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: Is there something like a blamed diff?
Thomas Rast t...@thomasrast.ch writes: David Kastrup d...@gnu.org writes: When comparing two branches, decorating the flat diff with the respectively responsible commits seems like it would be nice to do/have (the blame on the identical parts, in contrast, is not really interesting). Is there any tool that provides something like that? This seems to come up every year or so: http://thread.gmane.org/gmane.comp.version-control.git/110369/focus=110383 Nice. That one could likely be sped up by calling git-blame just once on each file with multiple -L options. Though actually with the current implementation of git-blame you are likely faster for a large number of differences by doing each region separately anyway since then the cost for digging through the history is obviously O(n) for n consecutive runs on n chunks while the administrative overhead for several chunks in a single run is O(n^2) at the moment. -- David Kastrup -- 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 svn clone not work. It's stop with no error message.
Posting to msysgit since this was on Windows. -- Cheers, Ray Chuan On Mon, Feb 17, 2014 at 3:45 PM, youngseonkim 1.youngsun@gmail.com wrote: Hi, I really wonder about this happen. I want svn→git migrate, and I use this command. git svn clone https://my.svn.repo/url --stdlayout When I test a small svn repository and 'real working repository 1' with same this command, it's complete successfully. But it's not work in a 'real working repository 2', it just stop suddenly. CMD console not shown any error message, last message are like this. r1 = 67f4093b82b7b764171b01f1566eca57f6c29ac2 I don't know about why this process stop.. 'real repository 2' configured same with 'real repository 1'. 'Real working repository 2' are very large but I don't know accurate size.. I working on Windows server 2008, 16GB RAM memory, 16 cores cpu, upper then 100GB hard disk space. I'm sorry. I'm not speak English well. But I really want someone help me.. Anybody have some idea about this happen? -- View this message in context: http://git.661346.n2.nabble.com/git-svn-clone-not-work-It-s-stop-with-no-error-message-tp7603785.html Sent from the git mailing list archive at Nabble.com. -- 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 -- 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 2/3] wt-status.c: move cut-line print code out to wt_status_add_cut_line
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
wt-status.c | 19 ---
wt-status.h | 1 +
2 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 65e35c3..ed31b6a 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -808,6 +808,17 @@ void wt_status_truncate_message_at_cut_line(struct strbuf
*buf)
strbuf_release(pattern);
}
+void wt_status_add_cut_line(FILE *fp)
+{
+ const char *explanation = _(Do not touch the line above.\nEverything
below will be removed.);
+ struct strbuf buf = STRBUF_INIT;
+
+ fprintf(fp, %c %s, comment_line_char, cut_line);
+ strbuf_add_commented_lines(buf, explanation, strlen(explanation));
+ fputs(buf.buf, fp);
+ strbuf_release(buf);
+}
+
static void wt_status_print_verbose(struct wt_status *s)
{
struct rev_info rev;
@@ -833,14 +844,8 @@ static void wt_status_print_verbose(struct wt_status *s)
* diff before committing.
*/
if (s-fp != stdout) {
- const char *explanation = _(Do not touch the line
above.\nEverything below will be removed.);
- struct strbuf buf = STRBUF_INIT;
-
rev.diffopt.use_color = 0;
- fprintf(s-fp, %c %s, comment_line_char, cut_line);
- strbuf_add_commented_lines(buf, explanation,
strlen(explanation));
- fputs(buf.buf, s-fp);
- strbuf_release(buf);
+ wt_status_add_cut_line(s-fp);
}
run_diff_index(rev, 1);
}
diff --git a/wt-status.h b/wt-status.h
index 30a4812..b56ce3f 100644
--- a/wt-status.h
+++ b/wt-status.h
@@ -92,6 +92,7 @@ struct wt_status_state {
};
void wt_status_truncate_message_at_cut_line(struct strbuf *);
+void wt_status_add_cut_line(FILE *fp);
void wt_status_prepare(struct wt_status *s);
void wt_status_print(struct wt_status *s);
void wt_status_collect(struct wt_status *s);
--
1.8.5.2.240.g8478abd
--
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 1/3] wt-status.c: make cut_line[] const to shrink .data section a bit
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
wt-status.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index 4e55810..65e35c3 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -17,7 +17,7 @@
#include strbuf.h
#include utf8.h
-static char cut_line[] =
+static const char cut_line[] =
8 \n;
static char default_wt_status_colors[][COLOR_MAXLEN] = {
--
1.8.5.2.240.g8478abd
--
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 0/3] commit --cleanup=scissors marker
Slight changes in git-commit.txt and some commit messages after Brian and Eric's comments. Nguyễn Thái Ngọc Duy (3): wt-status.c: make cut_line[] const to shrink .data section a bit wt-status.c: move cut-line print code out to wt_status_add_cut_line commit: add --cleanup=scissors Documentation/git-commit.txt | 8 +++- builtin/commit.c | 9 +++-- t/t7502-commit.sh| 16 wt-status.c | 21 + wt-status.h | 1 + 5 files changed, 44 insertions(+), 11 deletions(-) -- 1.8.5.2.240.g8478abd -- 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 3/3] commit: add --cleanup=scissors
Since 1a72cfd (commit -v: strip diffs and submodule shortlogs from the
commit message - 2013-12-05) we have a less fragile way to cut out
git status at the end of a commit message but it's only enabled for
stripping submodule shortlogs. Add new cleanup option that reuses the
same mechanism for the entire git status without accidentally
removing lines starting with '#'
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/git-commit.txt | 8 +++-
builtin/commit.c | 9 +++--
t/t7502-commit.sh| 16
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 1a7616c..7948233 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -176,7 +176,7 @@ OPTIONS
--cleanup=mode::
This option determines how the supplied commit message should be
cleaned up before committing. The 'mode' can be `strip`,
- `whitespace`, `verbatim`, or `default`.
+ `whitespace`, `verbatim`, `scissors` or `default`.
+
--
strip::
@@ -186,6 +186,12 @@ whitespace::
Same as `strip` except #commentary is not removed.
verbatim::
Do not change the message at all.
+scissors::
+ Same as `whitespace`, except that everything from (and
+ including) the line
+ `# 8 `
+ is truncated if the message is to be edited. `#` can be
+ customized with core.commentChar.
default::
Same as `strip` if the message is to be edited.
Otherwise `whitespace`.
diff --git a/builtin/commit.c b/builtin/commit.c
index 3767478..ea2912f 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -113,6 +113,7 @@ static char *sign_commit;
static enum {
CLEANUP_SPACE,
CLEANUP_NONE,
+ CLEANUP_SCISSORS,
CLEANUP_ALL
} cleanup_mode;
static const char *cleanup_arg;
@@ -777,6 +778,8 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
_(Please enter the commit message for your
changes.
Lines starting\nwith '%c' will be ignored,
and an empty
message aborts the commit.\n),
comment_line_char);
+ else if (cleanup_mode == CLEANUP_SCISSORS)
+ wt_status_add_cut_line(s-fp);
else /* CLEANUP_SPACE, that is. */
status_printf(s, GIT_COLOR_NORMAL,
_(Please enter the commit message for your
changes.
@@ -1132,6 +1135,8 @@ static int parse_and_validate_options(int argc, const
char *argv[],
cleanup_mode = CLEANUP_SPACE;
else if (!strcmp(cleanup_arg, strip))
cleanup_mode = CLEANUP_ALL;
+ else if (!strcmp(cleanup_arg, scissors))
+ cleanup_mode = use_editor ? CLEANUP_SCISSORS : CLEANUP_SPACE;
else
die(_(Invalid cleanup mode %s), cleanup_arg);
@@ -1600,8 +1605,8 @@ int cmd_commit(int argc, const char **argv, const char
*prefix)
die(_(could not read commit message: %s),
strerror(saved_errno));
}
- /* Truncate the message just before the diff, if any. */
- if (verbose)
+ if (verbose || /* Truncate the message just before the diff, if any. */
+ cleanup_mode == CLEANUP_SCISSORS)
wt_status_truncate_message_at_cut_line(sb);
if (cleanup_mode != CLEANUP_NONE)
diff --git a/t/t7502-commit.sh b/t/t7502-commit.sh
index 6313da2..9a3f3a1 100755
--- a/t/t7502-commit.sh
+++ b/t/t7502-commit.sh
@@ -223,6 +223,22 @@ test_expect_success 'cleanup commit messages (whitespace
option,-F)' '
'
+test_expect_success 'cleanup commit messages (scissors option,-F,-e)' '
+
+ echo negative
+ cat text EOF
+
+# to be kept
+# 8
+to be removed
+EOF
+ echo # to be kept expect
+ git commit --cleanup=scissors -e -F text -a
+ git cat-file -p HEAD |sed -e 1,/^\$/dactual
+ test_cmp expect actual
+
+'
+
test_expect_success 'cleanup commit messages (strip option,-F)' '
echo negative
--
1.8.5.2.240.g8478abd
--
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: Bug: relative core.worktree is resolved from symlink and not its target
On Mon, Feb 17, 2014 at 4:36 PM, Daniel Hahler genml+git-2...@thequod.de wrote: On 09.02.2014 10:08, Duy Nguyen wrote: On Tue, Feb 04, 2014 at 11:20:39AM +0100, Daniel Hahler wrote: Thanks for looking into this. when using a submodule sm, there is a relative worktree in its config: .git/modules/sm/config: [core] worktree = ../../../smworktree git-new-worktree (from contrib) symlinks this config the new worktree. From inside the new worktree, git reads the config, but resolves the relative worktree setting based on the symlink's location. Hmm.. core.worktree is relative to $GIT_DIR. Whether config is a symlink should have no effects. If config is a symlink, the relative path for worktree is meant to be resolved based on the config file's location, and not from the symlink ($GIT_DIR). I think you started with a wrong assumption. See config.txt it says -- 8 -- core.worktree:: Set the path to the root of the working tree. This can be overridden by the GIT_WORK_TREE environment variable and the '--work-tree' command line option. The value can be an absolute path or relative to the path to the .git directory, which is either specified by --git-dir or GIT_DIR, or automatically discovered. -- 8 -- So I think it fails correctly (by the book). Here is a test case to reproduce it: # Create a submodule repo mkdir /tmp/t-sm cd /tmp/t-sm git init touch foo git add foo git commit -m init # Create the root repo mkdir /tmp/t-root cd /tmp/t-root git init mkdir submodules git submodule add /tmp/t-sm submodules/sm git commit -m init # Create a new worktree from the submodule cd /tmp/t-root/submodules/sm git-new-workdir . /tmp/new-workdir This then fails when checking out: + git checkout -f fatal: Could not chdir to '../../../../submodules/sm': No such file or directory % ls -l /tmp/new-workdir/.git/config […] /tmp/new-workdir/.git/config - /tmp/t-root/.git/modules/submodules/sm/config % cat /tmp/new-workdir/.git/config [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true worktree = ../../../../submodules/sm From inside of /tmp/new-workdir `git rev-parse --git-dir` fails already (with the same cannot chdir error). The problem appears to be that it tries to chdir based on /tmp/new-workdir/.git, but should do so based on $(readlink -f .git/config). I recognize that this case is constructed anyway, because even if `worktree` would get resolved correctly, it would not be what you'd expect: the point of git-new-workdir is to get a separate worktree, and not use the existing one. Therefore I see two problems here: 1. worktree is not resolved correctly by git itself (with .git/config being a symlink) 2. git-new-workdir should handle this better, e.g. by creating a copy of the config file with the worktree setting removed and printing a warning about it. The workaround appears to be to explicitly set GIT_WORK_TREE=/tmp/new-workdir. No if you copy config out then it may be not what you want anymore (e.g. new remotes not reflected in new worktree). A better solution is move core.worktree out of config. Notice t-root/submodules/sm is a file that contains the path to the true .git directory. We could have stored worktree path in that file instead of in config. -- Duy -- 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 v3 00/26] inotify support
On Mon, Feb 10, 2014 at 3:19 AM, Torsten Bögershausen tbo...@web.de wrote: On 2014-02-08 09.53, Duy Nguyen wrote: file-watcher.c | 32 1 file changed, 32 insertions(+) I feel a little bit unsure about the 700. Most often Git does not care about permissions, and relies on umask being set appropriatly. (Please correct me if I'm wrong) Git does care. See credential-cache--daemon.c. In fact this function is a copy of check_socket_directory() from that file. I was probably a little bit unclear. Of course credentials should be protected well and stored with 700. The rest of the repo could be more loose by using adjust_shared_perm(). Because the whole repo can be shared (or not) and data is visible to the group or everyone. (this is a minor issue) So how about a check whenever a worktree is connected to the daemon, if that worktree has stricter permission, e.g. 0700 vs 0770 of the daemon socket directory, then the daemon refuses the worktree (maybe with a warning)? -- Duy -- 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] gitweb: Avoid overflowing page body frame with large images
When displaying a blob in gitweb, if it's an image, specify constraints for
maximum display width and height to prevent the image from overflowing the
frame of the enclosing page_body div.
This change assumes that it is more desirable to see the whole image without
scrolling (new behavior) than it is to see every pixel without zooming
(previous behavior).
Signed-off-by: Andrew Keller and...@kellerfarm.com
---
This is an updated copy of this patch.
Could I request a thumbs up, thumbs down, or thumbs sideways from those who
develop gitweb?
Thanks,
Andrew Keller
gitweb/gitweb.perl |2 +-
gitweb/static/gitweb.css |5 +
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3bc0f0b..79057b7 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -7094,7 +7094,7 @@ sub git_blob {
git_print_page_path($file_name, blob, $hash_base);
print div class=\page_body\\n;
if ($mimetype =~ m!^image/!) {
- print qq!img type=!.esc_attr($mimetype).qq!!;
+ print qq!img class=blob type=!.esc_attr($mimetype).qq!!;
if ($file_name) {
print qq! alt=!.esc_attr($file_name).qq!
title=!.esc_attr($file_name).qq!!;
}
diff --git a/gitweb/static/gitweb.css b/gitweb/static/gitweb.css
index 3b4d833..3212601 100644
--- a/gitweb/static/gitweb.css
+++ b/gitweb/static/gitweb.css
@@ -32,6 +32,11 @@ img.avatar {
vertical-align: middle;
}
+img.blob {
+ max-height: 100%;
+ max-width: 100%;
+}
+
a.list img.avatar {
border-style: none;
}
--
1.7.9.6 (Apple Git-31.1)
--
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
Wrong version of Git on your download website for windows
Hello, many thanks for all your working. Git is a very good help tool. A smal bug is on your download website for windows. Here we can read: Latest stable release 1.9.0 Release Notes (2014-02-14) Download for Windows, but the link loads Git-1.8.5.2.preview20131230.exe -- Mit freundlichen Grüßen Torsten Thurow __ Dr. Ing. Torsten Thurow | computer scientist Technische Universität München | Faculty of Architecture Chair for Architectural Informatics | Prof. Dr.-Ing. Frank Petzold Arcisstr. 21 | 80333 Munich | Germany fon: +49 (0) 89 289 22-184 fax: +49 (0) 89 289 22-179 email: torsten.thu...@tum.de web: www.ai.ar.tum.de __ attachment: torsten_thurow.vcf
Re: [msysGit] Re: git svn clone not work. It's stop with no error message.
Hi Tay, On Mon, 17 Feb 2014, Tay Ray Chuan wrote: Posting to msysgit since this was on Windows. Thanks. On Mon, Feb 17, 2014 at 3:45 PM, youngseonkim 1.youngsun@gmail.com wrote: git svn clone https://my.svn.repo/url --stdlayout When I test a small svn repository and 'real working repository 1' with same this command, it's complete successfully. But it's not work in a 'real working repository 2', it just stop suddenly. The git-svn we have on Windows is really old. As an easy way out, you can use Vagrant (https://github.com/msysgit/msysgit/wiki/Vagrant) to run a Linux Git on your machine. That should fix your issue. Ciao, Johannes -- 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: Wrong version of Git on your download website for windows
On Mon, Feb 17, 2014 at 04:45:20PM +0100, Dr. Torsten Thurow wrote: Hello, many thanks for all your working. Git is a very good help tool. A smal bug is on your download website for windows. Here we can read: Latest stable release 1.9.0 Release Notes (2014-02-14) Download for Windows, but the link loads Git-1.8.5.2.preview20131230.exe Windows and Mac OS X binary builds are done by a different group and uploaded as they get the time, and as such, the version number is that of the source, not the binaries. Also, the git-scm.com website is maintained by other people, not the Git project itself. The fact that that website has confusing information for binary builds is tracked in that site's issue #268: https://github.com/git/git-scm.com/issues/268. -- 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: Wrong version of Git on your download website for windows
I looked into this and they seem to be deliberately holding off onto a release due to some max path issues on Windows: https://github.com/msysgit/git/pull/122 Also there are some unofficial builds for 1.8.5.4 I think, you just have to Google for it. On Mon, Feb 17, 2014 at 9:45 AM, Dr. Torsten Thurow torsten.thu...@tum.de wrote: Hello, many thanks for all your working. Git is a very good help tool. A smal bug is on your download website for windows. Here we can read: Latest stable release 1.9.0 Release Notes (2014-02-14) Download for Windows, but the link loads Git-1.8.5.2.preview20131230.exe -- Mit freundlichen Grüßen Torsten Thurow __ Dr. Ing. Torsten Thurow | computer scientist Technische Universität München | Faculty of Architecture Chair for Architectural Informatics | Prof. Dr.-Ing. Frank Petzold Arcisstr. 21 | 80333 Munich | Germany fon: +49 (0) 89 289 22-184 fax: +49 (0) 89 289 22-179 email: torsten.thu...@tum.de web: www.ai.ar.tum.de __ -- 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: Is there something like a blamed diff?
David Kastrup d...@gnu.org writes: Thomas Rast t...@thomasrast.ch writes: David Kastrup d...@gnu.org writes: When comparing two branches, decorating the flat diff with the respectively responsible commits seems like it would be nice to do/have (the blame on the identical parts, in contrast, is not really interesting). Is there any tool that provides something like that? This seems to come up every year or so: http://thread.gmane.org/gmane.comp.version-control.git/110369/focus=110383 Nice. That one could likely be sped up by calling git-blame just once on each file with multiple -L options. Yes. You'll note that the email predates the support for multiple -L options by a few years :-) I never had a need for such a script, I just wrote that in response to someone asking about it. If you find it useful, please clean it up for inclusion in contrib/. -- Thomas Rast t...@thomasrast.ch -- 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
Fwd: git-reviewed: linking commits to review discussion in git
Hello All, We have linked peer review discussions on git@vger.kernel.org to their respective commits within the main git.git repository. You can view the linked reviews from 2012 until present in the GitHub repo at: https://github.com/mmukadam/git/tree/review If you want to search for the reviews related to a commit, you can type in the full hash code here: http://users.encs.concordia.ca/~m_mukada/git-review-tracker.html or append the commit hash to the following url: https://github.com/mmukadam/git/tree/review/commit_hash Note, if you get a '404 page not found' from GitHub it means that we couldn't find a review to link the commit to. It's a bit hard to view the reviews on GitHub because the 'review' branch was designed to be viewed on the command line using a set of simple scripts that sit on top of the standard git commands. For example: to view all reviews Hamano is involved in you can do: git reviewed --log-reviewer hamano to view the reviews of particular commit: git reviewed --log 1a1832eb085e5bca198735e5d0e766a3cb61b8fc You can also create new reviews on a commit and mail them as well as import reviews from email. Note the command is git-reivewED because git-review is associated with Gerrit. The tool is beta, but it just creates a detached review branch, so it won't affect master. To remove it all you do is delete the scripts and the 'review' branch. More info available here: The online man-page is here: http://users.encs.concordia.ca/~m_mukada/git-review.html In order to install git-review, you need to clone the repository: https://github.com/mmukadam/git-reviewed.git The online tutorial is available here: http://users.encs.concordia.ca/~m_mukada/git-review-tutorial.html Sample output: Let's say you want to see the reviews related to commit: - git reviewed --log 9ce415d972a04df4bfceaad0fab8eaea9a66997e Review: 74d203accc341993dbed507fceceb2841670ce37 Commit Reviewed: 9ce415d972a04df4bfceaad0fab8eaea9a66997e Author: Johannes Sixt j...@kdbg.org AuthorDate: Fri Jun 7 22:53:27 2013 +0200 Reviewer: Junio C Hamano gits...@pobox.com gits...@pobox.com ReviewDate: Thu Feb 13 11:35:13 2014 -0800 Re: [PATCH] tests: turn on network daemon tests by default Review: e80ebaa1fdd132a13bfbc6f87cdd4ecec7f2b715 Commit Reviewed: 9ce415d972a04df4bfceaad0fab8eaea9a66997e Author: Johannes Sixt j...@kdbg.org AuthorDate: Fri Jun 7 22:53:27 2013 +0200 Reviewer: Junio C Hamano gits...@pobox.com gits...@pobox.com ReviewDate: Wed Feb 12 14:34:52 2014 -0800 Re: [PATCH] tests: turn on network daemon tests by default Review: 8da03766afcd60e432ffdd2d6f549e2ed02a4bc9 Commit Reviewed: 9ce415d972a04df4bfceaad0fab8eaea9a66997e Author: Johannes Sixt j...@kdbg.org AuthorDate: Fri Jun 7 22:53:27 2013 +0200 Reviewer: Jeff King p...@peff.net p...@peff.net ReviewDate: Mon Feb 10 16:29:37 2014 -0500 [PATCH] tests: turn on network daemon tests by default To show the email review discussion for a single review: - git reviewed --view 74d203accc341993dbed507fceceb2841670ce37 Commit Reviewed: 9ce415d972a04df4bfceaad0fab8eaea9a66997e Reviewer: Junio C Hamano gits...@pobox.com Reviewer Date: Thu, 13 Feb 2014 11:35:13 -0800 --- From : Junio C Hamano gits...@pobox.com Message-Id : xmqqfvnmlsb2@gitster.dls.corp.google.com Date : Thu, 13 Feb 2014 11:35:13 -0800 Subject: Re: [PATCH] tests: turn on network daemon tests by default References: 20140210191521.ga3...@sigill.intra.peff.net 20140210212931.ga16...@sigill.intra.peff.net xmqqa9dxpgw9@gitster.dls.corp.google.com 20140211200445.ga27...@sigill.intra.peff.net xmqqzjlxnqvw@gitster.dls.corp.google.com 20140212214753.ga6...@sigill.intra.peff.net xmqq38jom037@gitster.dls.corp.google.com In-Reply-To: xmqq38jom037@gitster.dls.corp.google.com (Junio C. Hamano's message of Wed, 12 Feb 2014 14:34:52 -0800) Cc: Duy Nguyen pclo...@gmail.com, Git Mailing List git@vger.kernel.org, Shawn O. Pearce spea...@spearce.org commit: 9ce415d972a04df4bfceaad0fab8eaea9a66997e Junio C Hamano gits...@pobox.com writes: Jeff King p...@peff.net writes: test_normalize_tristate GIT_TEST_DAEMON Heh, great minds think alike. This is what I am playing with, without committing (because I do like your ask config if this is a kind of various boolean 'false' representations, which I haven't managed to add to it). [snip] --- t/lib-git-daemon.sh | 8 --- t/lib-httpd.sh | 22 +-- t/test-lib-functions.sh | 58 + 3 files changed, 74 insertions(+), 14 deletions(-) diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh index 394b06b..615bf5d 100644 --- a/t/lib-git-daemon.sh +++ b/t/lib-git-daemon.sh @@ -16,9 +16,10 @@ # stop_git_daemon #
Re: error: src refspec refs/heads/master matches more than one.
Duy Nguyen pclouds at gmail.com writes: Prevent is a strong word. I meant we only do it if they force it. Something like this.. I would propose to make this even stronger: Forbid to create any branches which start with any of: - refs/ - heads/ - remotes/ - tags/ as long as you do not use the force option. The idea here is that you also will not get ambiguities later when you pull new branches into your repository. so long Ingo -- 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
difftool sends malformed path to exernal tool on Windows
From the Git Bash command line, I enter $ git difftool and type y when the file I want to difference appears. Git correctly calls the external diff tool (LVCompare.exe), but the path for the remote file Git passes to that tool is malformed (e.g., C:\/Users/Paul/AppData/Local/Temp/QCpqLa_calcLoadCellExcitation.vi). Obviously the \/ (backslash forwardslash) combination is incorrect. For the record, I have successfully made calls to LVCompare.exe manually from a Windows command prompt directly (without Git). The relevant portion of the .gitconfig file is: [diff] tool = LVCompare [difftool LVCompare] cmd = 'C:/Program Files (x86)/National Instruments/Shared/LabVIEW Compare/LVCompare.exe' \$LOCAL\ \$REMOTE\ For the record, the operating system is Windows 8.1. Paul -- 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: [BUG?] git http connection reuse
On Sun, Feb 16, 2014 at 02:33:06PM +0100, Daniel Stenberg wrote: On Sun, 16 Feb 2014, Daniel Stenberg wrote: Right, the problem is there to make sure that a NTLM-auth connection with different credentials aren't re-used. NTLM with its connection-oriented authentication breaks the traditional HTTP paradigms and before this change there was a risk that libcurl would wrongly re-use a NTLM connection that was done with different credentials! I suspect we introduced a regression here with that fix. I'll dig into this. Thanks for pointing this out! I could repeat this problem with a curl test case so I wrote up two, and then I made a fix to curl: https://github.com/bagder/curl/commit/d765099813f5 Thanks for the quick turnaround. I've confirmed that your patch fixes both my limited test case and Git itself (when using just the curl_easy interface). -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
[msysGit] Git for Windows 1.9.0 (fwd)
Hopefully the Postfix Greylisting Policy Server will not try again to greylist me, as it might however do without violating the RFC. -- Forwarded message -- Date: Tue, 18 Feb 2014 00:38:54 +0100 (CET) From: Johannes Schindelin johannes.schinde...@gmx.de To: msys...@googlegroups.com Cc: git@vger.kernel.org Subject: [msysGit] Git for Windows 1.9.0 Dear Git fanbois, this announcement informs you that the small team of volunteers who keep the Git ship afloat for the most prevalent desktop operating system managed to release yet another version of Git for Windows: Git Release Notes (Git-1.9.0-preview20140217) Last update: 17 February 2013 Changes since Git-1.8.5.2-preview20131230 New Features - Comes with Git 1.9.0 plus Windows-specific patches. - Better work-arounds for Windows-specific path length limitations (pull request #122) - Uses optimized TortoiseGitPLink when detected (msysGit pull request #154) - Allow Windows users to use Linux Git on their files, using Vagrant http://www.vagrantup.com/ (msysGit pull request #159) - InnoSetup 5.5.4 is now used to generate the installer (msysGit pull request #167) Bugfixes - Fixed regression with interactive password prompt for remotes using the HTTPS protocol (issue #111) - We now work around Subversion servers printing non-ISO-8601-compliant time stamps (pull request #126) - The installer no longer sets the HOME environment variable (msysGit pull request #166) - Perl no longer creates empty sys$command files when no stdin is connected (msysGit pull request #152) Ciao, Johannes -- -- *** Please reply-to-all at all times *** *** (do not pretend to know who is subscribed and who is not) *** *** Please avoid top-posting. *** The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free. You received this message because you are subscribed to the Google Groups msysGit group. To post to this group, send email to msys...@googlegroups.com To unsubscribe from this group, send email to msysgit+unsubscr...@googlegroups.com For more options, and view previous threads, visit this group at http://groups.google.com/group/msysgit?hl=en_US?hl=en --- You received this message because you are subscribed to the Google Groups msysGit group. To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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: [BUG?] git http connection reuse
On Sun, Feb 16, 2014 at 01:18:52PM +0100, Daniel Stenberg wrote:
On Sat, 15 Feb 2014, Kyle J. McKay wrote:
If pipelining is off (the default) and total connections is not 1
it sounds to me from the description above that the requests will
be executed on separate connections until the maximum number of
connections is in use and then there might be some reuse.
Not exactly. When about to do a request, libcurl will always try to
find an existing idle but open connection in its connection pool to
re-use. With the multi interface you can of course easily start N
requests at once to the same host and then they'll only re-use
connections to the extent there are connections to pick, otherwise
it'll create new connections.
Right; I'd expect multiple connections for parallel requests, but in
this case we are completing the first and removing the handle before
starting the second. Digging further, I was able to reproduce the
behavior with a simple program:
-- 8 --
#include stdio.h
#include stdlib.h
#include curl/curl.h
int main(int argc, char **argv)
{
CURL *curl = curl_easy_init();
CURLM *multi = curl_multi_init();
int want_multi = atoi(argv[2]);
int i;
curl_easy_setopt(curl, CURLOPT_URL, argv[1]);
curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L);
for (i = 0; i 2; i++) {
if (i want_multi) {
int nr;
curl_multi_add_handle(multi, curl);
do {
curl_multi_perform(multi, nr);
} while (nr);
curl_multi_remove_handle(multi, curl);
}
else
curl_easy_perform(curl);
}
return 0;
}
-- 8 --
The program just requests the same URL twice using the same curl handle,
optionally using the multi interface for zero, one, or both of the
requests. For 0 and 2 (i.e., either both curl_easy or both
curl_multi), the connection is reused. But for 1 (in which we use
multi for the first request, but easy for the second), we do not reuse
the connection.
The manpage for curl_multi_add_handle does say:
When an easy handle has been added to a multi stack, you can not
and you must not use curl_easy_perform(3) on that handle!
Does that apply to the handle after it has finished its transaction and
been removed from the multi object (in which case git is Doing It
Wrong)? Is the program above failing to take some step to finalize the
first request, so that the second one knows its connection can be
reused? Or should curl be handling this?
-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: [msysGit] Git for Windows 1.9.0 (fwd)
On Tue, Feb 18, 2014 at 12:52:28AM +0100, Johannes Schindelin wrote: Hopefully the Postfix Greylisting Policy Server will not try again to greylist me, as it might however do without violating the RFC. -- Forwarded message -- Date: Tue, 18 Feb 2014 00:38:54 +0100 (CET) From: Johannes Schindelin johannes.schinde...@gmx.de To: msys...@googlegroups.com Cc: git@vger.kernel.org Subject: [msysGit] Git for Windows 1.9.0 Dear Git fanbois, this announcement informs you that the small team of volunteers who keep the Git ship afloat for the most prevalent desktop operating system managed to release yet another version of Git for Windows: Git Release Notes (Git-1.9.0-preview20140217) Last update: 17 February 2013 Changes since Git-1.8.5.2-preview20131230 New Features - Comes with Git 1.9.0 plus Windows-specific patches. - Better work-arounds for Windows-specific path length limitations (pull request #122) - Uses optimized TortoiseGitPLink when detected (msysGit pull request #154) - Allow Windows users to use Linux Git on their files, using Vagrant http://www.vagrantup.com/ (msysGit pull request #159) I was curious about this, so i went to github and... couldn't find any pull request above #126. Mike -- 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: Fwd: git-reviewed: linking commits to review discussion in git
On Mon, Feb 17, 2014 at 03:12:48PM -0500, Murtuza Mukadam wrote: We have linked peer review discussions on git@vger.kernel.org to their respective commits within the main git.git repository. You can view the linked reviews from 2012 until present in the GitHub repo at: https://github.com/mmukadam/git/tree/review Neat. We've experimented in the past with mapping commits back to mailing list discussions. Thomas (cc'd) has a script that creates git-notes trees mapping commits to the relevant message-id, which can then be found in the list archive. To me, the interesting bits of such a project are: 1. How do we decide which messages led to which commits? There is definitely some room for heuristics here, as patches are sometimes tweaked in transit, or come in multiple stages (e.g., the original patch, then somebody suggests a fixup on top). You might want to compare your work with the script from Thomas here: http://repo.or.cz/w/trackgit.git 2. How do we store the mapping? I think git-notes are a natural fit here, but you don't seem to use them. Is there a reason? 3. How do we present the emails to the user (including showing threads, letting them dig deeper, etc)? The existing solution has no support at all for 3. Personally, I keep my own git-list archive locally, so I can search it (by message-id or other features), dump the result into an mbox (optionally including the surrounding thread), and then view the result in mutt. Having had this solution for a while, my experience has been that I don't use it that often. It's not that I don't refer to the archive to see more backstory on a commit; I probably do that once a week or so. But since I have a decent searchable archive, I tend to just do it by hand, searching for keywords from the commit message, and limiting by date if necessary. Going straight to the message by id might be a little faster, but I often pick up stray bits in my search that were not part of the original thread. E.g., somebody reports a bug, then 3 days later, somebody else posts a patch (but does not do it as a reply to the bug). There's nothing in the message headers or the commit mapping to say that those two messages are related. But because a search of the relevant terms finds both, and because the result is date-sorted, they end up near each other and it's easy for me to peruse. It would be interesting to apply some kind of clustering algorithm that automatically determines the messages related to a commit, including both the patch but also any discussion leading up to it. I realize that may be getting far afield of your original goals, but hey, you said you wanted feedback. I can reach for the stars. :) -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] revert.c: Allow to specify -x via git-config
Without this when maintaining stable branches it's easy to forget to use
-x to track where a patch was cherry-picked from.
Signed-off-by: Guido Günther a...@sigxcpu.org
---
Documentation/git-cherry-pick.txt | 8
builtin/revert.c | 10 ++
2 files changed, 18 insertions(+)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index c205d23..c35064f 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -215,6 +215,14 @@ the working tree.
spending extra time to avoid mistakes based on incorrectly matching
context lines.
+CONFIGURATION
+-
+
+See linkgit:git-config[1] for core variables.
+
+cherrypick.record-origin::
+ Default for the `-x` option. Defaults to `false`.
+
SEE ALSO
linkgit:git-revert[1]
diff --git a/builtin/revert.c b/builtin/revert.c
index 87659c9..df9718f 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -196,6 +196,15 @@ int cmd_revert(int argc, const char **argv, const char
*prefix)
return res;
}
+static int git_cherry_pick_config(const char *var, const char *value, void *cb)
+{
+ struct replay_opts *opts = cb;
+
+ if (!strcmp(var, cherrypick.record-origin))
+ opts-record_origin = git_config_bool (var, value);
+ return 0;
+}
+
int cmd_cherry_pick(int argc, const char **argv, const char *prefix)
{
struct replay_opts opts;
@@ -204,6 +213,7 @@ int cmd_cherry_pick(int argc, const char **argv, const char
*prefix)
memset(opts, 0, sizeof(opts));
opts.action = REPLAY_PICK;
git_config(git_default_config, NULL);
+ git_config(git_cherry_pick_config, opts);
parse_args(argc, argv, opts);
res = sequencer_pick_revisions(opts);
if (res 0)
--
1.9.0.rc3
--
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: [BUG?] git http connection reuse
On Mon, 17 Feb 2014, Jeff King wrote: Right; I'd expect multiple connections for parallel requests, but in this case we are completing the first and removing the handle before starting the second. Digging further, I was able to reproduce the behavior with a simple program: Yeah, given your description I had no problems to repeat it either. Turns out we had no decent test case that checked for this so in our eagerness to fix a security problem involving over-reuse we broke this simpler reuse case. Two steps forward, one step backward... :-/ The manpage for curl_multi_add_handle does say: When an easy handle has been added to a multi stack, you can not and you must not use curl_easy_perform(3) on that handle! Does that apply to the handle after it has finished its transaction and been removed from the multi object (in which case git is Doing It Wrong)? No it doesn't. The man page should probably be clarified to express that slightly better. It just means that _while_ a handle is added to a multi handle it cannot be used with curl_easy_perform(). So yes, you can remove indeed it from the handle and then do curl_easy_perform(). It works just fine! Several internal caches are kept in the multi handle when that's used though, so when getting the easy handle out after having used it with the multi interface and then using it with the easy interface may cause libcurl to do a little more work than if you would be able to re-add it to the same multi handle do to the operation with that... -- / daniel.haxx.se -- 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 gc --aggressive led to about 40 times slower git log --raw
Hi I've got a repository where git log --raw _somefile took a few seconds in the past, but after an attempt at merging some commits that were collected in a clone of the same repo that was created about a year ago, I noticed that this command was now taking 3 minutes 7 seconds. git gc, git fsck, git clone file:///the/repo/.git also now each took between ~4-10 minutes, also git log --raw somefile got equally unusably slow. With the help of the people on the IRC, I tracked it down to my recent use of git gc --aggressive in this repo. Running git repack -a -d -f solved it, now it's again taking 4-5 seconds. After running git gc --aggressive again for confirmation, git log --raw _somefile was again slowed down, although now 'only' to 1 minute 34 seconds; did perhaps my git remote add -f other-repo, which I remember was also running rather slowly, exacerbate the problem (to the 3 minutes I was seeing)? The repo has about 6000 commits, about 12'000 files in the current HEAD, and about 43 MB packed .git contents. The files are (almost) all plain text, about half of them are about 42 bytes long, the rest up to about 2 MB although most of them are just around 5-50 KB. Most files mostly grow at the end. The biggest files (500KB-2MB) are quite long-lived and don't stop growing, again mostly at the end. Also, about 2*5K files are each in the same directory, meaning that the tree objects representing those 2 directories are big but changing only in a few places. I've now learned to avoid git gc --aggressive. Perhaps there are some other conclusions to be drawn, I don't know. Christian. -- 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/5] notes-utils: handle boolean notes.rewritemode correctly
On Sun, Feb 16, 2014 at 05:22:45PM +0100, David Kastrup wrote: Not really relevant to this patch, but looking at the output of git grep config_error_nonbool seems like a serious amount of ridiculousness going on. The header shows cache.h:extern int config_error_nonbool(const char *); cache.h:#define config_error_nonbool(s) (config_error_nonbool(s), -1) and the implementation config.c:#undef config_error_nonbool config.c:int config_error_nonbool(const char *var) You could always look in the commit history: $ git log -S'#define config_error_nonbool' cache.h or search the mailing list: http://thread.gmane.org/gmane.comp.version-control.git/211505 Presumably this was done so that the uses of config_error_nonbool can be recognized as returning -1 unconditionally. Yes, it helps prevent false positives in gcc's flow analysis (specifically, -Wuninitialized warnings). But is that worth the obfuscation? Yes? Why not let config_error_nonbool return -1 in the first place? It originally did, but callers do not get to see the static return, so they miss some analysis opportunities. It does not appear like any caller would call the function rather than the macro, so why declare the function as returning an int at all? Because we don't use these macros on non-gnu compilers; they actually see the real function return. And why give it the same name as the macro (risking human/computer confusion and requiring an explicit #undef for the definition or was that declaration?) instead of config_error_nonbool_internal or whatever else? This particular case is simple, but see error() for another use of the same technique which requires variadic macros, which are not available everywhere. Callers want to say just error(...), so we have to name the macro that. If we call the matching function error_internal, then non-gnu compilers would need a macro to convert error(...) to error_internal(...). But they can't do so, because it would be a variadic macro. So you could adjust config_error_nonbool(), but not error(). But that introduces its own confusion, because the technique is not applied consistently. I agree the #define is ugly. But it's confined to a small area, and it does solve an actual problem. -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: [BUG?] git http connection reuse
On Tue, Feb 18, 2014 at 08:13:16AM +0100, Daniel Stenberg wrote: Right; I'd expect multiple connections for parallel requests, but in this case we are completing the first and removing the handle before starting the second. Digging further, I was able to reproduce the behavior with a simple program: Yeah, given your description I had no problems to repeat it either. Turns out we had no decent test case that checked for this so in our eagerness to fix a security problem involving over-reuse we broke this simpler reuse case. Two steps forward, one step backward... :-/ You are talking about the NTLM fix here, right? I think there is still an unrelated issue with curl_multi preventing connection reuse, but I'm not sure from what you say below... Does that apply to the handle after it has finished its transaction and been removed from the multi object (in which case git is Doing It Wrong)? No it doesn't. The man page should probably be clarified to express that slightly better. It just means that _while_ a handle is added to a multi handle it cannot be used with curl_easy_perform(). Thanks for the clarification. That was my guess from reading it, but given that it wasn't working as expected, I wondered if we were violating the rules. I saw the documentation fix you just pushed; it looks reasonable to me. Several internal caches are kept in the multi handle when that's used though, so when getting the easy handle out after having used it with the multi interface and then using it with the easy interface may cause libcurl to do a little more work than if you would be able to re-add it to the same multi handle do to the operation with that... I'm not clear whether you mean by this that it is _expected_ in my test program for curl not to reuse the connection. Or that curl may simply have to do a little more work, and it is still a bug that the connection is not reused. We can certainly teach git to use the multi interface, even when doing a single blocking request. -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
