* [PATCH/RFC] Move test-*.c to test/ subdirectory
From: Nguyễn Thái Ngọc Duy @ 2011-02-09 15:14 UTC (permalink / raw)
To: git; +Cc: Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
This makes topdir 19 files less and does not seem to break tests.
There's only one new test(-mktemp) on pu.
.gitignore | 19 ------
Makefile | 71 +++++++++++-----------
t/test-lib.sh | 6 +-
test/.gitignore | 19 ++++++
test-chmtime.c => test/chmtime.c | 0
test-ctype.c => test/ctype.c | 0
test-date.c => test/date.c | 0
test-delta.c => test/delta.c | 0
test-dump-cache-tree.c => test/dump-cache-tree.c | 0
test-genrandom.c => test/genrandom.c | 0
test-index-version.c => test/index-version.c | 0
test-line-buffer.c => test/line-buffer.c | 0
test-match-trees.c => test/match-trees.c | 0
test-obj-pool.c => test/obj-pool.c | 0
test-parse-options.c => test/parse-options.c | 0
test-path-utils.c => test/path-utils.c | 0
test-run-command.c => test/run-command.c | 0
test-sha1.c => test/sha1.c | 0
test-sigchain.c => test/sigchain.c | 0
test-string-pool.c => test/string-pool.c | 0
test-subprocess.c => test/subprocess.c | 0
test-svn-fe.c => test/svn-fe.c | 0
test-treap.c => test/treap.c | 0
23 files changed, 58 insertions(+), 57 deletions(-)
create mode 100644 test/.gitignore
rename test-chmtime.c => test/chmtime.c (100%)
rename test-ctype.c => test/ctype.c (100%)
rename test-date.c => test/date.c (100%)
rename test-delta.c => test/delta.c (100%)
rename test-dump-cache-tree.c => test/dump-cache-tree.c (100%)
rename test-genrandom.c => test/genrandom.c (100%)
rename test-index-version.c => test/index-version.c (100%)
rename test-line-buffer.c => test/line-buffer.c (100%)
rename test-match-trees.c => test/match-trees.c (100%)
rename test-obj-pool.c => test/obj-pool.c (100%)
rename test-parse-options.c => test/parse-options.c (100%)
rename test-path-utils.c => test/path-utils.c (100%)
rename test-run-command.c => test/run-command.c (100%)
rename test-sha1.c => test/sha1.c (100%)
rename test-sigchain.c => test/sigchain.c (100%)
rename test-string-pool.c => test/string-pool.c (100%)
rename test-subprocess.c => test/subprocess.c (100%)
rename test-svn-fe.c => test/svn-fe.c (100%)
rename test-treap.c => test/treap.c (100%)
diff --git a/.gitignore b/.gitignore
index 3dd6ef7..a99a216 100644
--- a/.gitignore
+++ b/.gitignore
@@ -161,25 +161,6 @@
/gitweb/GITWEB-BUILD-OPTIONS
/gitweb/gitweb.cgi
/gitweb/static/gitweb.min.*
-/test-chmtime
-/test-ctype
-/test-date
-/test-delta
-/test-dump-cache-tree
-/test-genrandom
-/test-index-version
-/test-line-buffer
-/test-match-trees
-/test-obj-pool
-/test-parse-options
-/test-path-utils
-/test-run-command
-/test-sha1
-/test-sigchain
-/test-string-pool
-/test-subprocess
-/test-svn-fe
-/test-treap
/common-cmds.h
*.tar.gz
*.dsc
diff --git a/Makefile b/Makefile
index 775ee83..617f910 100644
--- a/Makefile
+++ b/Makefile
@@ -416,25 +416,25 @@ PROGRAM_OBJS += http-backend.o
PROGRAMS += $(patsubst %.o,git-%$X,$(PROGRAM_OBJS))
-TEST_PROGRAMS_NEED_X += test-chmtime
-TEST_PROGRAMS_NEED_X += test-ctype
-TEST_PROGRAMS_NEED_X += test-date
-TEST_PROGRAMS_NEED_X += test-delta
-TEST_PROGRAMS_NEED_X += test-dump-cache-tree
-TEST_PROGRAMS_NEED_X += test-genrandom
-TEST_PROGRAMS_NEED_X += test-line-buffer
-TEST_PROGRAMS_NEED_X += test-match-trees
-TEST_PROGRAMS_NEED_X += test-obj-pool
-TEST_PROGRAMS_NEED_X += test-parse-options
-TEST_PROGRAMS_NEED_X += test-path-utils
-TEST_PROGRAMS_NEED_X += test-run-command
-TEST_PROGRAMS_NEED_X += test-sha1
-TEST_PROGRAMS_NEED_X += test-sigchain
-TEST_PROGRAMS_NEED_X += test-string-pool
-TEST_PROGRAMS_NEED_X += test-subprocess
-TEST_PROGRAMS_NEED_X += test-svn-fe
-TEST_PROGRAMS_NEED_X += test-treap
-TEST_PROGRAMS_NEED_X += test-index-version
+TEST_PROGRAMS_NEED_X += test/chmtime
+TEST_PROGRAMS_NEED_X += test/ctype
+TEST_PROGRAMS_NEED_X += test/date
+TEST_PROGRAMS_NEED_X += test/delta
+TEST_PROGRAMS_NEED_X += test/dump-cache-tree
+TEST_PROGRAMS_NEED_X += test/genrandom
+TEST_PROGRAMS_NEED_X += test/line-buffer
+TEST_PROGRAMS_NEED_X += test/match-trees
+TEST_PROGRAMS_NEED_X += test/obj-pool
+TEST_PROGRAMS_NEED_X += test/parse-options
+TEST_PROGRAMS_NEED_X += test/path-utils
+TEST_PROGRAMS_NEED_X += test/run-command
+TEST_PROGRAMS_NEED_X += test/sha1
+TEST_PROGRAMS_NEED_X += test/sigchain
+TEST_PROGRAMS_NEED_X += test/string-pool
+TEST_PROGRAMS_NEED_X += test/subprocess
+TEST_PROGRAMS_NEED_X += test/svn-fe
+TEST_PROGRAMS_NEED_X += test/treap
+TEST_PROGRAMS_NEED_X += test/index-version
TEST_PROGRAMS = $(patsubst %,%$X,$(TEST_PROGRAMS_NEED_X))
@@ -1829,7 +1829,7 @@ git.o git.spec \
$(patsubst %.perl,%,$(SCRIPT_PERL)) \
: GIT-VERSION-FILE
-TEST_OBJS := $(patsubst test-%$X,test-%.o,$(TEST_PROGRAMS))
+TEST_OBJS := $(patsubst test/%$X,test/%.o,$(TEST_PROGRAMS))
GIT_OBJS := $(LIB_OBJS) $(BUILTIN_OBJS) $(PROGRAM_OBJS) $(TEST_OBJS) \
git.o
ifndef NO_CURL
@@ -1839,8 +1839,8 @@ XDIFF_OBJS = xdiff/xdiffi.o xdiff/xprepare.o xdiff/xutils.o xdiff/xemit.o \
xdiff/xmerge.o xdiff/xpatience.o
VCSSVN_OBJS = vcs-svn/string_pool.o vcs-svn/line_buffer.o \
vcs-svn/repo_tree.o vcs-svn/fast_export.o vcs-svn/svndump.o
-VCSSVN_TEST_OBJS = test-obj-pool.o test-string-pool.o \
- test-line-buffer.o test-treap.o
+VCSSVN_TEST_OBJS = test/obj-pool.o test/string-pool.o \
+ test/line-buffer.o test/treap.o
OBJECTS := $(GIT_OBJS) $(XDIFF_OBJS) $(VCSSVN_OBJS)
dep_files := $(foreach f,$(OBJECTS),$(dir $f).depend/$(notdir $f).d)
@@ -1968,7 +1968,7 @@ $(VCSSVN_OBJS) $(VCSSVN_TEST_OBJS): $(LIB_H) \
vcs-svn/line_buffer.h vcs-svn/repo_tree.h vcs-svn/fast_export.h \
vcs-svn/svndump.h
-test-svn-fe.o: vcs-svn/svndump.h
+test/svn-fe.o: vcs-svn/svndump.h
endif
exec_cmd.s exec_cmd.o: EXTRA_CPPFLAGS = \
@@ -2100,7 +2100,8 @@ GIT-GUI-VARS: FORCE
fi
endif
-test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X))
+test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X))
+test_bindir_programs += $(patsubst test/%,bin-wrappers/test-%,$(TEST_PROGRAMS_NEED_X))
all:: $(TEST_PROGRAMS) $(test_bindir_programs)
@@ -2108,7 +2109,7 @@ bin-wrappers/%: wrap-for-bin.sh
@mkdir -p bin-wrappers
$(QUIET_GEN)sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's|@@BUILD_DIR@@|$(shell pwd)|' \
- -e 's|@@PROG@@|$(@F)|' < $< > $@ && \
+ -e 's|@@PROG@@|$(patsubst test-%,test/%,$(@F))|' < $< > $@ && \
chmod +x $@
# GNU make supports exporting all variables by "export" without parameters.
@@ -2122,27 +2123,27 @@ export NO_SVN_TESTS
test: all
$(MAKE) -C t/ all
-test-ctype$X: ctype.o
+test/ctype$X: ctype.o
-test-date$X: date.o ctype.o
+test/date$X: date.o ctype.o
-test-delta$X: diff-delta.o patch-delta.o
+test/delta$X: diff-delta.o patch-delta.o
-test-line-buffer$X: vcs-svn/lib.a
+test/line-buffer$X: vcs-svn/lib.a
-test-parse-options$X: parse-options.o
+test/parse-options$X: parse-options.o
-test-string-pool$X: vcs-svn/lib.a
+test/string-pool$X: vcs-svn/lib.a
-test-svn-fe$X: vcs-svn/lib.a
+test/svn-fe$X: vcs-svn/lib.a
.PRECIOUS: $(TEST_OBJS)
-test-%$X: test-%.o $(GITLIBS)
+test/%$X: test/%.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) $(filter %.a,$^) $(LIBS)
-check-sha1:: test-sha1$X
- ./test-sha1.sh
+check-sha1:: test/sha1$X
+ ./test/sha1.sh
check: common-cmds.h
if sparse; \
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 0fdc541..240caec 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -984,9 +984,9 @@ then
}
fi
-if ! test -x "$GIT_BUILD_DIR"/test-chmtime; then
- echo >&2 'You need to build test-chmtime:'
- echo >&2 'Run "make test-chmtime" in the source (toplevel) directory'
+if ! test -x "$GIT_BUILD_DIR"/test/chmtime; then
+ echo >&2 'You need to build test/chmtime:'
+ echo >&2 'Run "make test/chmtime" in the source (toplevel) directory'
exit 1
fi
diff --git a/test/.gitignore b/test/.gitignore
new file mode 100644
index 0000000..6e8a2a1
--- /dev/null
+++ b/test/.gitignore
@@ -0,0 +1,19 @@
+/chmtime
+/ctype
+/date
+/delta
+/dump-cache-tree
+/genrandom
+/index-version
+/line-buffer
+/match-trees
+/obj-pool
+/parse-options
+/path-utils
+/run-command
+/sha1
+/sigchain
+/string-pool
+/subprocess
+/svn-fe
+/treap
diff --git a/test-chmtime.c b/test/chmtime.c
similarity index 100%
rename from test-chmtime.c
rename to test/chmtime.c
diff --git a/test-ctype.c b/test/ctype.c
similarity index 100%
rename from test-ctype.c
rename to test/ctype.c
diff --git a/test-date.c b/test/date.c
similarity index 100%
rename from test-date.c
rename to test/date.c
diff --git a/test-delta.c b/test/delta.c
similarity index 100%
rename from test-delta.c
rename to test/delta.c
diff --git a/test-dump-cache-tree.c b/test/dump-cache-tree.c
similarity index 100%
rename from test-dump-cache-tree.c
rename to test/dump-cache-tree.c
diff --git a/test-genrandom.c b/test/genrandom.c
similarity index 100%
rename from test-genrandom.c
rename to test/genrandom.c
diff --git a/test-index-version.c b/test/index-version.c
similarity index 100%
rename from test-index-version.c
rename to test/index-version.c
diff --git a/test-line-buffer.c b/test/line-buffer.c
similarity index 100%
rename from test-line-buffer.c
rename to test/line-buffer.c
diff --git a/test-match-trees.c b/test/match-trees.c
similarity index 100%
rename from test-match-trees.c
rename to test/match-trees.c
diff --git a/test-obj-pool.c b/test/obj-pool.c
similarity index 100%
rename from test-obj-pool.c
rename to test/obj-pool.c
diff --git a/test-parse-options.c b/test/parse-options.c
similarity index 100%
rename from test-parse-options.c
rename to test/parse-options.c
diff --git a/test-path-utils.c b/test/path-utils.c
similarity index 100%
rename from test-path-utils.c
rename to test/path-utils.c
diff --git a/test-run-command.c b/test/run-command.c
similarity index 100%
rename from test-run-command.c
rename to test/run-command.c
diff --git a/test-sha1.c b/test/sha1.c
similarity index 100%
rename from test-sha1.c
rename to test/sha1.c
diff --git a/test-sigchain.c b/test/sigchain.c
similarity index 100%
rename from test-sigchain.c
rename to test/sigchain.c
diff --git a/test-string-pool.c b/test/string-pool.c
similarity index 100%
rename from test-string-pool.c
rename to test/string-pool.c
diff --git a/test-subprocess.c b/test/subprocess.c
similarity index 100%
rename from test-subprocess.c
rename to test/subprocess.c
diff --git a/test-svn-fe.c b/test/svn-fe.c
similarity index 100%
rename from test-svn-fe.c
rename to test/svn-fe.c
diff --git a/test-treap.c b/test/treap.c
similarity index 100%
rename from test-treap.c
rename to test/treap.c
--
1.7.4.74.g639db
^ permalink raw reply related
* Re: [PATCH/RFC] Move test-*.c to test/ subdirectory
From: Nguyen Thai Ngoc Duy @ 2011-02-09 15:23 UTC (permalink / raw)
To: git
In-Reply-To: <1297264469-13675-1-git-send-email-pclouds@gmail.com>
2011/2/9 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> This makes topdir 19 files less and does not seem to break tests.
except this because test-sha1.sh wasn't moved.
> -check-sha1:: test-sha1$X
> - ./test-sha1.sh
> +check-sha1:: test/sha1$X
> + ./test/sha1.sh
--
Duy
^ permalink raw reply
* Re: [PATCH] Documentation/merge subtree How-To: fix typo
From: Michael J Gruber @ 2011-02-09 15:58 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <1297242283-11532-1-git-send-email-u.kleine-koenig@pengutronix.de>
Uwe Kleine-König venit, vidit, dixit 09.02.2011 10:04:
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> ---
> Documentation/howto/using-merge-subtree.txt | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/howto/using-merge-subtree.txt b/Documentation/howto/using-merge-subtree.txt
> index 0953a50..2933056 100644
> --- a/Documentation/howto/using-merge-subtree.txt
> +++ b/Documentation/howto/using-merge-subtree.txt
> @@ -71,5 +71,5 @@ Additional tips
> relevant parts of your tree.
>
> - Please note that if the other project merges from you, then it will
> - connects its history to yours, which can be something they don't want
> + connect its history to yours, which can be something they don't want
> to.
On that occasion you may scrap the final "to". It's either "they don't
want" (which I suggest) or "they don't want to do".
Michael
^ permalink raw reply
* Advices to imlement update hook
From: Francis Moreau @ 2011-02-09 16:27 UTC (permalink / raw)
To: git
Hi !
I'd like to restrict access to one of my repos: the project tracked by
it has several directories: a/ b/ c/ and I'd like to allow only
modifications happen in b/ directory.
I'm planning to use git hooks, not sure which one I should use: if the
check should happen at the commit or push time or both.
For now I'm going to use the update hook, so it will happen when pushing.
Now the question is: what is the best way to do this ?
I'm planning to use something equivalent to "git-diff-tree oldref
newref | { grep -v b || exit 1; }" but doesn't look like the best git
way.
BTW, from the git-diff-tree manpage:
<path>...
If provided, the results are limited to a subset of
files matching one of these prefix strings. i.e., file
matches /^<pattern1>|<pattern2>|.../ Note that this
parameter does not provide any wildcard or regexp
features.
What does it mean exactly ? what does 'pattern' word mean if wildcard
or regexp is not supported ?
I also tried:
git diff-tree <oldref> <newref> -- ^b || exit 1
but it doesn't work.
Could anybody give me some advices ?
Thanks
--
Francis
^ permalink raw reply
* Re: Advices to imlement update hook
From: Johannes Sixt @ 2011-02-09 16:38 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <AANLkTimdsCgNBAnJmnzGj3M3Q4RPb==fiWu1+ZQhWenO@mail.gmail.com>
Am 2/9/2011 17:27, schrieb Francis Moreau:
> Hi !
>
> I'd like to restrict access to one of my repos: the project tracked by
> it has several directories: a/ b/ c/ and I'd like to allow only
> modifications happen in b/ directory.
>
> I'm planning to use git hooks, not sure which one I should use: if the
> check should happen at the commit or push time or both.
>
> For now I'm going to use the update hook, so it will happen when pushing.
>
> Now the question is: what is the best way to do this ?
>
> I'm planning to use something equivalent to "git-diff-tree oldref
> newref | { grep -v b || exit 1; }" but doesn't look like the best git
> way.
>
> BTW, from the git-diff-tree manpage:
>
> <path>...
> If provided, the results are limited to a subset of
> files matching one of these prefix strings. i.e., file
> matches /^<pattern1>|<pattern2>|.../ Note that this
> parameter does not provide any wildcard or regexp
> features.
>
> What does it mean exactly ? what does 'pattern' word mean if wildcard
> or regexp is not supported ?
> I also tried:
>
> git diff-tree <oldref> <newref> -- ^b || exit 1
>
> but it doesn't work.
git diff-tree --quiet <oldref> <newref> -- b
^ permalink raw reply
* Re: Advices to imlement update hook
From: Johannes Sixt @ 2011-02-09 16:42 UTC (permalink / raw)
To: Francis Moreau; +Cc: git
In-Reply-To: <4D52C2FA.2030103@viscovery.net>
[Sorry, sent too early - fat fingers :-(]
Am 2/9/2011 17:38, schrieb Johannes Sixt:
> Am 2/9/2011 17:27, schrieb Francis Moreau:
>> Hi !
>>
>> I'd like to restrict access to one of my repos: the project tracked by
>> it has several directories: a/ b/ c/ and I'd like to allow only
>> modifications happen in b/ directory.
>>
>> I'm planning to use git hooks, not sure which one I should use: if the
>> check should happen at the commit or push time or both.
...
>> I also tried:
>>
>> git diff-tree <oldref> <newref> -- ^b || exit 1
>>
>> but it doesn't work.
>
> git diff-tree --quiet <oldref> <newref> -- b
should do it; it sets the exit code.
But don't you also want to inspect all commits between oldref and newref?
Someone could have modified the directory, and then reverted the
modification in a later commit. If these commits arrive in a single push,
the above code wouldn't notice this.
-- Hannes
^ permalink raw reply
* Re: Advices to imlement update hook
From: Francis Moreau @ 2011-02-09 16:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4D52C403.30501@viscovery.net>
On Wed, Feb 9, 2011 at 5:42 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> [Sorry, sent too early - fat fingers :-(]
>
> Am 2/9/2011 17:38, schrieb Johannes Sixt:
>> Am 2/9/2011 17:27, schrieb Francis Moreau:
>>> Hi !
>>>
>>> I'd like to restrict access to one of my repos: the project tracked by
>>> it has several directories: a/ b/ c/ and I'd like to allow only
>>> modifications happen in b/ directory.
>>>
>>> I'm planning to use git hooks, not sure which one I should use: if the
>>> check should happen at the commit or push time or both.
> ...
>>> I also tried:
>>>
>>> git diff-tree <oldref> <newref> -- ^b || exit 1
>>>
>>> but it doesn't work.
>>
>> git diff-tree --quiet <oldref> <newref> -- b
>
> should do it; it sets the exit code.
but does that work if a commit modify b/ and another directory ?
> But don't you also want to inspect all commits between oldref and newref?
Yes I want to inspect all commits in the range.
> Someone could have modified the directory, and then reverted the
> modification in a later commit. If these commits arrive in a single push,
> the above code wouldn't notice this.
I agree but I thought that git diff-tree would list all changes made
between the 2 refs.
Thanks
--
Francis
^ permalink raw reply
* Adding default remotes to a bare repository
From: Francis Moreau @ 2011-02-09 16:53 UTC (permalink / raw)
To: git
Hi,
Is it possible to add some default remotes for a given repository ?
That is when cloning the repository, I can use the default remotes in
the cloned repository.
Thanks
--
Francis
^ permalink raw reply
* Re: Advices to imlement update hook
From: Jeff King @ 2011-02-09 17:05 UTC (permalink / raw)
To: Francis Moreau; +Cc: Johannes Sixt, git
In-Reply-To: <AANLkTik=Xw3b1i-AranJtfngOsfLvEDSzrMq3jKTy-Yy@mail.gmail.com>
On Wed, Feb 09, 2011 at 05:51:24PM +0100, Francis Moreau wrote:
> >>> git diff-tree <oldref> <newref> -- ^b || exit 1
> >>>
> >>> but it doesn't work.
> >>
> >> git diff-tree --quiet <oldref> <newref> -- b
> >
> > should do it; it sets the exit code.
>
> but does that work if a commit modify b/ and another directory ?
No, it just looks for commits that modified b. There is currently no way
to specify a path to say "commit that did not modify b". You need to
check the output of:
git rev-list | git diff-tree --stdin -m --name-only
which should list all paths modified by all commits. And then you can
either blacklist or whitelist as appropriate (note that the names can be
quoted; you might want to look at the "-z" option and do your
list-checking in perl).
> > But don't you also want to inspect all commits between oldref and newref?
>
> Yes I want to inspect all commits in the range.
see above.
> > Someone could have modified the directory, and then reverted the
> > modification in a later commit. If these commits arrive in a single push,
> > the above code wouldn't notice this.
>
> I agree but I thought that git diff-tree would list all changes made
> between the 2 refs.
Between the two endpoints. It won't even look at the commits in the
middle, so as long as a later middle commit reverts the change of an
earlier middle commit, the endpoints won't be affected.
-Peff
^ permalink raw reply
* Debugging Git push failure
From: Jeff Adamson @ 2011-02-09 18:57 UTC (permalink / raw)
To: git
Several developers on my team are experiencing an occasional failure
during push. A subsequent push executed immediately afterward the
failure will work fine. We are a small team of developers (about 10)
and only a couple users seem to experience this and then only
intermittently (every few days).
This is happening on a LAN environment with otherwise reliable
connectivity. We have some hook scripts for post-update and update
configured within the repo.
the server has git version 1.7.3.3 installed
$ cat /etc/issue
CentOS release 5.5 (Final)
Kernel \r on an \m
$ uname -a
Linux core1.example.com 2.6.18-194.26.1.el5 #1 SMP Tue Nov 9 12:54:20
EST 2010 x86_64 x86_64 x86_64 GNU/Linux
Here is some output from one of the users during two sequential runs
of `git push -v`. This user is git version 1.7.3.1.msysgit.0 (though
similar behavior has been seen by another user with version 1.7.0.4 on
ubuntu 10.04 LTS)
>git push -v
Pushing to ssh://git.example.com/data/git/example/scratch/bdd/cssearch-mockup.git
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 505 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
>git push -v
Pushing to ssh://git.example.com/data/git/example/scratch/bdd/cssearch-mockup.git
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 505 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
To ssh://git.example.com/data/git/example/scratch/bdd/cssearch-mockup.git
bffa1a7..8fd772d master -> master
Anyone know what could be causing this and, just as important, how to
debug it and issues like it in the future?
Thanks for any help/insight which can be offered.
--Jeff
^ permalink raw reply
* Re: t7006 sometimes hangs in cronjobs on OS X
From: Jeff King @ 2011-02-09 19:09 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Jonathan Nieder
In-Reply-To: <201102091538.46594.trast@student.ethz.ch>
On Wed, Feb 09, 2011 at 03:38:46PM +0100, Thomas Rast wrote:
> I have been running a nightly next&pu smoke tester each on RHEL5 and
> OS X. For quite some time (at least a month), t7006 gets stuck
> randomly (i.e., not every night). [This has been a bit of a problem
> because it keeps a lot of processes stuck on the machine and eats into
> my ulimit, but that's the case with any stuck process; I'll have to
> think about a good solution to that.]
>
> The relevant part of 'ps xwww' is
>
> 65211 ?? SN 0:00.03 /bin/sh t7006-pager.sh
> 65798 ?? SN 0:00.04 /usr/bin/perl /Users/trast/git-smoke/t/test-terminal.perl git --no-pager log
> 65846 ?? ZN 0:00.00 (git)
> 65847 ?? ZN 0:00.00 (perl5.10.0)
Hmm. The zombie git process implies to me that git has exited, but for
some reason we are still stuck in the copy-to-terminal loop and haven't
reaped it. But the zombie perl process confuses me. We fork a second
time so that one process copies stderr and the other one copies stdout.
Is the second perl process the stderr copier, and we are still blocking
on copying stdout for some reason? But then why is the command name
different? Is /usr/bin/perl a wrapper script on your platform?
Have you tried running strace on the surviving perl process to see what
it's doing? Presumably it's just hung on a read() syscall.
Or maybe try stracing the whole thing from the start, which may be more
informative, like:
diff --git a/t/lib-terminal.sh b/t/lib-terminal.sh
index c383b57..f7e6b7f 100644
--- a/t/lib-terminal.sh
+++ b/t/lib-terminal.sh
@@ -13,7 +13,7 @@ test_expect_success 'set up terminal for tests' '
echo >&4 "test_terminal: need to declare TTY prerequisite"
return 127
fi
- "$PERL_PATH" "$TEST_DIRECTORY"/test-terminal.perl "$@"
+ strace -f "$PERL_PATH" "$TEST_DIRECTORY"/test-terminal.perl "$@"
}
fi
'
and giving us the stderr dump (or perhaps redirecting strace output to a
file and saving it)?
> TEST_JOBS=6 nice make smoke
If you use TEST_JOBS=1, does it still happen? I can't imagine what race
condition would cause this, but there are other tests use
lib-terminal.sh, so perhaps there is some interference there.
-Peff
^ permalink raw reply related
* Re: t7006 sometimes hangs in cronjobs on OS X
From: Thomas Rast @ 2011-02-09 19:16 UTC (permalink / raw)
To: Jeff King; +Cc: git, Jonathan Nieder
In-Reply-To: <20110209190900.GA8314@sigill.intra.peff.net>
Jeff King wrote:
> On Wed, Feb 09, 2011 at 03:38:46PM +0100, Thomas Rast wrote:
>
> > I have been running a nightly next&pu smoke tester each on RHEL5 and
> > OS X. For quite some time (at least a month), t7006 gets stuck
> > randomly (i.e., not every night).
BTW, I just noticed when re-reading this that it's a bit confusing.
It never hangs on RHEL (i.e. Linux), only on OS X. (And I only
reported it now because I only just noticed that I had a month's worth
of zombies hanging around. :-)
> > 65211 ?? SN 0:00.03 /bin/sh t7006-pager.sh
> > 65798 ?? SN 0:00.04 /usr/bin/perl /Users/trast/git-smoke/t/test-terminal.perl git --no-pager log
> > 65846 ?? ZN 0:00.00 (git)
> > 65847 ?? ZN 0:00.00 (perl5.10.0)
>
> Hmm. The zombie git process implies to me that git has exited, but for
> some reason we are still stuck in the copy-to-terminal loop and haven't
> reaped it. But the zombie perl process confuses me. We fork a second
> time so that one process copies stderr and the other one copies stdout.
> Is the second perl process the stderr copier, and we are still blocking
> on copying stdout for some reason?
How do I find out?
> But then why is the command name
> different? Is /usr/bin/perl a wrapper script on your platform?
No, it's your average OS X binary (i.e., 'file' says it has an image
for every platform etc.).
The command name apparently just changes when it becomes a zombie:
when I run perl -e 'if (fork) {sleep 10;} else {sleep 5;}' they first
share the command line, but as soon as the child's sleep expires its
command line changes to '(perl5.10.0)'.
I'll have to put off the more involved experimentation somewhat :-(
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Re: Re: Updating a submodule with a compatible version from another submodule version using the parent meta-repository
From: Heiko Voigt @ 2011-02-09 19:36 UTC (permalink / raw)
To: Julian Ibarz; +Cc: Junio C Hamano, Jens Lehmann, git
In-Reply-To: <AANLkTim2G0kF+omPZ1_fk0P6oGDaKDWd79XNR5GXUkWG@mail.gmail.com>
Hi Julian,
On Wed, Feb 02, 2011 at 11:31:40PM -0500, Julian Ibarz wrote:
> So now my two questions that could save me some time are:
> - is there a function that gives the distance between two commits? I'm
> sure there is something like this coded somewhere but I didn't find it
> yet
One thing which now came to my mind is that you might be interested in
is to use merge bases to find the earliest commit that contains a
certain revision.
Have a look at how I implemented the submodule merge strategy that might
help you. You can find it in commit 68d03e4a. I basically do a search
for the earliest commit that contains the commits from both sides. You
could use a similar strategy but limit the possible candidates to a
restricted list of commits which are contained in the supermodule.
Cheers Heiko
^ permalink raw reply
* Re: t7006 sometimes hangs in cronjobs on OS X
From: Ben Walton @ 2011-02-09 18:30 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Jeff King, Jonathan Nieder
In-Reply-To: <201102091538.46594.trast@student.ethz.ch>
Excerpts from Thomas Rast's message of Wed Feb 09 09:38:46 -0500 2011:
> I have been running a nightly next&pu smoke tester each on RHEL5 and
> OS X. For quite some time (at least a month), t7006 gets stuck
> randomly (i.e., not every night). [This has been a bit of a problem
> because it keeps a lot of processes stuck on the machine and eats
> into my ulimit, but that's the case with any stuck process; I'll
> have to think about a good solution to that.]
I'm also seeing this test fail when runing the packaging tools for
OpenCSW. I haven't had a chance to investigate yet, but manual tests
of the script have run without errors so far. It's only during the
automated build that it fails. The automated build is initiated
manually but is run through a Makefile wrapper that will drastically
alter the environment. Beyond this, I have no further input. I'm
hoping to spend some time on it in the next few days.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
^ permalink raw reply
* Re: t7006 sometimes hangs in cronjobs on OS X
From: Thomas Rast @ 2011-02-09 20:22 UTC (permalink / raw)
To: Jeff King; +Cc: git, Jonathan Nieder
In-Reply-To: <201102092016.55078.trast@student.ethz.ch>
Thomas Rast wrote:
> I'll have to put off the more involved experimentation somewhat :-(
Or not.
Anyway, I managed to load the relevant parts of t7006 in an
interactive shell, and used
i=0
while test_terminal git --no-pager log >out.$i 2>&1; do
i=$(($i+1))
echo $i
done
to trigger the race. With
test_terminal () {
sudo "$PERL_PATH" "$TEST_DIRECTORY"/test-terminal.perl "$@"
}
which is the closest to dtruss I can get without actually using it, I
hit the race very quickly, usually in ~5 runs. But using either one
of
test_terminal () {
sudo dtruss "$PERL_PATH" "$TEST_DIRECTORY"/test-terminal.perl "$@"
}
test_terminal () {
sudo dtruss -f "$PERL_PATH" "$TEST_DIRECTORY"/test-terminal.perl "$@"
}
slows down things so much that it did not hit the race in useful time
(about 100 runs). I also tried running 'dtruss -n perl' in another
terminal and hoping it will hit a wall eventually, which does run a
bit faster but also got nowhere in about 350 runs.
Running 'dtruss -n git' instead did hit the issue, and I have the
output saved away, but I'm not sure what I'd be looking for. After
all, the git process becomes a zombie:
47606 s006 S+ 0:00.13 /usr/bin/perl /Users/trast/git/t/test-terminal.perl git --no-pager log
47607 s006 Z+ 0:00.00 (git)
47608 s006 Z+ 0:00.00 (perl5.10.0)
The output for pid 47607 ends in:
47607/0x1f7fec5: write_nocancel(0x1, "Author: A U Thor <author@example.com>\n\0", 0x26) = 38 0
47607/0x1f7fec5: write_nocancel(0x1, "Date: Thu Apr 7 15:13:13 2005 -0700\n\0", 0x26) = 38 0
47607/0x1f7fec5: write_nocancel(0x1, "\n\0", 0x1) = 1 0
47607/0x1f7fec5: write_nocancel(0x1, " initial\n\0", 0xC) = 12 0
47607/0x1f7fec5: fstat64(0x1, 0x7FFF5FBFE8A0, 0x0) = 0 0
47607/0x1f7fec5: fstat64(0x1, 0x7FFF5FBFEF60, 0x0) = 0 0
47607/0x1f7fec5: close_nocancel(0x1) = 0 0
Which seems rather unsurprising really :-(
Finally, attaching dtruss after hitting the race gives no output when
I finally kill it.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: t7006 sometimes hangs in cronjobs on OS X
From: Jeff King @ 2011-02-09 20:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Jonathan Nieder
In-Reply-To: <201102092122.19178.trast@student.ethz.ch>
On Wed, Feb 09, 2011 at 09:22:19PM +0100, Thomas Rast wrote:
> Thomas Rast wrote:
> > I'll have to put off the more involved experimentation somewhat :-(
>
> Or not.
>
> Anyway, I managed to load the relevant parts of t7006 in an
> interactive shell, and used
>
> i=0
> while test_terminal git --no-pager log >out.$i 2>&1; do
> i=$(($i+1))
> echo $i
> done
Great, that is a much smaller bit to work with. I of course can't
replicate it on my Linux boxes, though. :(
> Running 'dtruss -n git' instead did hit the issue, and I have the
> output saved away, but I'm not sure what I'd be looking for. After
> all, the git process becomes a zombie:
>
> 47606 s006 S+ 0:00.13 /usr/bin/perl /Users/trast/git/t/test-terminal.perl git --no-pager log
> 47607 s006 Z+ 0:00.00 (git)
> 47608 s006 Z+ 0:00.00 (perl5.10.0)
Yeah, I think the problem is going to be in the perl process, but...
> The output for pid 47607 ends in:
>
> 47607/0x1f7fec5: write_nocancel(0x1, "Author: A U Thor <author@example.com>\n\0", 0x26) = 38 0
> 47607/0x1f7fec5: write_nocancel(0x1, "Date: Thu Apr 7 15:13:13 2005 -0700\n\0", 0x26) = 38 0
> 47607/0x1f7fec5: write_nocancel(0x1, "\n\0", 0x1) = 1 0
> 47607/0x1f7fec5: write_nocancel(0x1, " initial\n\0", 0xC) = 12 0
> 47607/0x1f7fec5: fstat64(0x1, 0x7FFF5FBFE8A0, 0x0) = 0 0
> 47607/0x1f7fec5: fstat64(0x1, 0x7FFF5FBFEF60, 0x0) = 0 0
> 47607/0x1f7fec5: close_nocancel(0x1) = 0 0
>
> Which seems rather unsurprising really :-(
It doesn't close(2) also? That could be the problem. I would expect it
also to exit().
> Finally, attaching dtruss after hitting the race gives no output when
> I finally kill it.
Yeah, it is probably stuck in some syscall. You could try instrumenting
your test-terminal.perl like:
diff --git a/t/test-terminal.perl b/t/test-terminal.perl
index ee01eb9..1755017 100755
--- a/t/test-terminal.perl
+++ b/t/test-terminal.perl
@@ -55,11 +55,15 @@ sub copy_stdio {
defined $pid or die "fork failed: $!";
if (!$pid) {
close($out);
+ print STDERR "child: pumping stderr\n";
xsendfile(\*STDERR, $err);
+ print STDERR "child: done pumping stderr\n";
exit 0;
}
close($err);
+ print STDERR "parent: pumping stdout\n";
xsendfile(\*STDOUT, $out);
+ print STDERR "parent: done pumping stdout\n";
finish_child($pid) == 0
or exit 1;
}
and see which of those messages actually gets printed on the stuck case.
My suspicion is that one of the processes is getting stuck in xsendfile.
It may be the fault of File::Copy::copy, which I have seen be flaky
before on non-regular files. We should arguably be using non-buffered
I/O here anyway, so maybe try this:
diff --git a/t/test-terminal.perl b/t/test-terminal.perl
index ee01eb9..0d33da1 100755
--- a/t/test-terminal.perl
+++ b/t/test-terminal.perl
@@ -3,7 +3,6 @@ use 5.008;
use strict;
use warnings;
use IO::Pty;
-use File::Copy;
# Run @$argv in the background with stdio redirected to $out and $err.
sub start_child {
@@ -46,7 +45,13 @@ sub xsendfile {
# from a disconnected terminal will return
# EIO (as in AIX 4.x, IRIX, and Linux) or
# end-of-file. Either is fine.
- copy($in, $out, 4096) or $!{EIO} or die "cannot copy from child: $!";
+ while (1) {
+ my $r = sysread($in, my $buf, 4096);
+ last if $r == 0;
+ last if !defined $r and $!{EIO};
+ die "cannot copy from child: $!" unless defined $r;
+ syswrite($out, $buf);
+ }
}
sub copy_stdio {
^ permalink raw reply related
* Re: [PATCH] perl: Fix command_bidi_pipe() don't care about repository path
From: Junio C Hamano @ 2011-02-09 20:59 UTC (permalink / raw)
To: Masatake Osanai; +Cc: git
In-Reply-To: <1297091360-11409-1-git-send-email-unpush@gmail.com>
Masatake Osanai <unpush@gmail.com> writes:
> Subject: Re: [PATCH] perl: Fix command_bidi_pipe() don't care about repository path
Sorry but -ECANTPARSE. It is unclear if you are saying "the command does
not care, which is incorrect and it should", or "the command shouldn't
care, fix it as it does currently". It only turns out to be the former
after reading the body, but the subject must be understandable without
reading the body to keep "git shortlog" readable.
> command_bidi_pipe must care about repo_path() in case of repository
> instance.
Because...?
> This also fixes error on cat_blob() and hash_and_insert_object()
> in case of using outside of working tree.
Missing in your description are X and Y in: "Earier these functions did X
but they should do Y instead; the patch makes them do so".
> @@ -396,7 +396,16 @@ See C<command_close_bidi_pipe()> for details.
>
> sub command_bidi_pipe {
> my ($pid, $in, $out);
> + my($self) = _maybe_self(@_);
Nit; s/my/my /.
> + local %ENV = %ENV;
> + my $cwd_save = undef;
> + if ($self) {
> + shift;
> + $cwd_save = cwd();
> + _setup_git_cmd_env($self);
> + }
The POD description for this function says that it runs the same way as
command_output_pipe, which in turn uses _command_common_pipe that is
shared with command_input_pipe. The reason these two other functions are
Ok without this patch is because _cmd_exec() has the logic to do the repo
dependent set-up, as far as I can tell. But command_bidi_pipe() does not
use _cmd_exec(), and does not have a corresponding logic, and that is what
you are trying to fix.
Am I following your logic Ok so far?
It would have saved reviewers' time if you explained your patch a bit
better, perhaps like...
When command_input_pipe and command_output_pipe are used as a
method of a Git::repository instance, they eventually call into
_cmd_exec method that sets up the execution environment such as
GIT_DIR, GIT_WORK_TREE environment variables and the current
working directory in the child process that interacts with the
repository.
command_bidi_pipe however didn't expect to be called as such, and
lacked all these set-up. Because of this, a program that did this
did not work as expected:
my $repo = Git->repository(Directory => '/some/where/else');
my ($pid, $in, $out, $ctx) =
$repo->command_bidi_pipe(qw(hash-object -w --stdin-paths));
This patch refactors the _cmd_exec into _setup_git_cmd_env that
sets up the execution environment, and makes _cmd_exec and
command_bidi_pipe to use it.
Note that unlike _cmd_exec that execv's a git command as an
external process, command_bidi_pipe is called from the main line
of control, and the execution environment needs to be restored
after open2() does its magic.
Thanks.
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: Jeff King @ 2011-02-09 21:03 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Matthieu Moy, Sebastian Pipping, Git ML
In-Reply-To: <20110208100518.GA9505@neumann>
On Tue, Feb 08, 2011 at 11:05:18AM +0100, SZEDER Gábor wrote:
> > I think even the same people may different preferences from project to
> > project. For most of my projects, the scope of the repo is well-defined,
> > and I want full-tree semantics (e.g., I hack on a bug, go into t/ to
> > tweak and run the tests, and then want to "git add -u" the whole thing
> > when everything looks good). But I also recently worked on a gigantic
> > project that was split into several sub-components. I would cd 3 or 4
> > levels deep into the sub-component that I was working on, and I would
> > prefer my "git add -u" to stay in that sub-component, and my "git grep"
> > to look only in that sub-component.
>
> It sounds like your work focused solely on the sub-component you cd-d
> into. Did you have any other changes outside of that sub-component?
> Because when not, then both the current and the whole-tree "git add -u"
> would have the same effect.
Yes, I often did have other changes. They were usually one of two types.
The build infrastructure was in a separate directory, so one type would
be local tweaks to the build that should not end up getting committed.
The other type was required changes to another component that would get
committed separately (e.g., while working on component "foo" you realize
that it depends on a new feature in component "bar"; you leave "foo"
modified in the working tree, work on "bar", commit it, then come back
to "foo").
> The current and the whole-tree "git grep" would behave differently, of
> course. But even then a whole-tree "git grep" would be harmless and
> easy to limit in scope, though might be a bit annoying in the "cd deep
> down" case. In that case you would immediately see the matches
> outside of cwd, know that you forgot to limit the operation to cwd, so
> you hit the up key, simply append the "." to the last command, and you
> get what you wanted.
Yeah, grep is not as annoying because it does not have the "oops, I just
pushed this commit and it turns out that I screwed up "git add" five
minutes ago and it only had half of the files I intended" problem.
> As mentioned in this or other related threads, this is not at all that
> simple the other way around, i.e. with current "git grep" when you are
> in the sub-component and you happen to need a grep on the whole tree,
> because you have to pay attention to use the right number of "../"s.
Yes, it is annoying, but that is merely a syntactic issue. If we aliased
"/" to "the root of the project", then most arguments for full-tree
could be reversed for the relative case (e.g., "sure, but it's easy
enough to type 'git add /'").
For the record, I would much prefer full-tree behavior as the default,
and I think the '/' syntax is ugly and confusing. If you were asking at
the beginning of "git add -u" what the behavior should be, I would
absolutely say full-tree. But we're not there; we're talking about
changing existing behavior. And I'm not sure there is a clear-cut,
obvious-to-anybody-who-will-annoyed-with-the-change argument that
full-tree behavior is definitively better.
The most compelling I have seen is "you tend to notice accidental
full-tree sooner than accidental relative behavior". Which you mentioned
in your email. I just don't know if that passes the "will satisfy
annoyed users" test.
I dunno. I would not be sad at all if we moved to full-tree defaults
everywhere. I just don't want to have to be the one that annoyed users
yell at. :)
-Peff
^ permalink raw reply
* Re: [PATCH] mergetool: don't skip modify/remove conflicts
From: Junio C Hamano @ 2011-02-09 21:45 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <1297134518-4387-1-git-send-email-martin.von.zweigbergk@gmail.com>
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:
> diff --git a/rerere.h b/rerere.h
> index eaa9004..107a2bc 100644
> --- a/rerere.h
> +++ b/rerere.h
> @@ -6,6 +6,9 @@
> #define RERERE_AUTOUPDATE 01
> #define RERERE_NOAUTOUPDATE 02
>
> +extern void *RERERE_UTIL_PUNTED;
This is for paths without three-stages, i.e. ones rerere won't help.
Needs some comment for these two symbols.
Leading "RERERE_" is necessary for clarifying the namespace, PUNTED is
necessary because it defines what the symbols means, but why do we need
UTIL in the name? Drop it.
> +extern void *RERERE_UTIL_STAGED;
This is for what kind? The contents on the filesystem is ready to go,
added to the index, but still in MERGE_RR (i.e. "git rerere" not run yet)?
Is the real problem that git-mergetool is not running rerere when it
should, I wonder...
> diff --git a/rerere.c b/rerere.c
> index eb47f97..61cac54 100644
> --- a/rerere.c
> +++ b/rerere.c
> @@ -7,6 +7,10 @@
> #include "ll-merge.h"
> #include "attr.h"
>
> +#define RERERE_UTIL_ELIGIBLE NULL
> +void *RERERE_UTIL_PUNTED = &RERERE_UTIL_PUNTED;
> +void *RERERE_UTIL_STAGED = &RERERE_UTIL_STAGED;
> +
Same for "ELIGIBLE"; describe what it means.
> for (i = 0; i < active_nr; i++) {
> struct cache_entry *e = active_cache[i];
> struct string_list_item *it;
>
> - if (!ce_stage(e))
> + if (!ce_stage(e)) {
> continue;
> + }
Unnecessary change.
> it = string_list_insert(conflict, (const char *)e->name);
> - it->util = NULL;
> + it->util = RERERE_UTIL_PUNTED;
> if (ce_stage(e) == 1) {
> + it->util = RERERE_UTIL_STAGED;
Hmm, I thought that you were taling about paths that the user
hand-resolved and then ran "git add" on. Why is this marked "STAGED"?
Either your logic is wrong, or the name of the symbol is.
In any case, the original code is letting rerere handle both two-way
merge (stage #2 and #3 exist without state #1) and three-way merge (all
three stages exist) case, and changing only the body of this if statement
smells there is extremely fishy going on.
> @@ -487,8 +494,9 @@ static int do_plain_rerere(struct string_list *rr, int fd)
>
> for (i = 0; i < conflict.nr; i++) {
> const char *path = conflict.items[i].string;
> - if (!conflict.items[i].util)
> - continue; /* punted */
> + if (conflict.items[i].util == RERERE_UTIL_PUNTED ||
> + conflict.items[i].util == RERERE_UTIL_STAGED)
> + continue;
> if (!string_list_has_string(rr, path)) {
> unsigned char sha1[20];
> char *hex;
> @@ -648,8 +656,9 @@ int rerere_forget(const char **pathspec)
> find_conflict(&conflict);
> for (i = 0; i < conflict.nr; i++) {
> struct string_list_item *it = &conflict.items[i];
> - if (!conflict.items[i].util)
> - continue; /* punted */
> + if (conflict.items[i].util == RERERE_UTIL_PUNTED ||
> + conflict.items[i].util == RERERE_UTIL_STAGED)
> + continue;
There are a few repetition of "if it is marked with PUNTED or STAGED"; can
you make it into a small helper function and give it a _meaningful_ name?
What does it mean for an entry to be marked with either of these marks?
Thanks.
^ permalink raw reply
* [PATCH maint-1.7.0 v2 0/2] fast-import: introduce "feature notes" command
From: Jonathan Nieder @ 2011-02-09 21:46 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Thomas Rast, git, Johan Herland, Ramkumar Ramachandra,
Shawn O. Pearce, Sam Vilain, Junio C Hamano
In-Reply-To: <AANLkTi=bEi6J3wcex8JCowU6PRt3BKix5v67v8Ds-MN2@mail.gmail.com>
Sverre Rabbelier wrote:
> Perhaps we can submit a patch to maint to have it (the
> oldest git that supports the 'feature' command) recognize 'feature
> notes' though?
Thanks, both. Here's a series based against v1.7.0.9 to do that
(since 1.7.0.y is the oldest series with support for 'feature'.)
For ease of patching, patch 1 backports a related documentation tweak
from v1.7.4-rc0. Patch 2 introduces the "feature notes" command
itself.
Jonathan Nieder (2):
fast-import: clarify documentation of "feature" command
fast-import: introduce "feature notes" command
Documentation/git-fast-import.txt | 37 ++++++++++++++++++++-----------------
fast-import.c | 2 ++
t/t9301-fast-import-notes.sh | 1 +
3 files changed, 23 insertions(+), 17 deletions(-)
^ permalink raw reply
* Re: [PATCH 6/7] tag: support column output with --column
From: Junio C Hamano @ 2011-02-09 21:51 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1297178541-31124-7-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> @@ -52,7 +54,7 @@ static int show_reference(const char *refname, const unsigned char *sha1,
> }
>
> if (!filter->lines) {
> - printf("%s\n", refname);
> + string_list_append(&layout.items, refname);
Hmm, is this robbing streaming output from people who do not care about
columnar output?
I tend to agree with others who suggested you to port column to platforms
that lack it.
^ permalink raw reply
* Re: [PATCH] request-pull: Include newline in output
From: Junio C Hamano @ 2011-02-09 21:54 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <4d51fd61.8937e30a.096e.0a65@mx.google.com>
Michael Witten <mfwitten@gmail.com> writes:
> Date: Tue, 9 Feb 2011 02:17:47 +0000
> Output looked like this:
WTH?
> Isn't that nice?
Perhaps.
^ permalink raw reply
* Re: [PATCH/RFC] Move test-*.c to test/ subdirectory
From: Junio C Hamano @ 2011-02-09 22:15 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <1297264469-13675-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
I like the idea of moving test-*.c out of the top-level directory, but at
the same time I do not think it is a sane thing to have a new directory
called test/ to have only test helper commandlets.
With both t/ and test/ directories present at the top-level, even people
with Perl background may spot test/ before they notice t/ and expect to
find actual test scripts in test/ directory.
Perhaps move them to t/helper/ directory instead?
^ permalink raw reply
* Re: [PATCH] request-pull: Include newline in output
From: Michael Witten @ 2011-02-09 22:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5bgoow3.fsf@alter.siamese.dyndns.org>
On Wed, 09 Feb 2011 13:54:04 -0800, Junio C Hamano wrote:
> Michael Witten <mfwitten@gmail.com> writes:
>
>> Date: Tue, 9 Feb 2011 02:17:47 +0000
>
> WTH?
Woops! I typed that by hand...
Make that 'Wed'.
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: Junio C Hamano @ 2011-02-09 22:40 UTC (permalink / raw)
To: Jeff King; +Cc: SZEDER Gábor, Matthieu Moy, Sebastian Pipping, Git ML
In-Reply-To: <20110209210312.GB2083@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> The most compelling I have seen is "you tend to notice accidental
> full-tree sooner than accidental relative behavior". Which you mentioned
> in your email.
Hmph. You earlier mentioned "oops, I just pushed this commit and it turns
out that I screwed up "git add" five minutes ago and it only had half of
the files I intended" problem, but "oops, I just pushed this commit and it
turns out that I screwed up "git add" five minutes ago and it had more
changes than I intended" problem would be equally annoying, and I don't
think one is inherently more likely to be noticed than the other; IOW, it
is not compelling, but is just an arbitrary and a biased observation, no?
The most compelling, especially if we _were_ designing from scratch to
make things consistent across the command set, would be "limiting to cwd
with single dot is a lot easier to type than counting ../, using / to mean
the root of the working tree is confusing, and saying --full-tree is
annoying". I fully agree with that.
Can somebody volunteer to come up with a comprehensive list of operations
that will change their behaviour when we switch to "full-tree without
pathspec" semantics? We mentioned "grep" and "add -u" already.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox