Re: [PATCH v3 00/26] inotify support
On Mon, Feb 10, 2014 at 3:19 AM, Torsten Bögershausen tbo...@web.de wrote:
Please see filewatcher.c:
+ if (daemon) {
+ int err;
+ strbuf_addf(sb, %s/log, socket_path);
+ err = open(sb.buf, O_CREAT | O_TRUNC | O_WRONLY, 0600);
+ adjust_shared_perm(sb.buf);
(And now we talk about the logfile:
In daemon mode, stdout and stderr are saved in $WATCHER/log.
It could be nice to make this feature configrable,
either XXX/log or /dev/null.
On the long run we may eat to much disc space on a machine.
The other thing is that we may want to seperate stdout
from stderr, but even this is a low prio comment.
I probably should follow git-daemon and put these to syslog.
There is a small issue when I tested on a machine,
where the data directory called daten is softlinked to another disk:
daten - /disk3/home2/tb/daten
and the projects directory is softlinked to daten/projects
projects - daten/projects/
t7514 fails like this:
--- expect 2014-02-08 14:37:07.0 +
+++ actual 2014-02-08 14:37:07.0 +
@@ -1,6 +1,6 @@
packet: git hello
packet: git hello
-packet: git index 6cb9741eee29ca02c5b79e9c0bc647bcf47ce948
/home/tb/projects/git/tb/t/trash directory.t7514-file-watcher-lib
+packet: git index 6cb9741eee29ca02c5b79e9c0bc647bcf47ce948
/disk3/home2/tb/daten/projects/git/tb/t/trash directory.t7514-file-watcher-lib
Could we use relative path names internally, relative to $GIT_DIR ?
No because this is when the client tell the server about $GIT_DIR. I
guess we can use realpath(1) here.
---
Another thing:
Compiling under Mingw gives this:
LINK git-credential-store.exe
libgit.a(file-watcher-lib.o): In function `connect_watcher':
c:\Dokumente und Einstellungen\tb\projects\git\tb/file-watcher-lib.c:21:
undefined reference to `unix_stream_connect'
collect2: ld returned 1 exit status
make: *** [git-credential-store.exe] Error 1
We may need a compiler option like HAS_UNIX_SOCKETS or so.
I'll make unix-socket.o build unconditionally and return error at runtime.
--
+++ b/file-watcher.c
+#define INOTIFY_MASKS (IN_DELETE_SELF | IN_MOVE_SELF | \
+ IN_CREATE | IN_ATTRIB | IN_DELETE | IN_MODIFY | \
+ IN_MOVED_FROM | IN_MOVED_TO)
This feels confusing:
a) we have inotify_masks with lower case below.
b) how about INOTIFY_NEEDED_BITS ?
---
OK
I'm OK with having the protocol having specified in the
test cases.
One thing that I have on the wish list is to make the
commands/responses more unique, to be able to run grep
on the code base.
One idea could be to use a prefix
fwr for file watcher request or
fwr for file watcher response.
This does not work, hihi, so
fwq for file watcher reQuest and
fwe for file watcher rEsponse.
Or
ffw as from file watcher and
tfw as to file watcher for the people who have problems
with left and right, and could work.
If you want I can update test-file-watcher to accept send and
recv instead of and , respectively. The only command with
the same name for response and request is hello. I can make it
hello and helloack (or bonjour as response?).
--
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 v2 2/2] gc: config option for running --auto in background
On Sat, Feb 8, 2014 at 8:08 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
`gc --auto` takes time and can block the user temporarily (but not any
less annoyingly). Make it run in background on systems that support
it. The only thing lost with running in background is printouts. But
gc output is not really interesting. You can keep it in foreground by
changing gc.autodetach.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/config.txt | 4
builtin/gc.c | 23 ++-
t/t5400-send-pack.sh | 1 +
3 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5f4d793..4781773 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1167,6 +1167,10 @@ gc.autopacklimit::
--auto` consolidates them into one larger pack. The
default value is 50. Setting this to 0 disables it.
+gc.autodetach::
+ Make `git gc --auto` return immediately andrun in background
+ if the system supports it. Default is true.
+
gc.packrefs::
Running `git pack-refs` in a repository renders it
unclonable by Git versions prior to 1.5.1.2 over dumb
diff --git a/builtin/gc.c b/builtin/gc.c
index c19545d..ed5cc3c 100644
--- a/builtin/gc.c
+++ b/builtin/gc.c
@@ -29,6 +29,7 @@ static int pack_refs = 1;
static int aggressive_window = 250;
static int gc_auto_threshold = 6700;
static int gc_auto_pack_limit = 50;
+static int detach_auto = 1;
static const char *prune_expire = 2.weeks.ago;
static struct argv_array pack_refs_cmd = ARGV_ARRAY_INIT;
@@ -73,6 +74,10 @@ static int gc_config(const char *var, const char *value,
void *cb)
gc_auto_pack_limit = git_config_int(var, value);
return 0;
}
+ if (!strcmp(var, gc.autodetach)) {
+ detach_auto = git_config_bool(var, value);
+ return 0;
+ }
if (!strcmp(var, gc.pruneexpire)) {
if (value strcmp(value, now)) {
unsigned long now = approxidate(now);
@@ -301,11 +306,19 @@ int cmd_gc(int argc, const char **argv, const char
*prefix)
*/
if (!need_to_gc())
return 0;
- if (!quiet)
- fprintf(stderr,
- _(Auto packing the repository for
optimum performance. You may also\n
- run \git gc\ manually. See
- \git help gc\ for more
information.\n));
+ if (!quiet) {
+ if (detach_auto)
+ fprintf(stderr, _(Auto packing the
repository in background for optimum performance.\n));
+ else
+ fprintf(stderr, _(Auto packing the
repository for optimum performance.\n));
+ fprintf(stderr, _(See \git help gc\ for manual
housekeeping.\n));
+ }
+ if (detach_auto)
+ /*
+* failure to daemonize is ok, we'll continue
+* in foreground
+*/
+ daemonize();
While I agree that it should be OK, shouldn't we warn the user?
--
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 1/2] daemon: move daemonize() to libgit.a
On Sat, Feb 8, 2014 at 8:08 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
diff --git a/setup.c b/setup.c
index 6c3f85f..b09a412 100644
--- a/setup.c
+++ b/setup.c
@@ -787,3 +787,27 @@ void sanitize_stdfds(void)
if (fd 2)
close(fd);
}
+
+int daemonize(void)
+{
+#ifdef NO_POSIX_GOODIES
+ errno = -ENOSYS;
+ return -1;
+#else
+ switch (fork()) {
+ case 0:
+ break;
+ case -1:
+ die_errno(fork failed);
+ default:
+ exit(0);
+ }
+ if (setsid() == -1)
+ die_errno(setsid failed);
+ close(0);
+ close(1);
+ close(2);
+ sanitize_stdfds();
+ return 0;
+#endif
+}
Nice change.
Just a nit: When I added the NO_POSIX_GOODIES-flag, Junio wanted the
implementations to be separate.
--
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
[BUG] git-stash confused when directory replaced with symlink
Hello! Looks like a bug. `git stash` fails with fatal error, when whole subdirectory is replaced with a symlink. I'm using latest Git/1.8.5.4 under Ubuntu 12.04.4 x64. Steps to reproduce initial state: $ git init $ mkdir dir $ touch dir/file.txt $ git add dir/file.txt $ git commit -m 'Initial commit' $ rm -r dir $ ln -s -T /something/does/not/matter dir $ git status # Changes not staged for commit: # # deleted:dir/file.txt # # Untracked files: # # dir Now the bug itself: $ git stash error: 'dir/file.txt' is beyond a symbolic link fatal: Unable to process path dir/file.txt Cannot save the current worktree state Target of the symlink doesn't matter, as far as I understand. Doing `git add --all` or `git rm --cached dir/file.txt` doesn't change the result - still fatal. Git tries to delete file dir/file.txt, which does not exist. It confused by existing dir. However `git checkout .` works fine: symlink deleted, directory restored. -- Vovan-VE -- 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: gitweb.cgi bug
On Mon, Feb 10, 2014 at 12:06 AM, Andrew Keller and...@kellerfarm.com wrote:
On Feb 8, 2014, at 10:19 PM, Dongsheng Song wrote:
On Sun, Feb 9, 2014 at 12:29 AM, Andrew Keller and...@kellerfarm.com wrote:
On Feb 8, 2014, at 8:37 AM, Dongsheng Song wrote:
I have an git repo PROJECT.git, the full path is /srv/repo/git/PROJECT.git,
when I set git_base_url_list in gitweb.conf:
@git_base_url_list = qw(https://192.168.30.239/repo/git
git@192.168.30.239:repo/git);
I got the result:
https://192.168.30.239/repo/git/PROJECT.git
git@192.168.30.239:/PROJECT.git
This is wrong, it should be (without the leading '/')
git@192.168.30.239:PROJECT.git
There is no way to generate a fetch url of 'git@192.168.30.239:PROJECT.git'
in gitweb.
If one of the base urls was 'git@192.168.30.239:.', then you could get a
fetch URL of 'git@192.168.30.239:./PROJECT.git'
In general, though, I like to stay away from relative paths. Weird things
can happen, like HTTP works but SSH doesn't, because the home directory for
SSH changed because you used a different user.
What's about the following translate rules ?
git@192.168.30.239: - git@192.168.30.239:PROJECT.git
git@192.168.30.239:/ - git@192.168.30.239:/PROJECT.git
git@192.168.30.239:/repo - git@192.168.30.239:/repo/PROJECT.git
git@192.168.30.239:/repo/ - git@192.168.30.239:/repo/PROJECT.git
I think that those translation rules are completely reasonable.
However, that's not what gitweb was originally designed to do. What you're
describing is a desire for a new feature, not the existence of a bug.
Basically, gitweb does not support relative paths when the base url does not
contain part of the path already.
I don't know Perl, but I think change the following translate code is
not a hard work:
# use per project git URL list in $projectroot/$project/cloneurl
# or make project git URL from git base URL and project name
my $url_tag = URL;
my @url_list = git_get_project_url_list($project);
@url_list = map { $_/$project } @git_base_url_list unless @url_list;
foreach my $git_url (@url_list) {
next unless $git_url;
print format_repo_url($url_tag, $git_url);
$url_tag = ;
}
You're right - that is where the change should be applied, and the change you
suggest is pretty simple.
However, I'm not confident that the syntax for a relative path is the same
for all schemes. (Others on the list, feel free to object.) Since gitweb
blindly concatenates the base URL and the relative project path, I'm worried
that adding the proper functionality for one scheme will yield incorrect
behavior for another scheme.
Can you move your repository to a subfolder? Can use use absolute paths
instead of relative paths? Either of those approaches work around this
issue. I don't mean to coldly tell you that the solution is don't do that,
but on the surface, this seems like a nasty problem.
- Andrew
Thanks, I hope this 'new feature' will translate into reality, and not
take too long.
--
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: attr.c doesn't honor --work-tree option
On 6 February 2014 18:54, Junio C Hamano gits...@pobox.com wrote:
Lasse Makholm lasse.makh...@gmail.com writes:
Here's a repro with -DDEBUG_ATTR=1 and a printf() in read_attr_from_file():
$ cd /tmp/
$ mkdir -p attr-test/repo
$ cd attr-test/repo
$ git init
Initialized empty Git repository in /tmp/attr-test/repo/.git/
$ echo 'dir/* filter=foo' .gitattributes
$
Inside the working tree, it works:
$ ~/src/git.git/git check-attr -a dir/file
Does check-ignore misbehave the same way?
No, check-ignore works but also has NEED_WORK_TREE set. And that
actually also feels a bit wrong to me because check-attr and
check-ignore both seem like reasonable things to do in a bare repo
because .git(attributes|ignore) files are likely to be committed in
the repo.
I suspect that is this because check-attr is not a command that
requires a working tree. The command was written primarily as a
debugging aid that can be used anywhere as long as you have a
repository to read strings from either its standard input or its
arguments, and gives them directly to check_attr(), but it does so
without first going to the top of the real working tree like
check-ignore does.
Fair point. I actually stumbled across this because a git cat-file
--textconv ... was failing, so that's at least one other (and arguably
more real) use case that is broken in the same way.
Forcing it to go to the top of the working tree (see the attached
one-liner, but note that I didn't test it) may give you want you
want.
For this case, it does, yes. But it also breaks check-attr in bare
repos with attributes defined in $GIT_DIR/info/attributes because it
will refuse to run without a work tree...
In any case the current state seems broken because --work-tree clearly
doesn't work for all commands...
Setting NEED_WORK_TREE for check-attr risks breaking existing scripts
but on the other hand there doesn't seem to be any good reason why
check-attr and check-ignore should differ in this regard...
It seems like the ideal solution would be an optional NEED_WORK_TREE
of some sort that would let these commands work correctly both with
--work-tree, without it and in bare repos but I get that that might
not be easy to fix...
Another approach might be to deprecate --work-tree and tell people to
use -C instead...
/L
git.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git.c b/git.c
index 7cf2953..314ec9f 100644
--- a/git.c
+++ b/git.c
@@ -342,7 +342,7 @@ static struct cmd_struct commands[] = {
{ branch, cmd_branch, RUN_SETUP },
{ bundle, cmd_bundle, RUN_SETUP_GENTLY },
{ cat-file, cmd_cat_file, RUN_SETUP },
- { check-attr, cmd_check_attr, RUN_SETUP },
+ { check-attr, cmd_check_attr, RUN_SETUP | NEED_WORK_TREE },
{ check-ignore, cmd_check_ignore, RUN_SETUP | NEED_WORK_TREE },
{ check-mailmap, cmd_check_mailmap, RUN_SETUP },
{ check-ref-format, cmd_check_ref_format },
--
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 2/2] gc: config option for running --auto in background
On Mon, Feb 10, 2014 at 6:03 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
`gc --auto` takes time and can block the user temporarily (but not any
- if (!quiet)
- fprintf(stderr,
- _(Auto packing the repository for
optimum performance. You may also\n
- run \git gc\ manually. See
- \git help gc\ for more
information.\n));
+ if (!quiet) {
+ if (detach_auto)
+ fprintf(stderr, _(Auto packing the
repository in background for optimum performance.\n));
+ else
+ fprintf(stderr, _(Auto packing the
repository for optimum performance.\n));
+ fprintf(stderr, _(See \git help gc\ for manual
housekeeping.\n));
+ }
+ if (detach_auto)
+ /*
+* failure to daemonize is ok, we'll continue
+* in foreground
+*/
+ daemonize();
While I agree that it should be OK, shouldn't we warn the user?
If --quiet is set, we should not be printing anyway. If not, I thinkg
we could only print auto packing in background.. when we actually
can do that, else just print the old message. It means an #ifdef
NO_POSIX_GOODIES here again though..
--
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 v2 2/2] gc: config option for running --auto in background
On Mon, Feb 10, 2014 at 2:17 PM, Duy Nguyen pclo...@gmail.com wrote:
On Mon, Feb 10, 2014 at 6:03 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
`gc --auto` takes time and can block the user temporarily (but not any
- if (!quiet)
- fprintf(stderr,
- _(Auto packing the repository for
optimum performance. You may also\n
- run \git gc\ manually. See
- \git help gc\ for more
information.\n));
+ if (!quiet) {
+ if (detach_auto)
+ fprintf(stderr, _(Auto packing the
repository in background for optimum performance.\n));
+ else
+ fprintf(stderr, _(Auto packing the
repository for optimum performance.\n));
+ fprintf(stderr, _(See \git help gc\ for manual
housekeeping.\n));
+ }
+ if (detach_auto)
+ /*
+* failure to daemonize is ok, we'll continue
+* in foreground
+*/
+ daemonize();
While I agree that it should be OK, shouldn't we warn the user?
If --quiet is set, we should not be printing anyway. If not, I thinkg
we could only print auto packing in background.. when we actually
can do that, else just print the old message. It means an #ifdef
NO_POSIX_GOODIES here again though..
Yuck, it's probably better to simply silently drop the detaching, I guess.
--
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 2/6] t5538: fix default http port
On Sat, Feb 08, 2014 at 02:36:11PM +0700, Duy Nguyen wrote:
Thinking on this more, I wonder if we should just do something like
this:
[...]
Yes!
Here it is as a Real Patch™. I just based it on master, so it can
replace your 5537/5538 fix in your series.
Next stop, attempt to start httpd at start_httpd regardless of
GIT_TEST_HTTPD. If successful, test_set_prereq HTTPD or something that
the following tests can use. If GIT_TEST_HTTPD is set and start_httpd
fails, error out, not set prereq.
I'd be fine with that, as I always run them anyway. The potential
downsides would be:
1. Is there anybody who has apache installed who would _not_ want to
bring it up for the test?
2. Is there anybody for whom the failure mode of bringing up apache
would be unpleasant (e.g., if it hangs the tests or something)?
For (1), we could perhaps have a GIT_NO_TEST_HTTPD to avoid it.
For (2), I suspect we may need to make our error handling more robust,
but getting people to run it is the first step to figuring out what the
problems are.
If we go this route, we should probably do the same for
GIT_TEST_GIT_DAEMON in t5570 (and for that matter, we should probably do
the same for the port numbers).
-- 8 --
Subject: [PATCH] tests: auto-set LIB_HTTPD_PORT from test name
We set the default apache port for each of the httpd tests
to the 4-digit test number of the test script. We want these
to remain unique so that the tests do not conflict with each
other when run in parallel.
Instead of doing it manually in each test script, let's just
set it from the test name at run time. This is simpler, and
is one less thing to be updated when test scripts are
renamed (e.g., when being re-rolled or when conflicting
after being merged with another topic).
Incidentally, this fixes a case where t5537 and t5538 used
the same port number (5537), and could conflict with each
other when run in parallel.
Signed-off-by: Jeff King p...@peff.net
---
t/lib-httpd.sh | 2 +-
t/t5537-fetch-shallow.sh | 1 -
t/t5538-push-shallow.sh | 1 -
t/t5540-http-push.sh | 1 -
t/t5541-http-push.sh | 1 -
t/t5550-http-fetch.sh| 1 -
t/t5551-http-fetch.sh| 1 -
t/t5561-http-backend.sh | 1 -
8 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh
index bfdff2a..b43162e 100644
--- a/t/lib-httpd.sh
+++ b/t/lib-httpd.sh
@@ -64,7 +64,7 @@ case $(uname) in
esac
LIB_HTTPD_PATH=${LIB_HTTPD_PATH-$DEFAULT_HTTPD_PATH}
-LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'8111'}
+LIB_HTTPD_PORT=${LIB_HTTPD_PORT-${this_test#t}}
TEST_PATH=$TEST_DIRECTORY/lib-httpd
HTTPD_ROOT_PATH=$PWD/httpd
diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh
index b0fa738..adf215a 100755
--- a/t/t5537-fetch-shallow.sh
+++ b/t/t5537-fetch-shallow.sh
@@ -178,7 +178,6 @@ if test -n $NO_CURL -o -z $GIT_TEST_HTTPD; then
test_done
fi
-LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5537'}
. $TEST_DIRECTORY/lib-httpd.sh
start_httpd
diff --git a/t/t5538-push-shallow.sh b/t/t5538-push-shallow.sh
index 0a6e40f..8e54ac5 100755
--- a/t/t5538-push-shallow.sh
+++ b/t/t5538-push-shallow.sh
@@ -126,7 +126,6 @@ if test -n $NO_CURL -o -z $GIT_TEST_HTTPD; then
test_done
fi
-LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5537'}
. $TEST_DIRECTORY/lib-httpd.sh
start_httpd
diff --git a/t/t5540-http-push.sh b/t/t5540-http-push.sh
index 5b0198c..8d7b3c5 100755
--- a/t/t5540-http-push.sh
+++ b/t/t5540-http-push.sh
@@ -16,7 +16,6 @@ then
fi
LIB_HTTPD_DAV=t
-LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5540'}
. $TEST_DIRECTORY/lib-httpd.sh
ROOT_PATH=$PWD
start_httpd
diff --git a/t/t5541-http-push.sh b/t/t5541-http-push.sh
index bfd241e..73af16f 100755
--- a/t/t5541-http-push.sh
+++ b/t/t5541-http-push.sh
@@ -12,7 +12,6 @@ if test -n $NO_CURL; then
fi
ROOT_PATH=$PWD
-LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5541'}
. $TEST_DIRECTORY/lib-httpd.sh
. $TEST_DIRECTORY/lib-terminal.sh
start_httpd
diff --git a/t/t5550-http-fetch.sh b/t/t5550-http-fetch.sh
index 8392624..1a3a2b6 100755
--- a/t/t5550-http-fetch.sh
+++ b/t/t5550-http-fetch.sh
@@ -8,7 +8,6 @@ if test -n $NO_CURL; then
test_done
fi
-LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5550'}
. $TEST_DIRECTORY/lib-httpd.sh
start_httpd
diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index a124efe..e07eaf3 100755
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -8,7 +8,6 @@ if test -n $NO_CURL; then
test_done
fi
-LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5551'}
. $TEST_DIRECTORY/lib-httpd.sh
start_httpd
diff --git a/t/t5561-http-backend.sh b/t/t5561-http-backend.sh
index b5d7fbc..d23fb02 100755
--- a/t/t5561-http-backend.sh
+++ b/t/t5561-http-backend.sh
@@ -8,7 +8,6 @@ if test -n $NO_CURL; then
test_done
fi
-LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5561'}
. $TEST_DIRECTORY/lib-httpd.sh
start_httpd
--
1.8.5.2.500.g8060133
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info
Re: [PATCH v3 00/26] inotify support
On 2014-02-10 11.37, Duy Nguyen wrote: Could we use relative path names internally, relative to $GIT_DIR ? No because this is when the client tell the server about $GIT_DIR. I guess we can use realpath(1) here. Good. I realized that the watcher can watch several repos at the same time. However, we could allow relative path names, which will be relative to $SOCKET_DIR, and loosen the demand for an absolut path name a little bit. And $SOCKET_DIR can be the same as $GIT_DIR, when we are watching only one repo. If you want I can update test-file-watcher to accept send and recv instead of and , respectively. The only command with the same name for response and request is hello. I can make it hello and helloack (or bonjour as response?). helloack looks good. -- 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] bash completion: Add --recurse-submodules
Sup Yut Sum ch3co...@gmail.com writes: Signed-off-by: Sup Yut Sum ch3co...@gmail.com --- contrib/completion/git-completion.bash | 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) Aren't you missing a commit message? -Keshav -- 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 v5 02/14] trailer: process trailers from file and arguments
Christian Couder chrisc...@tuxfamily.org writes: This is what if_exists and if_missing are all about. Either: the same key already exists regardless of the value and, in this case, what happens depends on what has been specified using the if_exists configuration variable. Or: the same key DOES NOT already exists regardless of the value and in this case, what happens depends on what has been specified using the if_missing configuration variable. Hmm, how should things like signed-off-by be handled? You may want to allow many entries with the same key with distinct values, but duplicated values may want to be handled differently (currently we only avoid to place a duplicate key, value consecutively, but keys with different semantics (e.g. fixes-bug: #bugid) may want to say unless the same key with the same value exists, append it at the end. -- 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 6/6] fetch-pack: fix deepen shallow over smart http with no-done cap
Duy Nguyen pclo...@gmail.com writes: On Fri, Feb 07, 2014 at 10:01:08AM -0800, Junio C Hamano wrote: Here is the difference between the posted series and what I queued after applying the changes suggested during the review. Thanks. I was going to send a reroll after the received comments. Could you put this on top of 6/6, just to make sure future changes in t5537 (maybe more or less commits created..) does not change the test behavior? It fixes the test name too. I originally thought, ok let's create commits in one test and do fetch in another. But it ended up in the same test and I forgot to update test name. Surely, and thanks for being careful. Will squash it in. -- 8 -- diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh index 1413caf..b300383 100755 --- a/t/t5537-fetch-shallow.sh +++ b/t/t5537-fetch-shallow.sh @@ -203,7 +203,7 @@ EOF # This test is tricky. We need large enough haves that fetch-pack # will put pkt-flush in between. Then we need a have the server # does not have, it'll send ACK %s ready -test_expect_success 'add more commits' ' +test_expect_success 'no shallow lines after receiving ACK ready' ' ( cd shallow for i in $(test_seq 10) @@ -224,7 +224,9 @@ test_expect_success 'add more commits' ' cd clone git checkout --orphan newnew test_commit new-too - git fetch --depth=2 + GIT_TRACE_PACKET=$TRASH_DIRECTORY/trace git fetch --depth=2 + grep fetch-pack ACK .* ready ../trace + ! grep fetch-pack done ../trace ) ' -- 8 -- -- 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 2/6] t5538: fix default http port
Jeff King p...@peff.net writes: Here it is as a Real Patch™. I just based it on master, so it can replace your 5537/5538 fix in your series. Thanks, looks good. Will put this at the bottom and rebuild the nd/http-fetch-shallow-fix series on top. 1. Is there anybody who has apache installed who would _not_ want to bring it up for the test? 2. Is there anybody for whom the failure mode of bringing up apache would be unpleasant (e.g., if it hangs the tests or something)? For (1), we could perhaps have a GIT_NO_TEST_HTTPD to avoid it. For (2), I suspect we may need to make our error handling more robust, but getting people to run it is the first step to figuring out what the problems are. If we go this route, we should probably do the same for GIT_TEST_GIT_DAEMON in t5570 (and for that matter, we should probably do the same for the port numbers). All good points. -- 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: bash completion patch
Thomas Rast t...@thomasrast.ch writes: Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr writes: [...] don't forget to Cc Junio if you think your patch is ready for inclusion. Heh, thanks. Everybody seems to think anything they send out to the list is ready for inclusion, so the last part may not be a piece of advice that is practically very useful, though ;-) That happens to me a lot, too. Perhaps it would be a clearer signal if you had an alias (or just something like gitster+patch) that we can send it to if we mean please include instead of what do you think of this? The intention from regulars like you I can read from the tone of the message (or if you want to you can mention it in the log message). If a clearer signal is really needed, perhaps we should say something like: Send any patch that has not been reviewed on the list fist to the list and area experts (you can learn who they are by running git blame and git shortlog on the part of the system you are touching) for review. Once the patch gains list consensus that it is a good change, and the maintainer hasn't picked it up (perhaps it fell through cracks), resend it to the maintainer with Cc: to the list. We could phrase it more brutally: If it is the first time a particular patch is sent to the list, it almost always is not ready for inclusion. but I do not think that is a good idea. -- 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 2/2] gc: config option for running --auto in background
Duy Nguyen pclo...@gmail.com writes:
On Mon, Feb 10, 2014 at 6:03 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
`gc --auto` takes time and can block the user temporarily (but not any
- if (!quiet)
- fprintf(stderr,
- _(Auto packing the repository for
optimum performance. You may also\n
- run \git gc\ manually. See
- \git help gc\ for more
information.\n));
+ if (!quiet) {
+ if (detach_auto)
+ fprintf(stderr, _(Auto packing the
repository in background for optimum performance.\n));
+ else
+ fprintf(stderr, _(Auto packing the
repository for optimum performance.\n));
+ fprintf(stderr, _(See \git help gc\ for manual
housekeeping.\n));
+ }
+ if (detach_auto)
+ /*
+* failure to daemonize is ok, we'll continue
+* in foreground
+*/
+ daemonize();
While I agree that it should be OK, shouldn't we warn the user?
If --quiet is set, we should not be printing anyway. If not, I thinkg
we could only print auto packing in background.. when we actually
can do that, else just print the old message. It means an #ifdef
NO_POSIX_GOODIES here again though..
Didn't you change it not to die but return nosys or something?
--
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 1/2] daemon: move daemonize() to libgit.a
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
diff --git a/setup.c b/setup.c
index 6c3f85f..b09a412 100644
--- a/setup.c
+++ b/setup.c
@@ -787,3 +787,27 @@ void sanitize_stdfds(void)
if (fd 2)
close(fd);
}
+
+int daemonize(void)
+{
+#ifdef NO_POSIX_GOODIES
+ errno = -ENOSYS;
Negated?
+ return -1;
+#else
+ switch (fork()) {
+ case 0:
+ break;
+ case -1:
+ die_errno(fork failed);
+ default:
+ exit(0);
+ }
+ if (setsid() == -1)
+ die_errno(setsid failed);
+ close(0);
+ close(1);
+ close(2);
+ sanitize_stdfds();
+ return 0;
+#endif
+}
--
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: Documentation about push.default=upstream is confusing
Ingo Rohloff lund...@gmx.de writes: To handle that I setup several remote tracking branches called: repo1_master (tracks repo1/master) repo2_master (tracks repo2/master) reap3_master (tracks repo3/master) Now without push.default=upstream I would have to either always explicitly do something like: git push repo1 repo1_master:master git push repo2 repo2_master:master If you think about your interaction with people who are only looking at repo1 alone, you _are_ using a centralized workflow. You are not the only one who update their 'master'; other people push there to update that 'master' and you pull it in to keep you up to date and further build your changes on top. Such an interaction with other people by using repo1 as the shared meeting point is well served by the push-to-upstream mechanism, and that kind of interaction is called centralized workflow. The illustration from you is running one centralized workflow with each of the three repositories. The de-centralized workflow the message hints (but does not talk about) is different. It is not uncommon to pull from one place and then to push the result out to your own publishing branch (e.g. clone from anna, fetch to keep up to date with her, work on it, publish to your repository to tell her to fetch from you), and push-to-upstream is not very well suited for that topology. You may clone her for-bob branch, but you do not push it back to her repository to update her for-bob branch. -- 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 2/6] t5538: fix default http port
On Mon, Feb 10, 2014 at 02:15:24PM -0500, Jeff King wrote:
Thanks. It might be worth squashing in the patch below (or sticking it
on top), to cover git-daemon as well.
Patch would probably be easier to read if I actually included it...
-- 8 --
Subject: [PATCH] tests: auto-set git-daemon port
A recent commit taught lib-httpd to always start apache on
the same port as the numbered tests. Let's do the same for
the git-daemon tests.
Signed-off-by: Jeff King p...@peff.net
---
t/lib-git-daemon.sh | 2 +-
t/t5570-git-daemon.sh | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh
index 394b06b..1f22de2 100644
--- a/t/lib-git-daemon.sh
+++ b/t/lib-git-daemon.sh
@@ -22,7 +22,7 @@ then
test_done
fi
-LIB_GIT_DAEMON_PORT=${LIB_GIT_DAEMON_PORT-'8121'}
+LIB_GIT_DAEMON_PORT=${LIB_GIT_DAEMON_PORT-${this_test#t}}
GIT_DAEMON_PID=
GIT_DAEMON_DOCUMENT_ROOT_PATH=$PWD/repo
diff --git a/t/t5570-git-daemon.sh b/t/t5570-git-daemon.sh
index e061468..6b16379 100755
--- a/t/t5570-git-daemon.sh
+++ b/t/t5570-git-daemon.sh
@@ -3,7 +3,6 @@
test_description='test fetching over git protocol'
. ./test-lib.sh
-LIB_GIT_DAEMON_PORT=${LIB_GIT_DAEMON_PORT-5570}
. $TEST_DIRECTORY/lib-git-daemon.sh
start_git_daemon
--
1.8.5.2.500.g8060133
--
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 2/6] t5538: fix default http port
On Mon, Feb 10, 2014 at 10:23:53AM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: Here it is as a Real Patch™. I just based it on master, so it can replace your 5537/5538 fix in your series. Thanks, looks good. Will put this at the bottom and rebuild the nd/http-fetch-shallow-fix series on top. Thanks. It might be worth squashing in the patch below (or sticking it on top), to cover git-daemon as well. AFAICT, that leaves SVN_HTTPD_PORT, which we do not set by default at all, and the p4 tests, which already do their own similar magic. The set GIT_HTTPD_TESTS by default magic should probably go in a separate series, so I'll roll them by themselves. -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 v2 2/2] gc: config option for running --auto in background
On Mon, Feb 10, 2014 at 10:43 AM, Junio C Hamano gits...@pobox.com wrote: If --quiet is set, we should not be printing anyway. If not, I thinkg we could only print auto packing in background.. when we actually can do that, else just print the old message. It means an #ifdef NO_POSIX_GOODIES here again though.. Didn't you change it not to die but return nosys or something? Ah, the problem is that it is too late to take back ... will do so in the background when you noticed that daemonize() did not succeed, so you would need a way to see if we can daemonize() before actually doing so if you want to give different messages. int can_daemonize(void) could be an answer that is nicer than NO_POSIX_GOODIES, but I am not sure if it is worth 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] hashmap.h: make sure map entries are tightly packed
Karsten Blees karsten.bl...@gmail.com writes: ... At the very least we shouldn't stall the rest of the patch series on a hunch that the last (unfortunately non-standard) patch may break on some legacy system. Oh, no question about it. I was planning split out the last one and merge the rest to 'master' after the current cycle. -- 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 v5 02/14] trailer: process trailers from file and arguments
From: Junio C Hamano gits...@pobox.com Subject: Re: [PATCH v5 02/14] trailer: process trailers from file and arguments Date: Mon, 10 Feb 2014 10:14:34 -0800 Christian Couder chrisc...@tuxfamily.org writes: This is what if_exists and if_missing are all about. Either: the same key already exists regardless of the value and, in this case, what happens depends on what has been specified using the if_exists configuration variable. Or: the same key DOES NOT already exists regardless of the value and in this case, what happens depends on what has been specified using the if_missing configuration variable. Hmm, how should things like signed-off-by be handled? You may want to allow many entries with the same key with distinct values, but duplicated values may want to be handled differently (currently we only avoid to place a duplicate key, value consecutively, but keys with different semantics (e.g. fixes-bug: #bugid) may want to say unless the same key with the same value exists, append it at the end. Many entries with the same key but distinct values can be configured using: if_exists = add_if_different if_missing = add Many entries with the same key but values that can be the same can be configured using: if_exists = add if_missing = add The place where the trailers are added, if they should be added, can be selected using either where = after, the default, or where = before. where = after means just after trailers with the same key, or, if there are no trailers with the same key, after all the existing trailers. where = before means just before trailers with the same key, or, if there are no trailers with the same key, before all the existing trailers. I think that this is enough to handle most of the usual cases, but we can add other more complex options later, as I said in the last message of this thread: http://thread.gmane.org/gmane.comp.version-control.git/237278/ Thanks, 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 v5 02/14] trailer: process trailers from file and arguments
Christian Couder chrisc...@tuxfamily.org writes: Many entries with the same key but distinct values can be configured using: if_exists = add_if_different if_missing = add Many entries with the same key but values that can be the same can be configured using: if_exists = add if_missing = add While the above certainly can express the combinations, I am still puzzled about the value of having under this condition (i.e. if-exists/if-missing) and do this (i.e. add/add-if-different) as two separate concepts. If you do not have an existing entry with the same key, no new entry can be the same as an existing one---therefore, the former allow only distinct values for the same key can just say trailer.Fixes.action = add_if_different or something, without any if_exists/if_missing. In a similar way, the latter duplicated values allowed for the same key can say trailer.Sob.action = add You can throw into the mix other actions like add_if_missing, you can also express only one value allowed for the same key---the first one wins, replace to mean replace if there is one with the same key, and replace_or_add to mean same as 'replace', but add if there is no existing entries with the same key. Will we lose expressiveness by simplifying the semantics, getting rid of this under this condition part and instead making do this part more intelligent? Even if we assume, for the sake of discussion, that it *is* a good idea to separate under this condition part and do this part, I do not think the above is the only or the best way to express distinct values allowed for the same key. How do we argue that this from your example if_exists = add_if_different if_missing = add is a better design than this, for example? if_key_value_exists = ignore ; exact matching key,val exists if_key_exists = add ; otherwise if_missing = add The latter splits remaining conditional logic from do this part (no more add_if_different that causes add action to see if there is the same key and act differently) and moves it to under this condition part. I am trying to illustrate that the line to split the under this condition and do this looks arbitrary and fuzzy here, and because of this arbitrary-ness and fuzziness, it is not very obvious to me why it is a good idea to have under this condition as a separate concept from do this settings. What is the advantage of having such an extra axis? Does it make it easier to manage? Does it allow us to express more? I can see that the location where a new entry (or a duplicated one) is added (i.e. do we prepend? do we append?) can be orthogonal to any of the above; no need to bring up 'where' in the discussion. -- 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] docs/merge-strategies: remove hyphen from mis-merges
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 PULL] l10n updates for 1.9.0 round 2
Thansk. -- 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] tests: turn on network daemon tests by default
We do not run the httpd nor git-daemon tests by default, as
they are rather heavyweight and require network access
(albeit over localhost). However, it would be nice if more
pepole ran them, for two reasons:
1. We would get more test coverage on more systems.
2. The point of the test suite is to find regressions. It
is very easy to change some of the underlying code and
break the httpd code without realizing you are even
affecting it. Running the httpd tests helps find these
problems sooner (ideally before the patches even hit
the list).
We still want to leave an out, though, for people who
really do not want to run them. For that reason, the
GIT_TEST_HTTPD and GIT_TEST_GIT_DAEMON variables are now
tri-state booleans (true/false/auto), so you can say
GIT_TEST_HTTPD=false to turn the tests back off.
In addition, we are forgiving of common setup failures
(e.g., you do not have apache installed, or have an old
version) when the tri-state is auto (or empty), but report
an error when it is true. This makes auto a sane
default, as we should not cause failures on setups where the
tests cannot run. But it allows people who use true to
catch regressions in their system (e.g., they uninstalled
apache, but were expecting their automated test runs to test
git-httpd, and would want to be notified).
Signed-off-by: Jeff King p...@peff.net
---
I dug in the history to see if there was any reasoning given for the
current off by default setting. It looks like Junio asked for it when
the original http-push tests were added, and everything else just
followed that. The reasoning there was basically they're heavyweight
and we might not be able to run them, but hopefully having the option
variable will make that OK.
t/lib-git-daemon.sh | 8 +---
t/lib-httpd.sh | 22 +++---
t/test-lib-functions.sh | 44
3 files changed, 60 insertions(+), 14 deletions(-)
diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh
index 1f22de2..e623bef 100644
--- a/t/lib-git-daemon.sh
+++ b/t/lib-git-daemon.sh
@@ -16,9 +16,10 @@
# stop_git_daemon
# test_done
-if test -z $GIT_TEST_GIT_DAEMON
+GIT_TEST_GIT_DAEMON=$(test_tristate $GIT_TEST_GIT_DAEMON)
+if test $GIT_TEST_GIT_DAEMON = false
then
- skip_all=git-daemon testing disabled (define GIT_TEST_GIT_DAEMON to
enable)
+ skip_all=git-daemon testing disabled (unset GIT_TEST_GIT_DAEMON to
enable)
test_done
fi
@@ -58,7 +59,8 @@ start_git_daemon() {
kill $GIT_DAEMON_PID
wait $GIT_DAEMON_PID
trap 'die' EXIT
- error git daemon failed to start
+ test_skip_or_die $GIT_TEST_GIT_DAEMON \
+ git daemon failed to start
fi
}
diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh
index b43162e..bb900ca 100644
--- a/t/lib-httpd.sh
+++ b/t/lib-httpd.sh
@@ -30,9 +30,10 @@
# Copyright (c) 2008 Clemens Buchacher dri...@aon.at
#
-if test -z $GIT_TEST_HTTPD
+GIT_TEST_HTTPD=$(test_tristate $GIT_TEST_HTTPD)
+if test $GIT_TEST_HTTPD = false
then
- skip_all=Network testing disabled (define GIT_TEST_HTTPD to enable)
+ skip_all=Network testing disabled (unset GIT_TEST_HTTPD to enable)
test_done
fi
@@ -76,8 +77,7 @@ GIT_VALGRIND_OPTIONS=$GIT_VALGRIND_OPTIONS; export
GIT_VALGRIND_OPTIONS
if ! test -x $LIB_HTTPD_PATH
then
- skip_all=skipping test, no web server found at '$LIB_HTTPD_PATH'
- test_done
+ test_skip_or_die $GIT_TEST_HTTPD no web server found at
'$LIB_HTTPD_PATH'
fi
HTTPD_VERSION=`$LIB_HTTPD_PATH -v | \
@@ -89,19 +89,20 @@ then
then
if ! test $HTTPD_VERSION -ge 2
then
- skip_all=skipping test, at least Apache version 2 is
required
- test_done
+ test_skip_or_die $GIT_TEST_HTTPD \
+ at least Apache version 2 is required
fi
if ! test -d $DEFAULT_HTTPD_MODULE_PATH
then
- skip_all=Apache module directory not found. Skipping
tests.
- test_done
+ test_skip_or_die $GIT_TEST_HTTPD \
+ Apache module directory not found
fi
LIB_HTTPD_MODULE_PATH=$DEFAULT_HTTPD_MODULE_PATH
fi
else
- error Could not identify web server at '$LIB_HTTPD_PATH'
+ test_skip_or_die $GIT_TEST_HTTPD \
+ Could not identify web server at '$LIB_HTTPD_PATH'
fi
prepare_httpd() {
@@ -155,9 +156,8 @@ start_httpd() {
3 24
if test $? -ne 0
then
- skip_all=skipping test, web server setup failed
trap 'die' EXIT
- test_done
+ test_skip_or_die $GIT_TEST_HTTPD web server setup failed
fi
}
diff --git
Re: [PATCH v2 1/2] daemon: move daemonize() to libgit.a
On Tue, Feb 11, 2014 at 1:46 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
diff --git a/setup.c b/setup.c
index 6c3f85f..b09a412 100644
--- a/setup.c
+++ b/setup.c
@@ -787,3 +787,27 @@ void sanitize_stdfds(void)
if (fd 2)
close(fd);
}
+
+int daemonize(void)
+{
+#ifdef NO_POSIX_GOODIES
+ errno = -ENOSYS;
Negated?
Facepalm. I remember I wrote this somewhere but don't remember what
topic :( Should I resend?
--
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 11:55 PM, Torsten Bögershausen tbo...@web.de wrote: On 2014-02-10 11.37, Duy Nguyen wrote: Could we use relative path names internally, relative to $GIT_DIR ? No because this is when the client tell the server about $GIT_DIR. I guess we can use realpath(1) here. Good. I realized that the watcher can watch several repos at the same time. However, we could allow relative path names, which will be relative to $SOCKET_DIR, and loosen the demand for an absolut path name a little bit. And $SOCKET_DIR can be the same as $GIT_DIR, when we are watching only one repo. It does not help much anyway because file-watcher-lib.c sends get_git_work_tree(), which is absolute/normalized path, to file-watcher. There's no sources of sending $GIT_DIR relative to $SOCKET_DIR (and I don't think we want to make get_git_work_tree() relative before sending, it's more work on both sides we no benefits, except for tracing). -- 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 3/4] docs/git-clone: clarify use of --no-hardlinks option
Albert L. Lash, IV albert.l...@gmail.com writes:
Current text claims optimization, implying the use of
hardlinks, when this option ratchets down the level of
efficiency. This change explains the difference made by
using this option, namely copying instead of hardlinking,
and why it may be useful.
Signed-off-by: Albert L. Lash, IV ala...@bloomberg.net
---
Documentation/git-clone.txt | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index bf3dac0..0363d00 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -55,15 +55,12 @@ repository is specified as a URL, then this flag is
ignored (and we
never use the local optimizations). Specifying `--no-local` will
override the default when `/path/to/repo` is given, using the regular
Git transport instead.
-+
-To force copying instead of hardlinking (which may be desirable if you
-are trying to make a back-up of your repository), but still avoid the
-usual Git aware transport mechanism, `--no-hardlinks` can be used.
--no-hardlinks::
- Optimize the cloning process from a repository on a
- local filesystem by copying files under `.git/objects`
- directory.
+ Force the cloning process from a repository on a local
+ filesystem to copy the files under the `.git/objects`
+ directory instead of using hardlinks. This may be desirable
+ if you are trying to make a back-up of your repository.
Makes sense, and it is kind of embarrassing (I have to suspect that
this was originally the description of --hardlinks option).
[PATCH {1,2}/4] looked trivially correct, too.
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: [PATCH 4/4] docs/git-blame: explain more clearly the example pickaxe use
Albert L. Lash, IV albert.l...@gmail.com writes: We state that the following paragraph mentions the pickaxe interface, but the term pickaxe is not then used. This change clarifies that the example command uses the pickaxe interface and what it is searching for. Signed-off-by: Albert L. Lash, IV ala...@bloomberg.net --- Documentation/git-blame.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/git-blame.txt b/Documentation/git-blame.txt index 8e70a61..ddb88d0 100644 --- a/Documentation/git-blame.txt +++ b/Documentation/git-blame.txt @@ -35,7 +35,8 @@ Apart from supporting file annotation, Git also supports searching the development history for when a code snippet occurred in a change. This makes it possible to track when a code snippet was added to a file, moved or copied between files, and eventually deleted or replaced. It works by searching for -a text string in the diff. A small example: +a text string in the diff. A small example of the pickaxe interface +that searches for `blame_usage`: - $ git log --pretty=oneline -S'blame_usage' Thanks. I cannot shake this nagging feeling that this and the latter half of the previous paragraph may not belong to this page, though. Will queue. -- 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 v4 7/9] rebase: parse options in stuck-long mode
On Mon, Feb 10, 2014 at 01:59:02AM -0500, Eric Sunshine wrote: On Sun, Feb 9, 2014 at 8:03 PM, brian m. carlson sand...@crustytoothpaste.net wrote: From: Nicolas Vigier bo...@mars-attacks.org There is no functionnal change. The reason for this change is to be able s/functionnal/functional/ I could have sworn I fixed that typo in the commit message. No, that was a different patch with the same typo. Sorry about that; I should have double-checked. I'm going to wait another day or so to see if anyone thinks other changes are needed, and then I'll do a reroll. -- 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 00/11] More preparatory work for multiparent tree-walker
Kirill Smelkov k...@mns.spb.ru writes: Here I'm preparing tree-diff.c to be ready for the new tree-walker, so that the final change is tractable and looks good and non noisy. Some small speedups are gained along the way. The final bits are almost ready, but I don't want to release them in a hurry. No worries. We are not in a hurry to apply non-regression-fix changes during a pre-release feature freeze period anyway. This seems to somehow conflict with other topics and does not cleanly apply on top of your other tree-diff topic, by the way. -- 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
