Re: [PATCH] git.c: add --index-file command-line option.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 16/12/2012 06:59, Junio C Hamano ha scritto: I Manlio Perillo manlio.peri...@gmail.com writes: This works with a shell. I'm using Python to write a custom git command. I would be very surprised if Python lacked a way to spawn a subprocess with an environment modified from the current process. Of course it is possible, but a command-line option is more convenient, IMHO. Regards Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlDNhGsACgkQscQJ24LbaUQ0dQCglUAw8zwRKNeDUGznfrm1xFKf GQsAnA/ucztku4v9LnIr0Lv/gyl5ULiT =j/1w -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] Port to QNX
Matt Kraai wrote: From: Matt Kraai matt.kr...@amo.abbott.com Signed-off-by: Matt Kraai matt.kr...@amo.abbott.com --- Makefile | 19 +++ git-compat-util.h | 8 ++-- 2 files changed, 25 insertions(+), 2 deletions(-) snip diff --git a/git-compat-util.h b/git-compat-util.h index 2e79b8a..6c588ca 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -75,7 +75,7 @@ # endif #elif !defined(__APPLE__) !defined(__FreeBSD__) !defined(__USLC__) \ !defined(_M_UNIX) !defined(__sgi) !defined(__DragonFly__) \ - !defined(__TANDEM) + !defined(__TANDEM) !defined(__QNX__) #define _XOPEN_SOURCE 600 /* glibc2 and AIX 5.3L need 500, OpenBSD needs 600 for S_ISLNK() */ #define _XOPEN_SOURCE_EXTENDED 1 /* AIX 5.3L needs this */ #endif @@ -99,7 +99,7 @@ #include stdlib.h #include stdarg.h #include string.h -#ifdef __TANDEM /* or HAVE_STRINGS_H or !NO_STRINGS_H? */ +#if defined(__TANDEM) || defined(__QNX__) /* or HAVE_STRINGS_H or !NO_STRINGS_H? */ #include strings.h /* for strcasecmp() */ There's another recent thread, discussing to change this to #ifdef HAVE_STRING_H plus the infrastructure in Makefile and configure.ac. Bye, Jojo -- 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 3/4] cache-tree: fix writing cache-tree when CE_REMOVE is present
On Sun, Dec 16, 2012 at 2:20 PM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
entry_count is used in update_one() for two purposes:
1. to skip through the number of processed entries in in-memory index
2. to record the number of entries this cache-tree covers on disk
Unfortunately when CE_REMOVE is present these numbers are not the same
because CE_REMOVE entries are automatically removed before writing to
disk but entry_count is not adjusted and still counts CE_REMOVE
entries.
Nicely explained. I wonder if we can also add a piece of test to
the patch 4/4 to demonstrate the issue with CE_REMOVE entries,
though.
A hand crafted one, maybe. I did not attempt to recreate it with git
commands (and I don't think we update cache-tree after unpack_trees).
So I wrote something like this instead:
int main(int ac, char **av)
{
unsigned char sha1[20];
setup_git_directory();
read_cache();
active_cache[1]-ce_flags |= CE_REMOVE;
write_cache_as_tree(sha1, 0, NULL);
return 0;
}
I can polish it a bit and write new tests based on it and
test-dump-cache-tree if you want.
--
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 v4 3/4] cache-tree: fix writing cache-tree when CE_REMOVE is present
Nguyen Thai Ngoc Duy pclo...@gmail.com wrote: On Sun, Dec 16, 2012 at 2:20 PM, Junio C Hamano gits...@pobox.com wrote: Nicely explained. I wonder if we can also add a piece of test to the patch 4/4 to demonstrate the issue with CE_REMOVE entries, though. A hand crafted one, maybe. I did not attempt to recreate it with git commands (and I don't think we update cache-tree after unpack_trees). Yeah, that's what I thought. No need to bother creating a bug that won't appear in the real life :-) Tusks for sanity checking. -- Pardon terseness, typo and HTML from a tablet. -- 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] Documentation: don't link to example mail addresses
On Sat, Dec 15, 2012 at 06:24:09PM +, John Keeping wrote: I think I'd just render them monospace everywhere. We are very inconsistent about which form of quotes we use in the documentation (I think because most of the developers read the source directly and not the rendered asciidoc). And then we don't have to worry about the $$ construct (and IMHO it makes the source much more readable, and marking the address as a literal looks good in the output, too). I agree that the source is more readable as monospaced, but I think we need to keep the quotes around the text in git-tag(1) and probably git-fast-import(1) so that it is differentiated from the surrounding text in the man page output. Hmm, good point. I use MAN_BOLD_LITERAL, which serves that purpose, but I guess not everyone does (and it is not the default; I wonder if it should be). But if MAN_BOLD_LITERAL is not in use, then `` literals have zero typographical impact in the manpages. So maybe we do need to do something else. I was just hoping we could get away with something more readable in the source. By my reading of the asciidoc user guide, the mechanism that is hurting us is that mailto is an inline macro, and that foo@bar automatically triggers that inline macro. Furthermore, the right way to suppress expansion of macros is with a backslash escape. Doing this: diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index d1844ea..68bca1a 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -427,7 +427,7 @@ Here `name` is the person's display name (for example Here `name` is the person's display name (for example ``Com M Itter'') and `email` is the person's email address -(``c...@example.com''). `LT` and `GT` are the literal less-than (\x3c) +(``\c...@example.com''). `LT` and `GT` are the literal less-than (\x3c) and greater-than (\x3e) symbols. These are required to delimit the email address from the other fields in the line. Note that `name` and `email` are free-form and may contain any sequence seems to produce the output we want. I think it's a little less ugly than the $$ quoting, but not by much. No clue if one is accepted by more asciidoc versions or not. -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Move api-command.txt to the end of API list in api-index.txt
- because it describes a different form of API than the other api-* documents
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Documentation/technical/api-index.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/technical/api-index.sh
b/Documentation/technical/api-index.sh
index 9c3f413..c2c68ed 100755
--- a/Documentation/technical/api-index.sh
+++ b/Documentation/technical/api-index.sh
@@ -10,12 +10,16 @@
while read filename
do
case $filename in
- api-index-skel.txt | api-index.txt) continue ;;
+ api-index-skel.txt | api-index.txt | api-command.txt) continue
;;
esac
title=$(sed -e 1q $filename)
html=${filename%.txt}.html
echo * link:$html[$title]
done
+ filename=api-command.txt
+ title=$(sed -e 1q $filename)
+ html=${filename%.txt}.html
+ echo * link:$html[$title]
echo $c
sed -n -e '/^\/\/ table of contents end/,$p' $skel
) api-index.txt+
--
1.8.0.msysgit.0
---
Thomas
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] Documentation: don't link to example mail addresses
Email addresses in documentation are converted into mailto: hyperlinks in the HTML output and footnotes in man pages. This isn't desirable for cases where the address is used as an example and is not valid. Particularly annoying is the example jane@laptop.(none) which appears in git-shortlog(1) as jane@laptop[1].(none), with note 1 saying: 1. jane@laptop mailto:jane@laptop Fix this by escaping these email addresses with a leading backslash, to prevent Asciidoc expanding them as inline macros. In the case of mailmap.txt, render the address monospaced so that it matches the block examples surrounding that paragraph. Helped-by: Jeff King p...@peff.net Signed-off-by: John Keeping j...@keeping.me.uk --- On Sun, Dec 16, 2012 at 07:04:05AM -0500, Jeff King wrote: Furthermore, the right way to suppress expansion of macros is with a backslash escape. [snipped an example] I think it's a little less ugly than the $$ quoting, but not by much. No clue if one is accepted by more asciidoc versions or not. From a quick reading of the Asciidoc changelog, I think backslash escaping should be supported just as well as $$ quoting, which leaves the minimal patch looking like this. Documentation/git-fast-import.txt | 2 +- Documentation/git-tag.txt | 2 +- Documentation/mailmap.txt | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index d1844ea..68bca1a 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -427,7 +427,7 @@ they made it. Here `name` is the person's display name (for example ``Com M Itter'') and `email` is the person's email address -(``c...@example.com''). `LT` and `GT` are the literal less-than (\x3c) +(``\c...@example.com''). `LT` and `GT` are the literal less-than (\x3c) and greater-than (\x3e) symbols. These are required to delimit the email address from the other fields in the line. Note that `name` and `email` are free-form and may contain any sequence diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt index 247534e..2f1c0c3 100644 --- a/Documentation/git-tag.txt +++ b/Documentation/git-tag.txt @@ -129,7 +129,7 @@ This option is only applicable when listing tags without annotation lines. CONFIGURATION - By default, 'git tag' in sign-with-default mode (-s) will use your -committer identity (of the form Your Name your@email.address) to +committer identity (of the form Your Name \your@email.address) to find a key. If you want to use a different default key, you can specify it in the repository configuration as follows: diff --git a/Documentation/mailmap.txt b/Documentation/mailmap.txt index 288f04e..dd89fca 100644 --- a/Documentation/mailmap.txt +++ b/Documentation/mailmap.txt @@ -46,7 +46,7 @@ Jane Doe jane@desktop.(none) Joe R. Developer j...@example.com -Note how there is no need for an entry for jane@laptop.(none), because the +Note how there is no need for an entry for `jane@laptop.(none)`, because the real name of that author is already correct. Example 2: Your repository contains commits from the following -- 1.8.0.2 -- 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
Prebuilt man pages on Google code
While investigating Asciidoc's quoting in this thread [1], I noticed that my system man pages don't display Asciidoc double quoted text correctly. [1] http://article.gmane.org/gmane.comp.version-control.git/211533 For example in git-fast-import(1): Here name is the person’s display name (for example `Com M Itter'') and `email is the person’s email address (`c...@example.com''). `LT and GT are the literal less-than (\x3c) and greater-than (\x3e) symbols. It turns out that Gentoo installs the man pages from git-core on Google code, and the error can be seen in the source there [2]. [2] http://code.google.com/p/git-manpages/source/browse/man1/git-fast-import.1#379 When I generate man pages here, I get paired quotes (\u201C and \u201D): Here name is the person’s display name (for example “Com M Itter”) and email is the person’s email address (“c...@example.com”). LT and GT are the literal less-than (\x3c) and greater-than (\x3e) symbol I can't see any configuration option that could cause this difference, so I assume it must be caused by some particular tool version on the machine used to generate these man pages. If the output is a side-effect of avoiding non-ASCII characters, is is useful to do something like this (with appropriate Makefile support)? diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf index 1273a85..6655ec7 100644 --- a/Documentation/asciidoc.conf +++ b/Documentation/asciidoc.conf @@ -89,6 +89,16 @@ template::[header-declarations] endif::backend-docbook[] endif::doctype-manpage[] +ifdef::doctype-manpage[] +ifdef::git-asciidoc-man-ascii[] +[attributes] +lsquo=#39; +rsquo=#39; +ldquo=#34; +rdquo=#34; +endif::git-asciidoc-man-ascii[] +endif::doctype-manpage[] + ifdef::backend-xhtml11[] [attributes] git-relative-html-prefix= -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 2/7] tests: paint known breakages in bold yellow
Bold yellow seems a more appropriate color than bold green when
considering the universal traffic lights coloring scheme, where
green conveys the impression that everything's OK, and amber that
something's not quite right.
Likewise, change the color of the summarized total number of known
breakages from bold red to bold yellow to be less alarmist and more
consistent with the above.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/test-lib.sh | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index d0b236f..710f051 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -213,6 +213,8 @@ then
tput bold; tput setaf 1;; # bold red
skip)
tput bold; tput setaf 2;; # bold green
+ warn)
+ tput bold; tput setaf 3;; # bold brown/yellow
pass)
tput setaf 2;;# green
info)
@@ -311,7 +313,7 @@ test_known_broken_ok_ () {
test_known_broken_failure_ () {
test_broken=$(($test_broken+1))
- say_color skip not ok $test_count - $@ # TODO known breakage
+ say_color warn not ok $test_count - $@ # TODO known breakage
}
test_debug () {
@@ -408,7 +410,7 @@ test_done () {
fi
if test $test_broken != 0
then
- say_color error # still have $test_broken known breakage(s)
+ say_color warn # still have $test_broken known breakage(s)
msg=remaining $(($test_count-$test_broken)) test(s)
else
msg=$test_count test(s)
--
1.7.12.1.396.g53b3ea9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 4/7] tests: change info messages from yellow/brown to bold cyan
Now that we've adopted a traffic lights coloring scheme, yellow is used for warning messages, so we need to re-color info messages to something less alarmist. Blue is a universal color for informational messages; however we are using that for skipped tests in order to align with the color schemes of other test suites. Therefore we use bold cyan which is also blue-ish, but visually distinct from bold blue. This was suggested on the list a while ago and no-one raised any objections: http://thread.gmane.org/gmane.comp.version-control.git/205675/focus=205966 Signed-off-by: Adam Spiers g...@adamspiers.org --- t/test-lib.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/test-lib.sh b/t/test-lib.sh index 220b172..5d9d0fc 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -218,7 +218,7 @@ then pass) tput setaf 2;;# green info) - tput setaf 3;;# brown + tput bold; tput setaf 6;; # bold cyan *) test -n $quiet return;; esac -- 1.7.12.1.396.g53b3ea9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 5/7] tests: refactor mechanics of testing in a sub test-lib
This will allow us to test the test framework more thoroughly
without disrupting the top-level test metrics.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/t-basic.sh | 85 ++--
1 file changed, 40 insertions(+), 45 deletions(-)
diff --git a/t/t-basic.sh b/t/t-basic.sh
index 46ccda3..fc5200f 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -45,39 +45,53 @@ test_expect_failure 'pretend we have a known breakage' '
false
'
-test_expect_success 'pretend we have fixed a known breakage (run in sub
test-lib)'
- mkdir passing-todo
- (cd passing-todo
- cat passing-todo.sh -EOF
- #!$SHELL_PATH
-
- test_description='A passing TODO test
-
- This is run in a sub test-lib so that we do not get incorrect
- passing metrics
- '
-
- # Point to the t/test-lib.sh, which isn't in ../ as usual
- TEST_DIRECTORY=\$TEST_DIRECTORY\
- . \\$TEST_DIRECTORY\/test-lib.sh
+run_sub_test_lib_test () {
+ name=$1 descr=$2 # stdin is the body of the test code
+ mkdir $name
+ (
+ cd $name
+ cat $name.sh -EOF
+ #!$SHELL_PATH
+
+ test_description='$descr (run in sub test-lib)
+
+ This is run in a sub test-lib so that we do not get incorrect
+ passing metrics
+ '
+
+ # Point to the t/test-lib.sh, which isn't in ../ as usual
+ . \$TEST_DIRECTORY/test-lib.sh
+ EOF
+ cat $name.sh
+ chmod +x $name.sh
+ export TEST_DIRECTORY
+ ./$name.sh out 2err
+ )
+}
- test_expect_failure 'pretend we have fixed a known breakage' '
- :
- '
+check_sub_test_lib_test () {
+ name=$1 # stdin is the expected output from the test
+ (
+ cd $name
+ ! test -s err
+ sed -e 's/^ //' -e 's/Z$//' expect
+ test_cmp expect out
+ )
+}
+test_expect_success 'pretend we have fixed a known breakage'
+ run_sub_test_lib_test passing-todo 'A passing TODO test' -\\EOF
+ test_expect_failure 'pretend we have fixed a known breakage' 'true'
test_done
EOF
- chmod +x passing-todo.sh
- ./passing-todo.sh out 2err
- ! test -s err
- sed -e 's/^ //' expect -\\EOF
+ check_sub_test_lib_test passing-todo -\\EOF
ok 1 - pretend we have fixed a known breakage # TODO known breakage
# fixed 1 known breakage(s)
# passed all 1 test(s)
1..1
EOF
- test_cmp expect out)
+
test_set_prereq HAVEIT
haveit=no
test_expect_success HAVEIT 'test runs if prerequisite is satisfied' '
@@ -159,19 +173,8 @@ then
fi
test_expect_success 'tests clean up even on failures'
- mkdir failing-cleanup
- (
- cd failing-cleanup
-
- cat failing-cleanup.sh -EOF
- #!$SHELL_PATH
-
- test_description='Failing tests with cleanup commands'
-
- # Point to the t/test-lib.sh, which isn't in ../ as usual
- TEST_DIRECTORY=\$TEST_DIRECTORY\
- . \\$TEST_DIRECTORY\/test-lib.sh
-
+ test_must_fail run_sub_test_lib_test \
+ failing-cleanup 'Failing tests with cleanup commands' -\\EOF
test_expect_success 'tests clean up even after a failure' '
touch clean-after-failure
test_when_finished rm clean-after-failure
@@ -181,14 +184,8 @@ test_expect_success 'tests clean up even on failures'
test_when_finished \(exit 2)\
'
test_done
-
EOF
-
- chmod +x failing-cleanup.sh
- test_must_fail ./failing-cleanup.sh out 2err
- ! test -s err
- ! test -f \trash directory.failing-cleanup/clean-after-failure\
- sed -e 's/Z$//' -e 's/^ //' expect -\\EOF
+ check_sub_test_lib_test failing-cleanup -\\EOF
not ok 1 - tests clean up even after a failure
# Z
# touch clean-after-failure
@@ -202,8 +199,6 @@ test_expect_success 'tests clean up even on failures'
# failed 2 among 2 test(s)
1..2
EOF
- test_cmp expect out
- )
--
1.7.12.1.396.g53b3ea9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 1/7] tests: test number comes first in 'not ok $count - $message'
The old output to say not ok - 1 messsage was working by accident
only because the test numbers are optional in TAP.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/t-basic.sh | 4 ++--
t/test-lib.sh| 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/t-basic.sh b/t/t-basic.sh
index 562cf41..46ccda3 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -189,13 +189,13 @@ test_expect_success 'tests clean up even on failures'
! test -s err
! test -f \trash directory.failing-cleanup/clean-after-failure\
sed -e 's/Z$//' -e 's/^ //' expect -\\EOF
-not ok - 1 tests clean up even after a failure
+not ok 1 - tests clean up even after a failure
# Z
# touch clean-after-failure
# test_when_finished rm clean-after-failure
# (exit 1)
# Z
-not ok - 2 failure to clean up causes the test to fail
+not ok 2 - failure to clean up causes the test to fail
# Z
# test_when_finished \(exit 2)\
# Z
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f50f834..d0b236f 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -298,7 +298,7 @@ test_ok_ () {
test_failure_ () {
test_failure=$(($test_failure + 1))
- say_color error not ok - $test_count $1
+ say_color error not ok $test_count - $1
shift
echo $@ | sed -e 's/^/# /'
test $immediate = || { GIT_EXIT_OK=t; exit 1; }
--
1.7.12.1.396.g53b3ea9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 3/7] tests: paint skipped tests in bold blue
Skipped tests indicate incomplete test coverage. Whilst this is not a test failure or other error, it's still not a complete success. Other testsuite related software like automake, autotest and prove seem to use blue for skipped tests, so let's follow suit. Signed-off-by: Adam Spiers g...@adamspiers.org --- t/test-lib.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/test-lib.sh b/t/test-lib.sh index 710f051..220b172 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -212,7 +212,7 @@ then error) tput bold; tput setaf 1;; # bold red skip) - tput bold; tput setaf 2;; # bold green + tput bold; tput setaf 4;; # bold blue warn) tput bold; tput setaf 3;; # bold brown/yellow pass) -- 1.7.12.1.396.g53b3ea9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 0/7] make test output coloring more intuitive
This series of commits attempts to make test output coloring more intuitive, so that: - red is only used for things which have gone unexpectedly wrong: test failures, unexpected test passes, and failures with the framework, - yellow is only used for known breakages, - green is only used for things which have gone to plan and require no further work to be done, - blue is only used for skipped tests, and - cyan is used for other informational messages. Since unexpected test passes are no longer treated as passes, the summary lines displayed at the end of a test run have enough different possible outputs to warrant them being covered in the test framework's self-tests. Therefore this series also refactors and extends the self-tests. Adam Spiers (7): tests: test number comes first in 'not ok $count - $message' tests: paint known breakages in bold yellow tests: paint skipped tests in bold blue tests: change info messages from yellow/brown to bold cyan tests: refactor mechanics of testing in a sub test-lib tests: test the test framework more thoroughly tests: paint unexpectedly fixed known breakages in bold red t/t-basic.sh | 211 ++- t/test-lib.sh| 25 --- 2 files changed, 180 insertions(+), 56 deletions(-) -- 1.7.12.1.396.g53b3ea9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v6 6/7] tests: test the test framework more thoroughly
Add 5 new full test suite runs each with a different number of
passing/failing/broken/fixed tests, in order to ensure that the
correct exit code and output are generated in each case. As before,
these are run in a subdirectory to avoid disrupting the metrics for
the parent tests.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/t-basic.sh | 104 +++
1 file changed, 104 insertions(+)
diff --git a/t/t-basic.sh b/t/t-basic.sh
index fc5200f..5c1dde0 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -79,6 +79,55 @@ check_sub_test_lib_test () {
)
}
+test_expect_success 'pretend we have a fully passing test suite'
+ run_sub_test_lib_test full-pass '3 passing tests' -\\EOF
+ for i in 1 2 3; do
+ test_expect_success \passing test #\$i\ 'true'
+ done
+ test_done
+ EOF
+ check_sub_test_lib_test full-pass -\\EOF
+ok 1 - passing test #1
+ok 2 - passing test #2
+ok 3 - passing test #3
+# passed all 3 test(s)
+1..3
+ EOF
+
+
+test_expect_success 'pretend we have a partially passing test suite'
+ test_must_fail run_sub_test_lib_test \
+ partial-pass '2/3 tests passing' -\\EOF
+ test_expect_success 'passing test #1' 'true'
+ test_expect_success 'failing test #2' 'false'
+ test_expect_success 'passing test #3' 'true'
+ test_done
+ EOF
+ check_sub_test_lib_test partial-pass -\\EOF
+ok 1 - passing test #1
+not ok 2 - failing test #2
+ # false
+ok 3 - passing test #3
+# failed 1 among 3 test(s)
+1..3
+ EOF
+
+
+test_expect_success 'pretend we have a known breakage'
+ run_sub_test_lib_test failing-todo 'A failing TODO test' -\\EOF
+ test_expect_success 'passing test' 'true'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_done
+ EOF
+ check_sub_test_lib_test failing-todo -\\EOF
+ok 1 - passing test
+not ok 2 - pretend we have a known breakage # TODO known breakage
+# still have 1 known breakage(s)
+# passed all remaining 1 test(s)
+1..2
+ EOF
+
+
test_expect_success 'pretend we have fixed a known breakage'
run_sub_test_lib_test passing-todo 'A passing TODO test' -\\EOF
test_expect_failure 'pretend we have fixed a known breakage' 'true'
@@ -92,6 +141,61 @@ test_expect_success 'pretend we have fixed a known
breakage'
EOF
+test_expect_success 'pretend we have a pass, fail, and known breakage'
+ test_must_fail run_sub_test_lib_test \
+ mixed-results1 'mixed results #1' -\\EOF
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'failing test' 'false'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_done
+ EOF
+ check_sub_test_lib_test mixed-results1 -\\EOF
+ok 1 - passing test
+not ok 2 - failing test
+# false
+not ok 3 - pretend we have a known breakage # TODO known breakage
+# still have 1 known breakage(s)
+# failed 1 among remaining 2 test(s)
+1..3
+ EOF
+
+
+test_expect_success 'pretend we have a mix of all possible results'
+ test_must_fail run_sub_test_lib_test \
+ mixed-results2 'mixed results #2' -\\EOF
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'passing test' 'true'
+ test_expect_success 'failing test' 'false'
+ test_expect_success 'failing test' 'false'
+ test_expect_success 'failing test' 'false'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_expect_failure 'pretend we have fixed a known breakage' 'true'
+ test_done
+ EOF
+ check_sub_test_lib_test mixed-results2 -\\EOF
+ok 1 - passing test
+ok 2 - passing test
+ok 3 - passing test
+ok 4 - passing test
+not ok 5 - failing test
+# false
+not ok 6 - failing test
+# false
+not ok 7 - failing test
+# false
+not ok 8 - pretend we have a known breakage # TODO known breakage
+not ok 9 - pretend we have a known breakage # TODO known breakage
+ok 10 - pretend we have fixed a known breakage # TODO known breakage
+# fixed 1 known breakage(s)
+# still have 2 known breakage(s)
+# failed 3 among remaining 8 test(s)
+1..10
+ EOF
+
+
test_set_prereq HAVEIT
haveit=no
test_expect_success HAVEIT 'test runs if prerequisite is satisfied' '
--
1.7.12.1.396.g53b3ea9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a
[PATCH v6 7/7] tests: paint unexpectedly fixed known breakages in bold red
Change color of unexpectedly fixed known breakages to bold red. An
unexpectedly passing test indicates that the test code is somehow
broken or out of sync with the code it is testing. Either way this is
an error which is potentially as bad as a failing test, and as such is
no longer portrayed as a pass in the output.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
t/t-basic.sh | 30 --
t/test-lib.sh| 13 +
2 files changed, 33 insertions(+), 10 deletions(-)
diff --git a/t/t-basic.sh b/t/t-basic.sh
index 5c1dde0..bd6127f 100755
--- a/t/t-basic.sh
+++ b/t/t-basic.sh
@@ -134,13 +134,31 @@ test_expect_success 'pretend we have fixed a known
breakage'
test_done
EOF
check_sub_test_lib_test passing-todo -\\EOF
-ok 1 - pretend we have fixed a known breakage # TODO known breakage
-# fixed 1 known breakage(s)
-# passed all 1 test(s)
+ok 1 - pretend we have fixed a known breakage # TODO known breakage
vanished
+# 1 known breakage(s) vanished; please update test(s)
1..1
EOF
+test_expect_success 'pretend we have fixed one of two known breakages (run in
sub test-lib)'
+ run_sub_test_lib_test partially-passing-todos \
+ '2 TODO tests, one passing' -\\EOF
+ test_expect_failure 'pretend we have a known breakage' 'false'
+ test_expect_success 'pretend we have a passing test' 'true'
+ test_expect_failure 'pretend we have fixed another known breakage'
'true'
+ test_done
+ EOF
+ check_sub_test_lib_test partially-passing-todos -\\EOF
+not ok 1 - pretend we have a known breakage # TODO known breakage
+ok 2 - pretend we have a passing test
+ok 3 - pretend we have fixed another known breakage # TODO known
breakage vanished
+# 1 known breakage(s) vanished; please update test(s)
+# still have 1 known breakage(s)
+# passed all remaining 1 test(s)
+1..3
+ EOF
+
+
test_expect_success 'pretend we have a pass, fail, and known breakage'
test_must_fail run_sub_test_lib_test \
mixed-results1 'mixed results #1' -\\EOF
@@ -188,10 +206,10 @@ test_expect_success 'pretend we have a mix of all
possible results'
# false
not ok 8 - pretend we have a known breakage # TODO known breakage
not ok 9 - pretend we have a known breakage # TODO known breakage
-ok 10 - pretend we have fixed a known breakage # TODO known breakage
-# fixed 1 known breakage(s)
+ok 10 - pretend we have fixed a known breakage # TODO known breakage
vanished
+# 1 known breakage(s) vanished; please update test(s)
# still have 2 known breakage(s)
-# failed 3 among remaining 8 test(s)
+# failed 3 among remaining 7 test(s)
1..10
EOF
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 5d9d0fc..b1acdfc 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -308,7 +308,7 @@ test_failure_ () {
test_known_broken_ok_ () {
test_fixed=$(($test_fixed+1))
- say_color ok $test_count - $@ # TODO known breakage
+ say_color error ok $test_count - $@ # TODO known breakage vanished
}
test_known_broken_failure_ () {
@@ -406,13 +406,18 @@ test_done () {
if test $test_fixed != 0
then
- say_color pass # fixed $test_fixed known breakage(s)
+ say_color error # $test_fixed known breakage(s) vanished;
please update test(s)
fi
if test $test_broken != 0
then
say_color warn # still have $test_broken known breakage(s)
- msg=remaining $(($test_count-$test_broken)) test(s)
+ fi
+ if test $test_broken != 0 || test $test_fixed != 0
+ then
+ test_remaining=$(( $test_count - $test_broken - $test_fixed ))
+ msg=remaining $test_remaining test(s)
else
+ test_remaining=$test_count
msg=$test_count test(s)
fi
case $test_failure in
@@ -426,7 +431,7 @@ test_done () {
if test $test_external_has_tap -eq 0
then
- if test $test_count -gt 0
+ if test $test_remaining -gt 0
then
say_color pass # passed all $msg
fi
--
1.7.12.1.396.g53b3ea9
--
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] Documentation: don't link to example mail addresses
John Keeping j...@keeping.me.uk writes: Email addresses in documentation are converted into mailto: hyperlinks in the HTML output and footnotes in man pages. This isn't desirable for cases where the address is used as an example and is not valid. Particularly annoying is the example jane@laptop.(none) which appears in git-shortlog(1) as jane@laptop[1].(none), with note 1 saying: 1. jane@laptop mailto:jane@laptop Fix this by escaping these email addresses with a leading backslash, to prevent Asciidoc expanding them as inline macros. In the case of mailmap.txt, render the address monospaced so that it matches the block examples surrounding that paragraph. Helped-by: Jeff King p...@peff.net Signed-off-by: John Keeping j...@keeping.me.uk --- On Sun, Dec 16, 2012 at 07:04:05AM -0500, Jeff King wrote: Furthermore, the right way to suppress expansion of macros is with a backslash escape. [snipped an example] I think it's a little less ugly than the $$ quoting, but not by much. No clue if one is accepted by more asciidoc versions or not. From a quick reading of the Asciidoc changelog, I think backslash escaping should be supported just as well as $$ quoting, which leaves the minimal patch looking like this. The patch looks reasonable to me, too. We were bitten by relying on the description in AsciiDoc documentation (which shows the state of their latest software) before; between the constructs that work, it is safer to use the older, more vanilla and more common one. 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 v6 0/7] make test output coloring more intuitive
Adam Spiers g...@adamspiers.org writes: This series of commits attempts to make test output coloring more intuitive,... Thanks; I understand that this is to replace the previous one b465316 (tests: paint unexpectedly fixed known breakages in bold red, 2012-09-19)---am I correct? - red is only used for things which have gone unexpectedly wrong: test failures, unexpected test passes, and failures with the framework, - yellow is only used for known breakages, - green is only used for things which have gone to plan and require no further work to be done, - blue is only used for skipped tests, and - cyan is used for other informational messages. OK. Since unexpected test passes are no longer treated as passes, the summary lines displayed at the end of a test run have enough different possible outputs to warrant them being covered in the test framework's self-tests. Therefore this series also refactors and extends the self-tests. Adam Spiers (7): tests: test number comes first in 'not ok $count - $message' tests: paint known breakages in bold yellow tests: paint skipped tests in bold blue tests: change info messages from yellow/brown to bold cyan tests: refactor mechanics of testing in a sub test-lib tests: test the test framework more thoroughly tests: paint unexpectedly fixed known breakages in bold red t/t-basic.sh | 211 ++- t/test-lib.sh| 25 --- 2 files changed, 180 insertions(+), 56 deletions(-) Will take a look; 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 v6 0/7] make test output coloring more intuitive
On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano gits...@pobox.com wrote: Adam Spiers g...@adamspiers.org writes: This series of commits attempts to make test output coloring more intuitive,... Thanks; I understand that this is to replace the previous one b465316 (tests: paint unexpectedly fixed known breakages in bold red, 2012-09-19)---am I correct? Correct. AFAICS I have incorporated all feedback raised in previous reviews. Will take a look; thanks. Thanks. Sorry again for the delay. I'm now (finally) resuming work on as/check-ignore. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] SubmittingPatches: add convention of prefixing commit messages
Conscientious newcomers to git development will read SubmittingPatches and CodingGuidelines, but could easily miss the convention of prefixing commit messages with a single word identifying the file or area the commit touches. Signed-off-by: Adam Spiers g...@adamspiers.org --- Documentation/SubmittingPatches | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 0dbf2c9..c107cb1 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -9,6 +9,14 @@ Checklist (and a short version for the impatient): - the first line of the commit message should be a short description (50 characters is the soft limit, see DISCUSSION in git-commit(1)), and should skip the full stop + - it is also conventional in most cases to prefix the + first line with area: where the area is a filename + or identifier for the general area of the code being + modified, e.g. + . archive: ustar header checksum is computed unsigned + . git-cherry-pick.txt: clarify the use of revision range notation + (if in doubt which identifier to use, run git log --no-merges + on the files you are modifying to see the current conventions) - the body should provide a meaningful commit message, which: . explains the problem the change tries to solve, iow, what is wrong with the current code without the change. -- 1.7.12.1.396.g53b3ea9 -- 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 0/3] Help newbie git developers avoid obvious pitfalls
I fell into various newbie pitfalls when submitting my first patches to git, despite my best attempts to adhere to documented guidelines. This small patch series attempts to reduce the chances of other developers making the same mistakes I did. Adam Spiers (3): SubmittingPatches: add convention of prefixing commit messages Documentation: move support for old compilers to CodingGuidelines Makefile: use -Wdeclaration-after-statement if supported Documentation/CodingGuidelines | 8 Documentation/SubmittingPatches | 21 - Makefile| 7 ++- 3 files changed, 22 insertions(+), 14 deletions(-) -- 1.7.12.1.396.g53b3ea9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] Makefile: use -Wdeclaration-after-statement if supported
CodingGuidelines requests that code should be nice to older C compilers.
Since modern gcc can warn on code written using newer dialects such as C99,
it makes sense to take advantage of this by auto-detecting this capability
and enabling it when found.
Signed-off-by: Adam Spiers g...@adamspiers.org
---
If we adopt this approach, it may make sense to enable other flags
where available (e.g. -Wzero-as-null-pointer-constant, maybe even
-ansi). In that case, something like this might be a more efficient
way of writing it:
GCC_FLAGS=-Wdeclaration-after-statement,-Wanother-flag,-Wand-another
GCC_FLAGS_REGEXP=$(shell echo $(GCC_FLAGS) | sed 's/,/\\|/g')
GCC_SUPPORTED_FLAGS=$(shell cc --help -v 21 | \
sed -n '/.* \($(GCC_FLAGS_REGEXP)\) .*/{s//\1/;p}')
Makefile | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a49d1db..aae70d4 100644
--- a/Makefile
+++ b/Makefile
@@ -331,8 +331,13 @@ endif
# CFLAGS and LDFLAGS are for the users to override from the command line.
CFLAGS = -g -O2 -Wall
+GCC_DECL_AFTER_STATEMENT = \
+ $(shell $(CC) --help -v 21 | \
+ grep -q -- -Wdeclaration-after-statement \
+ echo -Wdeclaration-after-statement)
+GCC_FLAGS = $(GCC_DECL_AFTER_STATEMENT)
+ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) $(GCC_FLAGS)
LDFLAGS =
-ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
ALL_LDFLAGS = $(LDFLAGS)
STRIP ?= strip
--
1.7.12.1.396.g53b3ea9
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] Documentation: move support for old compilers to CodingGuidelines
The Try to be nice to older C compilers text is clearly a guideline to be borne in mind whilst coding rather than when submitting patches. Signed-off-by: Adam Spiers g...@adamspiers.org --- Documentation/CodingGuidelines | 8 Documentation/SubmittingPatches | 13 - 2 files changed, 8 insertions(+), 13 deletions(-) diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines index 57da6aa..69f7e9b 100644 --- a/Documentation/CodingGuidelines +++ b/Documentation/CodingGuidelines @@ -112,6 +112,14 @@ For C programs: - We try to keep to at most 80 characters per line. + - We try to support a wide range of C compilers to compile git with, + including old ones. That means that you should not use C99 + initializers, even if a lot of compilers grok it. + + - Variables have to be declared at the beginning of the block. + + - NULL pointers shall be written as NULL, not as 0. + - When declaring pointers, the star sides with the variable name, i.e. char *string, not char* string or char * string. This makes it easier to understand code diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index c107cb1..c34c9d1 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -127,19 +127,6 @@ in templates/hooks--pre-commit. To help ensure this does not happen, run git diff --check on your changes before you commit. -(1a) Try to be nice to older C compilers - -We try to support a wide range of C compilers to compile -git with. That means that you should not use C99 initializers, even -if a lot of compilers grok it. - -Also, variables have to be declared at the beginning of the block -(you can check this with gcc, using the -Wdeclaration-after-statement -option). - -Another thing: NULL pointers shall be written as NULL, not as 0. - - (2) Generate your patch using git tools out of your commits. git based diff tools generate unidiff which is the preferred format. -- 1.7.12.1.396.g53b3ea9 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] Makefile: remove tracking of TCLTK_PATH
It looks like we are tracking the value of TCLTK_PATH in the main Makefile for no good reason, as this is done in git-gui too and the GIT-GUI-VARS is not used in the Makefile. This patch removes the useless code used to do this tracking. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- .gitignore | 1 - Makefile | 14 +- 2 files changed, 1 insertion(+), 14 deletions(-) diff --git a/.gitignore b/.gitignore index f702415..6d69ae1 100644 --- a/.gitignore +++ b/.gitignore @@ -1,7 +1,6 @@ /GIT-BUILD-OPTIONS /GIT-CFLAGS /GIT-LDFLAGS -/GIT-GUI-VARS /GIT-PREFIX /GIT-SCRIPT-DEFINES /GIT-USER-AGENT diff --git a/Makefile b/Makefile index 4ad6fbd..585b2eb 100644 --- a/Makefile +++ b/Makefile @@ -2624,18 +2624,6 @@ ifdef GIT_PERF_MAKE_OPTS @echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' $@ endif -### Detect Tck/Tk interpreter path changes -ifndef NO_TCLTK -TRACK_VARS = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)') - -GIT-GUI-VARS: FORCE - @VARS='$(TRACK_VARS)'; \ - if test x$$VARS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new Tcl/Tk interpreter location; \ - echo $$VARS $@; \ -fi -endif - test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X)) all:: $(TEST_PROGRAMS) $(test_bindir_programs) @@ -2910,7 +2898,7 @@ ifndef NO_TCLTK $(MAKE) -C gitk-git clean $(MAKE) -C git-gui clean endif - $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS + $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES .PHONY: all install profile-clean clean strip -- 1.8.1.rc1.2.g8740035 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] Makefile: detect when PYTHON_PATH changes
When make is run, the python scripts are created from *.py files that are changed to use the python given by PYTHON_PATH. And PYTHON_PATH is set by default to /usr/bin/python on Linux. This is nice except when you run make another time setting a different PYTHON_PATH, because, as the python scripts have already been created, make finds nothing to do. The goal of this patch is to detect when the PYTHON_PATH changes and to create the python scripts again when this happens. To do that we use the same trick that is done to track other variables like prefix, flags, tcl/tk path and shell path. We update a GIT-PYTHON-VARS file with the PYTHON_PATH and check if it changed. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- .gitignore | 1 + Makefile | 16 ++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index 6d69ae1..086c5af 100644 --- a/.gitignore +++ b/.gitignore @@ -2,6 +2,7 @@ /GIT-CFLAGS /GIT-LDFLAGS /GIT-PREFIX +/GIT-PYTHON-VARS /GIT-SCRIPT-DEFINES /GIT-USER-AGENT /GIT-VERSION-FILE diff --git a/Makefile b/Makefile index 585b2eb..7db8445 100644 --- a/Makefile +++ b/Makefile @@ -2245,7 +2245,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh endif # NO_PERL ifndef NO_PYTHON -$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX +$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX GIT-PYTHON-VARS $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py $(QUIET_GEN)$(RM) $@ $@+ \ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_helpers -s \ @@ -2624,6 +2624,18 @@ ifdef GIT_PERF_MAKE_OPTS @echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' $@ endif +### Detect Python interpreter path changes +ifndef NO_PYTHON +TRACK_PYTHON = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)') + +GIT-PYTHON-VARS: FORCE + @VARS='$(TRACK_PYTHON)'; \ + if test x$$VARS != x`cat $@ 2/dev/null` ; then \ + echo 12 * new Python interpreter location; \ + echo $$VARS $@; \ +fi +endif + test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X)) all:: $(TEST_PROGRAMS) $(test_bindir_programs) @@ -2899,7 +2911,7 @@ ifndef NO_TCLTK $(MAKE) -C git-gui clean endif $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS - $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES + $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES GIT-PYTHON-VARS .PHONY: all install profile-clean clean strip .PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell -- 1.8.1.rc1.2.g8740035 -- 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] Remove misleading date form api-index-skel.txt
Andreas Schwab sch...@linux-m68k.org writes: s/form/from/ Andreas. Thanks; will apply. -- 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] Move api-command.txt to the end of API list in api-index.txt
Thomas Ackermann th.ac...@arcor.de writes:
- because it describes a different form of API than the other api-* documents
Drop that - ; it is not like you are enumerating many reasons.
It makes me wonder if a more correct fix is to move this document
to the ../howto/ hierarchy.
Signed-off-by: Thomas Ackermann th.ac...@arcor.de
---
Documentation/technical/api-index.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/technical/api-index.sh
b/Documentation/technical/api-index.sh
index 9c3f413..c2c68ed 100755
--- a/Documentation/technical/api-index.sh
+++ b/Documentation/technical/api-index.sh
@@ -10,12 +10,16 @@
while read filename
do
case $filename in
- api-index-skel.txt | api-index.txt) continue ;;
+ api-index-skel.txt | api-index.txt | api-command.txt) continue
;;
esac
title=$(sed -e 1q $filename)
html=${filename%.txt}.html
echo * link:$html[$title]
done
+ filename=api-command.txt
+ title=$(sed -e 1q $filename)
+ html=${filename%.txt}.html
+ echo * link:$html[$title]
echo $c
sed -n -e '/^\/\/ table of contents end/,$p' $skel
) api-index.txt+
--
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] git-completion.bash: add support for path completion
The git-completion.bash script did not implemented full support for
completion, for git commands that operate on files from the current
working directory or the index.
For these commands, only options completion was available.
Full support for completion is now implemented, for git commands where
the non-option arguments always refer to paths on the current working
directory or the index, as the follow:
* the path completion for the git mv and git rm commands is provided
using git ls-files --exclude-standard
* the path completion for the git add command is provided using
git ls-files --exclude-standard -o -m
* the path completion for the git clean command is provided using
git ls-files --exclude-standard -o
* the path completion for the git commit command is provides using
git diff-index --name-only HEAD
Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
contrib/completion/git-completion.bash | 39 ++
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0b77eb1..8b348c3 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -233,6 +233,25 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
}
+__git_files ()
+{
+ local dir=$(__gitdir)
+ if [ -d $dir ]; then
+ git --git-dir=$dir ls-files --exclude-standard $*
+ return
+ fi
+}
+
+# Return all staged files with modification from current HEAD
+__git_commit_files ()
+{
+ local dir=$(__gitdir)
+ if [ -d $dir ]; then
+ git --git-dir=$dir diff-index --name-only HEAD
+ return
+ fi
+}
+
__git_heads ()
{
local dir=$(__gitdir)
@@ -770,8 +789,6 @@ _git_apply ()
_git_add ()
{
- __git_has_doubledash return
-
case $cur in
--*)
__gitcomp
@@ -780,7 +797,8 @@ _git_add ()
return
esac
- COMPREPLY=()
+ # XXX should we care for --update and --all options ?
+ __gitcomp_nl $(__git_files -o -m) $cur
}
_git_archive ()
@@ -930,15 +948,14 @@ _git_cherry_pick ()
_git_clean ()
{
- __git_has_doubledash return
-
case $cur in
--*)
__gitcomp --dry-run --quiet
return
;;
esac
- COMPREPLY=()
+ # TODO: check for -x option
+ __gitcomp_nl $(__git_files -o) $cur
}
_git_clone ()
@@ -969,8 +986,6 @@ _git_clone ()
_git_commit ()
{
- __git_has_doubledash return
-
case $cur in
--cleanup=*)
__gitcomp default strip verbatim whitespace
@@ -998,7 +1013,7 @@ _git_commit ()
return
esac
- COMPREPLY=()
+ __gitcomp_nl $(__git_commit_files) $cur
}
_git_describe ()
@@ -1362,7 +1377,7 @@ _git_mv ()
return
;;
esac
- COMPREPLY=()
+ __gitcomp_nl $(__git_files) $cur
}
_git_name_rev ()
@@ -2068,15 +2083,13 @@ _git_revert ()
_git_rm ()
{
- __git_has_doubledash return
-
case $cur in
--*)
__gitcomp --cached --dry-run --ignore-unmatch --quiet
return
;;
esac
- COMPREPLY=()
+ __gitcomp_nl $(__git_files) $cur
}
_git_shortlog ()
--
1.8.1.rc1.18.g9db0d25
--
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] git-completion.bash: update obsolete code.
The git-completion.bash script was using the git ls-tree command
without the --name-only option, with a sed filter to parse path names;
use the --name-only option, instead.
Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
contrib/completion/git-completion.bash | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0b77eb1..85d9051 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -397,20 +397,7 @@ __git_complete_revlist_file ()
*) pfx=$ref:$pfx ;;
esac
- __gitcomp_nl $(git --git-dir=$(__gitdir) ls-tree $ls \
- | sed '/^100... blob /{
- s,^.*,,
- s,$, ,
- }
- /^12 blob /{
- s,^.*,,
- s,$, ,
- }
- /^04 tree /{
- s,^.*,,
- s,$,/,
- }
- s/^.*//') \
+ __gitcomp_nl $(git --git-dir=$(__gitdir) ls-tree --name-only
$ls) \
$pfx $cur_
;;
*...*)
--
1.8.1.rc1.18.g9db0d25
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] git-completion.bash: add support for path completion
The git-completion.bash script did not implemented full support for
completion, for git commands that operate on files from the current
working directory or the index.
For these commands, only options completion was available.
Full support for completion is now implemented, for git commands where
the non-option arguments always refer to paths on the current working
directory or the index, as the follow:
* the path completion for the git mv and git rm commands is provided
using git ls-files --exclude-standard
* the path completion for the git add command is provided using
git ls-files --exclude-standard -o -m
* the path completion for the git clean command is provided using
git ls-files --exclude-standard -o
* the path completion for the git commit command is provides using
git diff-index --name-only HEAD
Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
Updated the script documentation.
contrib/completion/git-completion.bash | 40 +++---
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0b77eb1..3bd7fc8 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -13,6 +13,7 @@
#*) .git/remotes file names
#*) git 'subcommands'
#*) tree paths within 'ref:path/to/file' expressions
+#*) working directory and index file names
#*) common --long-options
#
# To use these routines:
@@ -233,6 +234,25 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
}
+__git_files ()
+{
+ local dir=$(__gitdir)
+ if [ -d $dir ]; then
+ git --git-dir=$dir ls-files --exclude-standard $*
+ return
+ fi
+}
+
+# Return all staged files with modification from current HEAD
+__git_commit_files ()
+{
+ local dir=$(__gitdir)
+ if [ -d $dir ]; then
+ git --git-dir=$dir diff-index --name-only HEAD
+ return
+ fi
+}
+
__git_heads ()
{
local dir=$(__gitdir)
@@ -770,8 +790,6 @@ _git_apply ()
_git_add ()
{
- __git_has_doubledash return
-
case $cur in
--*)
__gitcomp
@@ -780,7 +798,8 @@ _git_add ()
return
esac
- COMPREPLY=()
+ # XXX should we care for --update and --all options ?
+ __gitcomp_nl $(__git_files -o -m) $cur
}
_git_archive ()
@@ -930,15 +949,14 @@ _git_cherry_pick ()
_git_clean ()
{
- __git_has_doubledash return
-
case $cur in
--*)
__gitcomp --dry-run --quiet
return
;;
esac
- COMPREPLY=()
+ # TODO: check for -x option
+ __gitcomp_nl $(__git_files -o) $cur
}
_git_clone ()
@@ -969,8 +987,6 @@ _git_clone ()
_git_commit ()
{
- __git_has_doubledash return
-
case $cur in
--cleanup=*)
__gitcomp default strip verbatim whitespace
@@ -998,7 +1014,7 @@ _git_commit ()
return
esac
- COMPREPLY=()
+ __gitcomp_nl $(__git_commit_files) $cur
}
_git_describe ()
@@ -1362,7 +1378,7 @@ _git_mv ()
return
;;
esac
- COMPREPLY=()
+ __gitcomp_nl $(__git_files) $cur
}
_git_name_rev ()
@@ -2068,15 +2084,13 @@ _git_revert ()
_git_rm ()
{
- __git_has_doubledash return
-
case $cur in
--*)
__gitcomp --cached --dry-run --ignore-unmatch --quiet
return
;;
esac
- COMPREPLY=()
+ __gitcomp_nl $(__git_files) $cur
}
_git_shortlog ()
--
1.8.1.rc1.18.g9db0d25
--
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
compiler checks
On Fri, Sep 21, 2012 at 12:00:55PM -0700, Junio C Hamano wrote: Adam Spiers g...@adamspiers.org writes: It has been rebased on the latest master, and passed a full test run. FYI, I applied the attached on top before queuing it in 'pu'. Points to note: * We match the underline and the title of documentation header; * a few type mismatches (constness of full_path and treat_gitlink() signature) that broke compilation; Of course I will incorporate these tweaks in my re-roll, but it worries me that my environment yielded no compilation issues even without these tweaks. Obviously I wouldn't have dreamed of submitting a patch series which didn't even compile! I'm using a modern gcc, and I guess you probably are too? Which would suggest to me that either your environment is somehow set up to perform stricter type checking than mine[1], or that there's a weird compiler-oriented bug somewhere (e.g. in Makefile). Or maybe I'm missing something obvious ... [1] I'm in favour of stricter compiler checks where possible: http://article.gmane.org/gmane.comp.version-control.git/211607 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v6 0/7] make test output coloring more intuitive
Adam Spiers g...@adamspiers.org writes: On Sun, Dec 16, 2012 at 6:54 PM, Junio C Hamano gits...@pobox.com wrote: Adam Spiers g...@adamspiers.org writes: This series of commits attempts to make test output coloring more intuitive,... Thanks; I understand that this is to replace the previous one b465316 (tests: paint unexpectedly fixed known breakages in bold red, 2012-09-19)---am I correct? Correct. AFAICS I have incorporated all feedback raised in previous reviews. Seemed clean from a cursory look. Will replace. 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 1/3] SubmittingPatches: add convention of prefixing commit messages
Adam Spiers g...@adamspiers.org writes: Conscientious newcomers to git development will read SubmittingPatches and CodingGuidelines, but could easily miss the convention of prefixing commit messages with a single word identifying the file or area the commit touches. Signed-off-by: Adam Spiers g...@adamspiers.org --- Documentation/SubmittingPatches | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 0dbf2c9..c107cb1 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -9,6 +9,14 @@ Checklist (and a short version for the impatient): - the first line of the commit message should be a short description (50 characters is the soft limit, see DISCUSSION in git-commit(1)), and should skip the full stop + - it is also conventional in most cases to prefix the + first line with area: where the area is a filename + or identifier for the general area of the code being + modified, e.g. + . archive: ustar header checksum is computed unsigned + . git-cherry-pick.txt: clarify the use of revision range notation + (if in doubt which identifier to use, run git log --no-merges + on the files you are modifying to see the current conventions) Thanks; I have to wonder if these details should be left in the longer version to keep the short one short, though. We should probably add learn from good examples. (aka read 'git log' output and the pattern should be obvious to you) as the first item to this list, too. - the body should provide a meaningful commit message, which: . explains the problem the change tries to solve, iow, what is wrong with the current code without the change. -- 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 12/12] Add git-check-ignore sub-command
On Tue, Oct 16, 2012 at 09:12:58AM -0700, Junio C Hamano wrote: Adam Spiers g...@adamspiers.org writes: On Mon, Oct 15, 2012 at 3:31 PM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: +For each pathname given via the command-line or from a file via +`--stdin`, this command will list the first exclude pattern found (if +any) which explicitly excludes or includes that pathname. Note that +within any given exclude file, later patterns take precedence over +earlier ones, so any matching pattern which this command outputs may +not be the one you would immediately expect. The first exclude pattern is very misleading, isn't it? I don't think so, because of the second sentence. For example, with these in $GIT_DIR/info/exclude, I would get: $ cat -n .git/info/exclude 1 *~ 2 Makefile~ $ git check-ignore -v Makefile~ .git/info/exclude:2:Makefile~ Makefile~ which is the correct result (the last one in a single source decides the fate of the path), but it hardly is first one found and the matching pattern in the output would not be something unexpected for the users, either. The reason it is the first one found is because the implementation arranges the loop in such a way that it can stop early when it finds a match---it simply checks matches from the end of the source. But that is not visible to end-users, Correct; that's precisely why I wrote the second sentence which explicitly explains this. and they will find the above description just wrong, no? It's not wrong AFAICS, but suggestions for rewording this more clearly are of course welcome. Maybe s/immediately/intuitively/ ? I think this is sufficient: For each pathname given via the command-line or from a file via `--stdin`, show the pattern from .gitignore (or other input files to the exclude mechanism) that decides if the pathname is excluded. and without Note that at all. I don't think this is quite sufficient. Firstly, it does not cover negated patterns (my original text contained or includes). Secondly, I think there is still potential for this rewording to result in confused users. If the backwards-ness of the internal algorithm is kept hidden from them, then in your example above, most users would be more likely to intuitively expect check-ignore to return the first line of .git/info/exclude (*~). When they saw it returning the second, they might draw the conclusion that the first line failed to match (e.g. by mistakenly thinking that the file format requires regular expressions rather than globs), rather than that git starts at the end of the file. This is precisely why I chose not to hide this aspect of the implementation when initially writing this documentation. Unfortunately my wording managed to confuse several of you, so clearly it was not adequate. Therefore I propose an extension of your version: For each pathname given via the command-line or from a file via `--stdin`, show the pattern from .gitignore (or other input files to the exclude mechanism) that decides if the pathname is excluded or included. Later patterns within a file take precedence over earlier ones. -- 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
$PATH pollution and t9902-completion.sh
t/t9902-completion.sh is currently failing for me because I happen to have a custom shell-script called git-check-email in ~/bin, which is on my $PATH. This is different to a similar-looking case reported recently, which was due to an unclean working tree: http://thread.gmane.org/gmane.comp.version-control.git/208085 It's not unthinkable that in the future other tests could break for similar reasons. Therefore it would be good to sanitize $PATH in the test framework so that it cannot destabilize tests, although I am struggling to think of a good way of doing this. Naively stripping directories under $HOME would not protect against git plugins such as the above being installed into places like /usr/bin. Thoughts? -- 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/3] Makefile: use -Wdeclaration-after-statement if supported
Adam Spiers g...@adamspiers.org writes: If we adopt this approach,... diff --git a/Makefile b/Makefile index a49d1db..aae70d4 100644 --- a/Makefile +++ b/Makefile @@ -331,8 +331,13 @@ endif # CFLAGS and LDFLAGS are for the users to override from the command line. CFLAGS = -g -O2 -Wall +GCC_DECL_AFTER_STATEMENT = \ + $(shell $(CC) --help -v 21 | \ + grep -q -- -Wdeclaration-after-statement \ + echo -Wdeclaration-after-statement) +GCC_FLAGS = $(GCC_DECL_AFTER_STATEMENT) +ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) $(GCC_FLAGS) LDFLAGS = -ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) ALL_LDFLAGS = $(LDFLAGS) Please do not do this. People cannot disable it from the command line, like: $ make V=1 CFLAGS='-g -O0 -Wall' If anything, this should be part of the default CFLAGS. More importantly, this will run the $(shell ...) struct once for every *.o file we produce, I think, in addition to running it twice for the whole build. If you add this: @@ -345,7 +345,8 @@ CFLAGS = -g -O2 -Wall GCC_DECL_AFTER_STATEMENT = \ $(shell $(CC) --help -v 21 | \ grep -q -- -Wdeclaration-after-statement \ - echo -Wdeclaration-after-statement) + echo -Wdeclaration-after-statement; \ + echo 2 GCC_DECL_AFTER_STATEMENT CRUFT) GCC_FLAGS = $(GCC_DECL_AFTER_STATEMENT) ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) $(GCC_FLAGS) LDFLAGS = remove git.o and dir.o from a fully built tree, and then try to rebuild these two files, you will get this: $ make V=1 git.o dir.o GCC_DECL_AFTER_STATEMENT CRUFT GCC_DECL_AFTER_STATEMENT CRUFT GCC_DECL_AFTER_STATEMENT CRUFT cc -o git.o -c -MF ./.depend/git.o.d -MMD -MP -g -O2 -Wall \ -Wdeclaration-after-statement -I. -DHAVE_PATHS_H -DHAVE_DEV_TTY \ -DXDL_FAST_HASH -DSHA1_HEADER='openssl/sha.h' -DNO_STRLCPY \ -DNO_MKSTEMPS -DSHELL_PATH='/bin/sh' \ '-DGIT_HTML_PATH=share/doc/git-doc' '-DGIT_MAN_PATH=share/man' \ '-DGIT_INFO_PATH=share/info' git.c GCC_DECL_AFTER_STATEMENT CRUFT cc -o dir.o -c -MF ./.depend/dir.o.d -MMD -MP -g -O2 -Wall \ -Wdeclaration-after-statement -I. -DHAVE_PATHS_H -DHAVE_DEV_TTY \ -DXDL_FAST_HASH -DSHA1_HEADER='openssl/sha.h' -DNO_STRLCPY \ -DNO_MKSTEMPS -DSHELL_PATH='/bin/sh' dir.c $ make V=1 git.o dir.o GCC_DECL_AFTER_STATEMENT CRUFT GCC_DECL_AFTER_STATEMENT CRUFT make: `dir.o' is up to date. -- 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/3] Makefile: use -Wdeclaration-after-statement if supported
On Sun, Dec 16, 2012 at 05:52:05PM -0800, Junio C Hamano wrote: Adam Spiers g...@adamspiers.org writes: If we adopt this approach,... diff --git a/Makefile b/Makefile index a49d1db..aae70d4 100644 --- a/Makefile +++ b/Makefile @@ -331,8 +331,13 @@ endif # CFLAGS and LDFLAGS are for the users to override from the command line. CFLAGS = -g -O2 -Wall +GCC_DECL_AFTER_STATEMENT = \ + $(shell $(CC) --help -v 21 | \ + grep -q -- -Wdeclaration-after-statement \ + echo -Wdeclaration-after-statement) +GCC_FLAGS = $(GCC_DECL_AFTER_STATEMENT) +ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) $(GCC_FLAGS) LDFLAGS = -ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS) ALL_LDFLAGS = $(LDFLAGS) Please do not do this. People cannot disable it from the command line, like: $ make V=1 CFLAGS='-g -O0 -Wall' If anything, this should be part of the default CFLAGS. More importantly, this will run the $(shell ...) struct once for every *.o file we produce, I think, in addition to running it twice for the whole build. [snipped] OK; I expect these issues with the implementation are all surmountable. I did not necessarily expect this to be the final implementation anyhow, as indicated by my comments below the divider line. However it's not clear to me what you think about the idea in principle, and whether other compiler flags would merit inclusion. (And also, please don't let this discussion hold up acceptance of the two prior patches in the series. Even though they are independent, they are somewhat logically related so I grouped them into the same series, although I'm not sure if that was the right thing to do.) -- 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] Documentation: don't link to example mail addresses
John Keeping j...@keeping.me.uk writes: diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index d1844ea..68bca1a 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -427,7 +427,7 @@ they made it. Here `name` is the person's display name (for example ``Com M Itter'') and `email` is the person's email address -(``c...@example.com''). `LT` and `GT` are the literal less-than (\x3c) +(``\c...@example.com''). `LT` and `GT` are the literal less-than (\x3c) I seem to be getting (tt`\c...@example.com''). `LT/tt and ttGT/tt are the literal less-than (\x3c) out of this part in the resulting HTML output, which is probably not what you wanted to see. I have a feeling that it might be a better solution to stop using these pretty quotes. It's not like we use them a lot and a quick scanning of git grep '``' output seems to tell me that many of them should be `monospace output`, and the rest (mostly references to section headers) can be Section. -- 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
How to specify remote branch correctly
Hi, List I have two branches in the remote, say, origin/master, origin/foo. Then when I tried to switch to the remote foo branch, the following two methods gave me different results: 1. git checkout foo 2. git checkout origin/foo The first method run silently with success, but the second method complains that I got a 'detached HEAD'. So, I think I don't understand the difference between 'foo' and 'origin/foo'. Can someone give me a hint? Supposing I have another remote defined in .git/config that points to another repository but also have a same name branch, say 'remote-x/foo', how do I tell git which 'foo' I want to switch to? The similar problem also exists for 'fetch' command to me. From the man page, I don't find answer of how to specify which remote I am going to fetch from. Can you help me? Thanks in advance. -- woody I can't go back to yesterday - because I was a different person then. -- 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/3] Makefile: use -Wdeclaration-after-statement if supported
Adam Spiers g...@adamspiers.org writes: OK; I expect these issues with the implementation are all surmountable. I did not necessarily expect this to be the final implementation anyhow, as indicated by my comments below the divider line. However it's not clear to me what you think about the idea in principle, and whether other compiler flags would merit inclusion. As different versions of GCC behave differently, and the same GCC (mis)detect issues differently depending on the optimization level, I do not know if it will be a fruitful exercise to try to come up with one expression to come up with the set of flags to suit everybody. One flag I prefer to use is -Werror, but that means the other flags must have zero false positive rate. If you are interested, the flags I personally use with the version of GCC I happen to have is in the Make script on the 'todo' 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: How to specify remote branch correctly
On 17 December 2012 13:30, Woody Wu narkewo...@gmail.com wrote: 1. git checkout foo 2. git checkout origin/foo The first method run silently with success, but the second method complains that I got a 'detached HEAD'. So, I think I don't understand the difference between 'foo' and 'origin/foo'. Can someone give me a hint? Hi Woody, I think you are just missing a couple of important distinctions that git makes about the different references that exist in your repository. A remote reference (origin/foo) describes exactly the state of somebody else's branch at the time you last synchronised with them. It does not make sense for you to be able to 'edit' this state, as it doesn't belong to you. Instead, we create a copy of that reference and give it a name (git checkout foo origin/foo) and call this a local reference (foo). Git then provides machinery around keeping these in sync with each other (git branch --set-upstream foo origin/foo) but we don't _have_ to keep these in sync at all! In fact, the names can be completely arbitrary and we don't have to track the upstream at all. If I have some other remote (remote-x) that has the same branch as origin but with some other changes I want to look at, we can just check that out to another branch (git checkout remote-x-foo remote-x/foo), or simply download it as a remote ref and merge the changes on top of my existing local branch (git fetch remote-x; git checkout foo; git merge remote-x/foo). There are lots of patterns that can emerge from this functionality, but the main thing to remember is that to create changes on top of a remote branch, we first need to create a local copy of it. A 'detached HEAD' here means that we are looking at the remote repository's branch but don't have a local copy of it, so any changes we make might be 'lost' (that is, not have an easy to find branch name). Regards, Andrew Ardill -- 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] Makefile: remove tracking of TCLTK_PATH
Christian Couder chrisc...@tuxfamily.org writes: It looks like we are tracking the value of TCLTK_PATH in the main Makefile for no good reason, as this is done in git-gui too and the GIT-GUI-VARS is not used in the Makefile. This was added to the main Makefile when we slurped gitk to our project at the top-level, so I am not surprised if git-gui were not depending on it at all. A better explanation is that t62ba514 (Move gitk to its own subdirectory, 2007-11-17) should have moved these lines to gitk-git/Makefile (and I think we should move them there in a separate patch). -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git-completion.bash: add support for path completion
Manlio Perillo manlio.peri...@gmail.com writes:
The git-completion.bash script did not implemented full support for
completion, for git commands that operate on files from the current
working directory or the index.
For these commands, only options completion was available.
Hrm, git mv COTAB completes it to COPYING for me. Same for:
git rm COTAB
git clean DocTAB
git commit --edit DocTAB
There must be something missing from the above description, and the
claim the above two paragraphs make does no make sense without that
something that is missing.
* the path completion for the git mv and git rm commands is provided
using git ls-files --exclude-standard
Does the above mean git mv COPYING DocTAB would complete the
command line to move it to Documentation/ directory?
I think using X is of secondary importance. Reviewers and future
developers (who are reading git log output) can read it from the
patch. What is expected in the log message is why the implemenation
was chosen, and in order to achieve what effect.
For example, something like:
Each parameter between the first one and the one before the last
one to 'git mv' is completed to a tracked path or a leading
directory of a tracked path
should come first to explain what your patch wanted to do. It of
course is helpful to explain how you implemented that behaviour, by
appending , using 'ls-files --exclude-standard' at the end.
* the path completion for the git add command is provided using
git ls-files --exclude-standard -o -m
Likewise. You are adding either a modified, or a new and
unignored and use ls-files --exclude-standard -o -m to achieve
it.
* the path completion for the git clean command is provided using
git ls-files --exclude-standard -o
* the path completion for the git commit command is provides using
git diff-index --name-only HEAD
As long as all of the above stops completion at directory boundary,
I think the above sounds like a sensible thing to do. e.g. when
ls-files gives Documentation/Makefile and Documentation/git.txt,
git cmd DocTAB first would give git cmd Documentation/ and
then the second TAB would offer these two paths as choices. That
way, the user can choose to just execute git cmd Documentation/
without even looking at these individual paths.
I am not sure how you would handle the last parameter to git mv,
though. That is by definition a path that does not exist,
i.e. cannot be completed.
Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
contrib/completion/git-completion.bash | 39
++
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0b77eb1..8b348c3 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -233,6 +233,25 @@ __gitcomp_nl ()
COMPREPLY=($(compgen -P ${2-} -S ${4- } -W $1 -- ${3-$cur}))
}
+__git_files ()
+{
+ local dir=$(__gitdir)
+ if [ -d $dir ]; then
+ git --git-dir=$dir ls-files --exclude-standard $*
+ return
+ fi
+}
+
+# Return all staged files with modification from current HEAD
+__git_commit_files ()
+{
+ local dir=$(__gitdir)
+ if [ -d $dir ]; then
+ git --git-dir=$dir diff-index --name-only HEAD
+ return
+ fi
+}
+
__git_heads ()
{
local dir=$(__gitdir)
@@ -770,8 +789,6 @@ _git_apply ()
_git_add ()
{
- __git_has_doubledash return
-
case $cur in
--*)
__gitcomp
@@ -780,7 +797,8 @@ _git_add ()
return
esac
- COMPREPLY=()
+ # XXX should we care for --update and --all options ?
+ __gitcomp_nl $(__git_files -o -m) $cur
}
_git_archive ()
@@ -930,15 +948,14 @@ _git_cherry_pick ()
_git_clean ()
{
- __git_has_doubledash return
-
case $cur in
--*)
__gitcomp --dry-run --quiet
return
;;
esac
- COMPREPLY=()
+ # TODO: check for -x option
+ __gitcomp_nl $(__git_files -o) $cur
}
_git_clone ()
@@ -969,8 +986,6 @@ _git_clone ()
_git_commit ()
{
- __git_has_doubledash return
-
case $cur in
--cleanup=*)
__gitcomp default strip verbatim whitespace
@@ -998,7 +1013,7 @@ _git_commit ()
return
esac
- COMPREPLY=()
+ __gitcomp_nl $(__git_commit_files) $cur
}
_git_describe ()
@@ -1362,7 +1377,7 @@ _git_mv ()
return
;;
esac
- COMPREPLY=()
+ __gitcomp_nl $(__git_files) $cur
}
_git_name_rev ()
@@ -2068,15 +2083,13 @@ _git_revert ()
_git_rm ()
{
- __git_has_doubledash return
-
case $cur in
--*)
__gitcomp --cached --dry-run --ignore-unmatch
Re: [PATCH] git-completion.bash: update obsolete code.
Manlio Perillo manlio.peri...@gmail.com writes:
The git-completion.bash script was using the git ls-tree command
without the --name-only option, with a sed filter to parse path names;
use the --name-only option, instead.
Signed-off-by: Manlio Perillo manlio.peri...@gmail.com
---
Did you miss the different handling between blobs and trees the
latter gets trailing slash in the completion)?
contrib/completion/git-completion.bash | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 0b77eb1..85d9051 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -397,20 +397,7 @@ __git_complete_revlist_file ()
*) pfx=$ref:$pfx ;;
esac
- __gitcomp_nl $(git --git-dir=$(__gitdir) ls-tree $ls \
- | sed '/^100... blob /{
-s,^.*,,
-s,$, ,
-}
-/^12 blob /{
-s,^.*,,
-s,$, ,
-}
-/^04 tree /{
-s,^.*,,
-s,$,/,
-}
-s/^.*//') \
+ __gitcomp_nl $(git --git-dir=$(__gitdir) ls-tree --name-only
$ls) \
$pfx $cur_
;;
*...*)
--
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: How to specify remote branch correctly
On 2012-12-17, Andrew Ardill andrew.ard...@gmail.com wrote: On 17 December 2012 13:30, Woody Wu narkewo...@gmail.com wrote: 1. git checkout foo 2. git checkout origin/foo The first method run silently with success, but the second method complains that I got a 'detached HEAD'. So, I think I don't understand the difference between 'foo' and 'origin/foo'. Can someone give me a hint? Hi Woody, I think you are just missing a couple of important distinctions that git makes about the different references that exist in your repository. A remote reference (origin/foo) describes exactly the state of somebody else's branch at the time you last synchronised with them. It does not make sense for you to be able to 'edit' this state, as it doesn't belong to you. Instead, we create a copy of that reference and give it a name (git checkout foo origin/foo) and call this a local reference (foo). Git then provides machinery around keeping these in sync with each other (git branch --set-upstream foo origin/foo) but we don't _have_ to keep these in sync at all! In fact, the names can be completely arbitrary and we don't have to track the upstream at all. If I have some other remote (remote-x) that has the same branch as origin but with some other changes I want to look at, we can just check that out to another branch (git checkout remote-x-foo remote-x/foo), or simply download it as a remote ref and merge the changes on top of my existing local branch (git fetch remote-x; git checkout foo; git merge remote-x/foo). Thanks for explaining the concept of branch to me. Now I understood the difference between local and remote branch. But I still have difficulties in answering my own questions. 1. git checkout foo. By this command, I think I am checking out files in my local branch named foo, and after that I also switch to the branch. Right? 2. git checkout origin/foo By this command, I am checking out files in remote branch origin/foo, but don't create a local branch, so I am not in any branch now. This is the reason why git tell me that I am in a 'detached HEAD'. Is this understanding right? There are lots of patterns that can emerge from this functionality, but the main thing to remember is that to create changes on top of a remote branch, we first need to create a local copy of it. A 'detached HEAD' here means that we are looking at the remote repository's branch but don't have a local copy of it, so any changes we make might be 'lost' (that is, not have an easy to find branch name). I think here is a little confuse to me. You mean that a 'detached HEAD' means I don't have a local copy, but I remember that if I run something like: $ git checkout a-tag-name then I ususally went into 'detached HEAD' but my local files really get switched to those files in the tag 'a-tag-name'. So what does you mean by 'don't have a local copy'? Many thanks! -- woody I can't go back to yesterday - because I was a different person then. -- 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: How to specify remote branch correctly
On 17 December 2012 16:06, Woody Wu narkewo...@gmail.com wrote: 1. git checkout foo. By this command, I think I am checking out files in my local branch named foo, and after that I also switch to the branch. Right? Correct. Your working directory (files) switch over to whatever your local branch 'foo' points to, and your HEAD is updated to point to your local branch 'foo'. Unless something goes wrong/you have conflicting files/uncommitted changes etc. 2. git checkout origin/foo By this command, I am checking out files in remote branch origin/foo, but don't create a local branch, so I am not in any branch now. This is the reason why git tell me that I am in a 'detached HEAD'. Is this understanding right? Correct! Your working directory is updated, however it doesn't make sense for you to make changes to a remote branch, so HEAD is updated to be detached. There are lots of patterns that can emerge from this functionality, but the main thing to remember is that to create changes on top of a remote branch, we first need to create a local copy of it. A 'detached HEAD' here means that we are looking at the remote repository's branch but don't have a local copy of it, so any changes we make might be 'lost' (that is, not have an easy to find branch name). I think here is a little confuse to me. You mean that a 'detached HEAD' means I don't have a local copy, but I remember that if I run something like: $ git checkout a-tag-name then I ususally went into 'detached HEAD' but my local files really get switched to those files in the tag 'a-tag-name'. So what does you mean by 'don't have a local copy'? I should have been more clear. Here I mean that you don't have a local copy of the branch reference. Your working directory is updated to be in sync with the remote branch, but you haven't yet copied that remote reference to a local branch that you can update with your changes. Hope that clears it up. Regards, Andrew Ardill -- 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] Documentation: don't link to example mail addresses
John Keeping j...@keeping.me.uk writes: I can't see any other uses of the $$ quote in the documentation, so it's probably worth noting that I've tested this with Asciidoc 8.6.8, although I can't see anything in the changelog to indicate that Asciidoc's treatment of it has changed recently. Thanks. Documentation/git-fast-import.txt | 2 +- Documentation/git-tag.txt | 2 +- Documentation/mailmap.txt | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt index d1844ea..05913cc 100644 --- a/Documentation/git-fast-import.txt +++ b/Documentation/git-fast-import.txt @@ -427,7 +427,7 @@ they made it. Here `name` is the person's display name (for example ``Com M Itter'') and `email` is the person's email address -(``c...@example.com''). `LT` and `GT` are the literal less-than (\x3c) +(``$$c...@example.com$$''). `LT` and `GT` are the literal less-than (\x3c) and greater-than (\x3e) symbols. These are required to delimit the email address from the other fields in the line. Note that `name` and `email` are free-form and may contain any sequence AsciiDoc 8.5.2 gives this: asciidoc: WARNING: git-fast-import.txt: line 434: nested inline passthrough Also in git-fast-import.1, there is this line: ... person\(cqs display name (for example `Com M Itter\(aq\(aq) and `ema... (notice two leftover `s); not that this is a new issue with this patch. Which is puzzling, because the next input line formats better: ... email address (\(lqcm@example\.com\(rq)\. ... Other two hunks for git-tag and mailmap seem to give us a better results. -- 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: How to specify remote branch correctly
On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill andrew.ard...@gmail.com wrote: On 17 December 2012 16:06, Woody Wu narkewo...@gmail.com wrote: 1. git checkout foo. By this command, I think I am checking out files in my local branch named foo, and after that I also switch to the branch. Right? Correct. Your working directory (files) switch over to whatever your local branch 'foo' points to, and your HEAD is updated to point to your local branch 'foo'. Unless something goes wrong/you have conflicting files/uncommitted changes etc. 'git checkout foo' has special meaning if a local branch with that name doesn't exist but there is a remote branch with that name. In that case it's equivalent to: git checkout -t -b foo origin/foo. Because that's what people usually want. -- 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: How to specify remote branch correctly
On 17 December 2012 16:30, Tomas Carnecky tomas.carne...@gmail.com wrote: 'git checkout foo' has special meaning if a local branch with that name doesn't exist but there is a remote branch with that name. In that case it's equivalent to: git checkout -t -b foo origin/foo. Because that's what people usually want. This is true, but I don't think it is documented. Does anyone know if this is documented anywhere in particular? The git checkout man pages seem to not mention it, and the git branch page doesn't seem to mention it either, but perhaps I am just missing it? In any case, might be useful to make this behaviour more clear. Regards, Andrew Ardill -- 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: How to specify remote branch correctly
On Sun, Dec 16, 2012 at 11:52 PM, Andrew Ardill andrew.ard...@gmail.com wrote: This is true, but I don't think it is documented. I noticed this, too. I was just about to send a patch to add this. Chris -- 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 0/2] Documentation: clarify usage of checkout
This is response to the questions posed in: http://thread.gmane.org/gmane.comp.version-control.git/211624 It doesn't seem like the behavior implemented in 70c9ac2 is documented. Chris Rorvick (2): Documentation/git-checkout.txt: clarify usage Documentation/git-checkout.txt: document 70c9ac2 behavior Documentation/git-checkout.txt | 34 +- 1 file changed, 25 insertions(+), 9 deletions(-) -- 1.8.1.rc1.203.g1ddc124 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Documentation/git-checkout.txt: clarify usage
The forms of checkout that do not take a path are lumped together in the DESCRIPTION section, but the description for this group is dominated by explanation of the -b|-B form. Split these apart for more clarity. Signed-off-by: Chris Rorvick ch...@rorvick.com --- Documentation/git-checkout.txt | 26 +- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 7958a47..a47555c 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -22,17 +22,18 @@ also update `HEAD` to set the specified branch as the current branch. 'git checkout' [branch]:: + + Update the index, working tree, and HEAD to reflect the + specified branch. + 'git checkout' -b|-B new_branch [start point]:: -'git checkout' [--detach] [commit]:: - This form switches branches by updating the index, working - tree, and HEAD to reflect the specified branch or commit. -+ -If `-b` is given, a new branch is created as if linkgit:git-branch[1] -were called and then checked out; in this case you can -use the `--track` or `--no-track` options, which will be passed to -'git branch'. As a convenience, `--track` without `-b` implies branch -creation; see the description of `--track` below. + Specifying `-b` causes a new branch to be created as if + linkgit:git-branch[1] were called and then checked out. In + this case you can use the `--track` or `--no-track` options, + which will be passed to 'git branch'. As a convenience, + `--track` without `-b` implies branch creation; see the + description of `--track` below. + If `-B` is given, new_branch is created if it doesn't exist; otherwise, it is reset. This is the transactional equivalent of @@ -45,6 +46,13 @@ $ git checkout branch that is to say, the branch is not reset/created unless git checkout is successful. +'git checkout' [--detach] [commit]:: + + Update the index and working tree to reflect the specified + commit and set HEAD to point directly to commit (see + DETACHED HEAD section.) Passing `--detach` forces this + behavior even if commit is a branch. + 'git checkout' [-p|--patch] [tree-ish] [--] pathspec...:: When paths or `--patch` are given, 'git checkout' does *not* -- 1.8.1.rc1.203.g1ddc124 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] Documentation/git-checkout.txt: document 70c9ac2 behavior
Document the behavior implemented in 70c9ac2 (DWIM git checkout frotz to git checkout -b frotz origin/frotz). Signed-off-by: Chris Rorvick ch...@rorvick.com --- Documentation/git-checkout.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index a47555c..db89cf7 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -25,6 +25,14 @@ branch. Update the index, working tree, and HEAD to reflect the specified branch. ++ +If branch is not found but there does exist a tracking branch in +exactly one remote (call it remote) with a matching name, treat as +equivalent to ++ + +$ git checkout -b branch --track remote/branch + 'git checkout' -b|-B new_branch [start point]:: -- 1.8.1.rc1.203.g1ddc124 -- 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: How to specify remote branch correctly
On 2012-12-17, Andrew Ardill andrew.ard...@gmail.com wrote: On 17 December 2012 16:06, Woody Wu narkewo...@gmail.com wrote: 1. git checkout foo. By this command, I think I am checking out files in my local branch named foo, and after that I also switch to the branch. Right? Correct. Your working directory (files) switch over to whatever your local branch 'foo' points to, and your HEAD is updated to point to your local branch 'foo'. Unless something goes wrong/you have conflicting files/uncommitted changes etc. 2. git checkout origin/foo By this command, I am checking out files in remote branch origin/foo, but don't create a local branch, so I am not in any branch now. This is the reason why git tell me that I am in a 'detached HEAD'. Is this understanding right? Correct! Your working directory is updated, however it doesn't make sense for you to make changes to a remote branch, so HEAD is updated to be detached. There are lots of patterns that can emerge from this functionality, but the main thing to remember is that to create changes on top of a remote branch, we first need to create a local copy of it. A 'detached HEAD' here means that we are looking at the remote repository's branch but don't have a local copy of it, so any changes we make might be 'lost' (that is, not have an easy to find branch name). I think here is a little confuse to me. You mean that a 'detached HEAD' means I don't have a local copy, but I remember that if I run something like: $ git checkout a-tag-name then I ususally went into 'detached HEAD' but my local files really get switched to those files in the tag 'a-tag-name'. So what does you mean by 'don't have a local copy'? I should have been more clear. Here I mean that you don't have a local copy of the branch reference. Your working directory is updated to be in sync with the remote branch, but you haven't yet copied that remote reference to a local branch that you can update with your changes. Hope that clears it up. Andre, by this in further exaplaination, I think I fully understood. Thanks a lot! -- woody I can't go back to yesterday - because I was a different person then. -- 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: How to specify remote branch correctly
On 2012-12-17, Tomas Carnecky tomas.carne...@gmail.com wrote: On Mon, 17 Dec 2012 16:13:08 +1100, Andrew Ardill andrew.ard...@gmail.com wrote: On 17 December 2012 16:06, Woody Wu narkewo...@gmail.com wrote: 1. git checkout foo. By this command, I think I am checking out files in my local branch named foo, and after that I also switch to the branch. Right? Correct. Your working directory (files) switch over to whatever your local branch 'foo' points to, and your HEAD is updated to point to your local branch 'foo'. Unless something goes wrong/you have conflicting files/uncommitted changes etc. 'git checkout foo' has special meaning if a local branch with that name doesn't exist but there is a remote branch with that name. In that case it's equivalent to: git checkout -t -b foo origin/foo. Because that's what people usually want. I think this is what exactly happened to me in the first time I got the 'foo'. One new thing to me is the '-t'. I am not sure wether the '-t' was used or not in the background. How do I check the 'upstream' relationships? Is there any file under .git recoreded that kind of information? -- woody I can't go back to yesterday - because I was a different person then. -- 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 v3 2/4] Makefile: detect when PYTHON_PATH changes
When make is run, the python scripts are created from *.py files that are changed to use the python given by PYTHON_PATH. And PYTHON_PATH is set by default to /usr/bin/python on Linux. This is nice except when you run make another time setting a different PYTHON_PATH, because, as the python scripts have already been created, make finds nothing to do. The goal of this patch is to detect when the PYTHON_PATH changes and to create the python scripts again when this happens. To do that we use the same trick that is done to track other variables like prefix, flags, tcl/tk path and shell path. We update a GIT-PYTHON-VARS file with the PYTHON_PATH and check if it changed. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- .gitignore | 1 + Makefile | 16 ++-- 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index 6d69ae1..086c5af 100644 --- a/.gitignore +++ b/.gitignore @@ -2,6 +2,7 @@ /GIT-CFLAGS /GIT-LDFLAGS /GIT-PREFIX +/GIT-PYTHON-VARS /GIT-SCRIPT-DEFINES /GIT-USER-AGENT /GIT-VERSION-FILE diff --git a/Makefile b/Makefile index 585b2eb..7db8445 100644 --- a/Makefile +++ b/Makefile @@ -2245,7 +2245,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)) git-instaweb: % : unimplemented.sh endif # NO_PERL ifndef NO_PYTHON -$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX +$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS GIT-PREFIX GIT-PYTHON-VARS $(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py $(QUIET_GEN)$(RM) $@ $@+ \ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_helpers -s \ @@ -2624,6 +2624,18 @@ ifdef GIT_PERF_MAKE_OPTS @echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' $@ endif +### Detect Python interpreter path changes +ifndef NO_PYTHON +TRACK_PYTHON = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)') + +GIT-PYTHON-VARS: FORCE + @VARS='$(TRACK_PYTHON)'; \ + if test x$$VARS != x`cat $@ 2/dev/null` ; then \ + echo 12 * new Python interpreter location; \ + echo $$VARS $@; \ +fi +endif + test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X)) all:: $(TEST_PROGRAMS) $(test_bindir_programs) @@ -2899,7 +2911,7 @@ ifndef NO_TCLTK $(MAKE) -C git-gui clean endif $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS - $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES + $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES GIT-PYTHON-VARS .PHONY: all install profile-clean clean strip .PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell -- 1.8.1.rc1.2.g8740035 -- 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 v3 1/4] Makefile: remove tracking of TCLTK_PATH
It looks like we are tracking the value of TCLTK_PATH in the main Makefile for no good reason, as this is done in git-gui too and the GIT-GUI-VARS is not used in the Makefile. This patch removes the useless code used to do this tracking. Maybe this code should have been moved to gitk-git/Makefile by 62ba514 (Move gitk to its own subdirectory, 2007-11-17). Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- .gitignore | 1 - Makefile | 14 +- 2 files changed, 1 insertion(+), 14 deletions(-) diff --git a/.gitignore b/.gitignore index f702415..6d69ae1 100644 --- a/.gitignore +++ b/.gitignore @@ -1,7 +1,6 @@ /GIT-BUILD-OPTIONS /GIT-CFLAGS /GIT-LDFLAGS -/GIT-GUI-VARS /GIT-PREFIX /GIT-SCRIPT-DEFINES /GIT-USER-AGENT diff --git a/Makefile b/Makefile index 4ad6fbd..585b2eb 100644 --- a/Makefile +++ b/Makefile @@ -2624,18 +2624,6 @@ ifdef GIT_PERF_MAKE_OPTS @echo GIT_PERF_MAKE_OPTS=\''$(subst ','\'',$(subst ','\'',$(GIT_PERF_MAKE_OPTS)))'\' $@ endif -### Detect Tck/Tk interpreter path changes -ifndef NO_TCLTK -TRACK_VARS = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)') - -GIT-GUI-VARS: FORCE - @VARS='$(TRACK_VARS)'; \ - if test x$$VARS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new Tcl/Tk interpreter location; \ - echo $$VARS $@; \ -fi -endif - test_bindir_programs := $(patsubst %,bin-wrappers/%,$(BINDIR_PROGRAMS_NEED_X) $(BINDIR_PROGRAMS_NO_X) $(TEST_PROGRAMS_NEED_X)) all:: $(TEST_PROGRAMS) $(test_bindir_programs) @@ -2910,7 +2898,7 @@ ifndef NO_TCLTK $(MAKE) -C gitk-git clean $(MAKE) -C git-gui clean endif - $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS + $(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-LDFLAGS GIT-BUILD-OPTIONS $(RM) GIT-USER-AGENT GIT-PREFIX GIT-SCRIPT-DEFINES .PHONY: all install profile-clean clean strip -- 1.8.1.rc1.2.g8740035 -- 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 v3 3/4] gitk-git/Makefile: track TCLTK_PATH as it used to be tracked
In 62ba514 (Move gitk to its own subdirectory, 2007-11-17) some code used to track TCLTK_PATH was left in the main Makefile instead of being moved to the new Makefile that was created in gitk-git/. The code left in the main Makefile should have been removed by a previous patch in the same series as this one. And this patch puts some code back to track TCLTK_PATH properly where it should be, that is in gitk-git/Makefile. Note that there is already some code to do that in git-gui/Makefile. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- .gitignore | 1 - gitk-git/.gitignore | 2 ++ gitk-git/Makefile | 16 ++-- 3 files changed, 16 insertions(+), 3 deletions(-) create mode 100644 gitk-git/.gitignore diff --git a/.gitignore b/.gitignore index 086c5af..56a4b2b 100644 --- a/.gitignore +++ b/.gitignore @@ -171,7 +171,6 @@ /git-whatchanged /git-write-tree /git-core-*/?* -/gitk-git/gitk-wish /gitweb/GITWEB-BUILD-OPTIONS /gitweb/gitweb.cgi /gitweb/static/gitweb.js diff --git a/gitk-git/.gitignore b/gitk-git/.gitignore new file mode 100644 index 000..d7ebcaf --- /dev/null +++ b/gitk-git/.gitignore @@ -0,0 +1,2 @@ +/GIT-TCLTK-VARS +/gitk-wish diff --git a/gitk-git/Makefile b/gitk-git/Makefile index e1b6045..5acdc90 100644 --- a/gitk-git/Makefile +++ b/gitk-git/Makefile @@ -17,6 +17,16 @@ DESTDIR_SQ = $(subst ','\'',$(DESTDIR)) bindir_SQ = $(subst ','\'',$(bindir)) TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH)) +### Detect Tck/Tk interpreter path changes +TRACK_TCLTK = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)') + +GIT-TCLTK-VARS: FORCE + @VARS='$(TRACK_TCLTK)'; \ + if test x$$VARS != x`cat $@ 2/dev/null` ; then \ + echo 12 * new Tcl/Tk interpreter location; \ + echo $$VARS $@; \ + fi + ## po-file creation rules XGETTEXT ?= xgettext ifdef NO_MSGFMT @@ -49,9 +59,9 @@ uninstall:: $(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk clean:: - $(RM) gitk-wish po/*.msg + $(RM) gitk-wish po/*.msg GIT-TCLTK-VARS -gitk-wish: gitk +gitk-wish: gitk GIT-TCLTK-VARS $(QUIET_GEN)$(RM) $@ $@+ \ sed -e '1,3s|^exec .* $$0|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) $$0|' gitk $@+ \ chmod +x $@+ \ @@ -65,3 +75,5 @@ $(ALL_MSGFILES): %.msg : %.po @echo Generating catalog $@ $(MSGFMT) --statistics --tcl $ -l $(basename $(notdir $)) -d $(dir $@) +.PHONY: all install uninstall clean update-po +.PHONY: FORCE -- 1.8.1.rc1.2.g8740035 -- 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 v3 4/4] Makefile: replace echo 1... with echo ...
This is clearer to many people this way. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- Makefile | 10 +- git-gui/Makefile | 6 +++--- gitk-git/Makefile | 2 +- 3 files changed, 9 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index 7db8445..e055c9a 100644 --- a/Makefile +++ b/Makefile @@ -2183,7 +2183,7 @@ endef GIT-SCRIPT-DEFINES: FORCE @FLAGS='$(SCRIPT_DEFINES)'; \ if test x$$FLAGS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new script parameters; \ + echo 2 * new script parameters; \ echo $$FLAGS $@; \ fi @@ -2564,7 +2564,7 @@ TRACK_PREFIX = $(bindir_SQ):$(gitexecdir_SQ):$(template_dir_SQ):$(prefix_SQ):\ GIT-PREFIX: FORCE @FLAGS='$(TRACK_PREFIX)'; \ if test x$$FLAGS != x`cat GIT-PREFIX 2/dev/null` ; then \ - echo 12 * new prefix flags; \ + echo 2 * new prefix flags; \ echo $$FLAGS GIT-PREFIX; \ fi @@ -2573,7 +2573,7 @@ TRACK_CFLAGS = $(CC):$(subst ','\'',$(ALL_CFLAGS)):$(USE_GETTEXT_SCHEME) GIT-CFLAGS: FORCE @FLAGS='$(TRACK_CFLAGS)'; \ if test x$$FLAGS != x`cat GIT-CFLAGS 2/dev/null` ; then \ - echo 12 * new build flags; \ + echo 2 * new build flags; \ echo $$FLAGS GIT-CFLAGS; \ fi @@ -2582,7 +2582,7 @@ TRACK_LDFLAGS = $(subst ','\'',$(ALL_LDFLAGS)) GIT-LDFLAGS: FORCE @FLAGS='$(TRACK_LDFLAGS)'; \ if test x$$FLAGS != x`cat GIT-LDFLAGS 2/dev/null` ; then \ - echo 12 * new link flags; \ + echo 2 * new link flags; \ echo $$FLAGS GIT-LDFLAGS; \ fi @@ -2631,7 +2631,7 @@ TRACK_PYTHON = $(subst ','\'',-DPYTHON_PATH='$(PYTHON_PATH_SQ)') GIT-PYTHON-VARS: FORCE @VARS='$(TRACK_PYTHON)'; \ if test x$$VARS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new Python interpreter location; \ + echo 2 * new Python interpreter location; \ echo $$VARS $@; \ fi endif diff --git a/git-gui/Makefile b/git-gui/Makefile index e22ba5c..e9c2bc3 100644 --- a/git-gui/Makefile +++ b/git-gui/Makefile @@ -254,7 +254,7 @@ lib/tclIndex: $(ALL_LIBFILES) GIT-GUI-VARS auto_mkindex lib '*.tcl' \ | $(TCL_PATH) $(QUIET_2DEVNULL); then : ok; \ else \ -echo 12 * $(TCL_PATH) failed; using unoptimized loading; \ +echo 2 * $(TCL_PATH) failed; using unoptimized loading; \ rm -f $@ ; \ echo '# Autogenerated by git-gui Makefile' $@ \ echo $@ \ @@ -274,8 +274,8 @@ TRACK_VARS = \ GIT-GUI-VARS: FORCE @VARS='$(TRACK_VARS)'; \ if test x$$VARS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new locations or Tcl/Tk interpreter; \ - echo 1$@ $$VARS; \ + echo 2 * new locations or Tcl/Tk interpreter; \ + echo $@ $$VARS; \ fi ifdef GITGUI_MACOSXAPP diff --git a/gitk-git/Makefile b/gitk-git/Makefile index 5acdc90..c2df22f 100644 --- a/gitk-git/Makefile +++ b/gitk-git/Makefile @@ -23,7 +23,7 @@ TRACK_TCLTK = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)') GIT-TCLTK-VARS: FORCE @VARS='$(TRACK_TCLTK)'; \ if test x$$VARS != x`cat $@ 2/dev/null` ; then \ - echo 12 * new Tcl/Tk interpreter location; \ + echo 2 * new Tcl/Tk interpreter location; \ echo $$VARS $@; \ fi -- 1.8.1.rc1.2.g8740035 -- 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/2] Documentation/git-checkout.txt: clarify usage
Chris Rorvick ch...@rorvick.com writes: The forms of checkout that do not take a path are lumped together in the DESCRIPTION section, but the description for this group is dominated by explanation of the -b|-B form. Split these apart for more clarity. Signed-off-by: Chris Rorvick ch...@rorvick.com --- Documentation/git-checkout.txt | 26 +- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index 7958a47..a47555c 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -22,17 +22,18 @@ also update `HEAD` to set the specified branch as the current branch. 'git checkout' [branch]:: + + Update the index, working tree, and HEAD to reflect the + specified branch. This is to check out the branch ;-) But of course, we cannot define checkout in terms of checkout, so we need to phrase it without saying checkout and explain what it *means* to check out the branch. I am not sure Reflect is a good word. Making the result similar to the branch is only one aspect of the act of checking out the branch. The other equally important aspect is that this is done to advance the history of the branch. Perhaps... Prepare to work on building new history on branch, by pointing the HEAD to the branch and updating the index and the files in the working tree. Local modifications to the files in the working tree are kept, so that they can be committed on the branch. 'git checkout' -b|-B new_branch [start point]:: + Specifying `-b` causes a new branch to be created as if + linkgit:git-branch[1] were called and then checked out. In + this case you can use the `--track` or `--no-track` options, + which will be passed to 'git branch'. As a convenience, + `--track` without `-b` implies branch creation; see the + description of `--track` below. + If `-B` is given, new_branch is created if it doesn't exist; otherwise, it is reset. This is the transactional equivalent of @@ -45,6 +46,13 @@ $ git checkout branch that is to say, the branch is not reset/created unless git checkout is successful. +'git checkout' [--detach] [commit]:: + + Update the index and working tree to reflect the specified + commit and set HEAD to point directly to commit (see + DETACHED HEAD section.) Passing `--detach` forces this + behavior even if commit is a branch. Prepare to work on building new history on top of commit, by detaching HEAD at the commit and ...(likewise)... -- 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/2] Documentation/git-checkout.txt: document 70c9ac2 behavior
Chris Rorvick ch...@rorvick.com writes: Document the behavior implemented in 70c9ac2 (DWIM git checkout frotz to git checkout -b frotz origin/frotz). Signed-off-by: Chris Rorvick ch...@rorvick.com --- Documentation/git-checkout.txt | 8 1 file changed, 8 insertions(+) diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index a47555c..db89cf7 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -25,6 +25,14 @@ branch. Update the index, working tree, and HEAD to reflect the specified branch. ++ +If branch is not found but there does exist a tracking branch in +exactly one remote (call it remote) with a matching name, treat as +equivalent to ++ + +$ git checkout -b branch --track remote/branch + 'git checkout' -b|-B new_branch [start point]:: Thanks; does it format well (I didn't check)? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How to specify remote branch correctly
On Mon, 17 Dec 2012 07:02:46 +, Woody Wu narkewo...@gmail.com wrote:
On 2012-12-17, Tomas Carnecky tomas.carne...@gmail.com wrote:
'git checkout foo' has special meaning if a local branch with that
name doesn't exist but there is a remote branch with that name. In
that case it's equivalent to: git checkout -t -b foo origin/foo.
Because that's what people usually want.
I think this is what exactly happened to me in the first time I got the
'foo'. One new thing to me is the '-t'. I am not sure wether the '-t'
was used or not in the background. How do I check the 'upstream'
relationships? Is there any file under .git recoreded that kind of
information?
Yes, that information is recorded in a file somewhere in .git. However, for
most users it's irrelevant which file it is. Git has commands to access this
information. Try one of these:
git branch -vv
git remote show origin
git rev-parse --abbrev-ref --symbolic-full-name @{u}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
What's cooking in git.git (Dec 2012, #04; Sun, 16)
Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The tip of the 'master' branch is 1.8.1-rc2; hopefully we can go final around the end of next week. Many topics are getting into good shape in 'next', hopefully ready to be merged soon after the 1.8.1 final. You can find the changes described here in the integration branches of the repositories listed at http://git-blame.blogspot.com/p/git-public-repositories.html -- [New Topics] * ja/directory-attrs (2012-12-13) 2 commits - [squash] simplify find-basename in attr.c - Add directory pattern matching to attributes The attribute mechanism didn't allow limiting attributes to be applied to only a single directory itself with path/ like the exclude mechanism does. Will merge to 'next' after squashing the microfix. * jk/mailmap-cleanup (2012-12-12) 5 commits - contrib: update stats/mailmap script - .mailmap: normalize emails for Linus Torvalds - .mailmap: normalize emails for Jeff King - .mailmap: fix broken entry for Martin Langhoff - .mailmap: match up some obvious names/emails Update various entries in our .mailmap file. Will merge to 'next'. * jk/mailmap-from-blob (2012-12-13) 5 commits - mailmap: default mailmap.blob in bare repositories - mailmap: fix some documentation loose-ends for mailmap.blob - mailmap: clean up read_mailmap error handling - mailmap: support reading mailmap from blobs - mailmap: refactor mailmap parsing for non-file sources Allow us to read, and default to read, mailmap files from the tip of the history in bare repositories. This will help running tools like shortlog in server settings. Will merge to 'next'. * nd/index-format-doc (2012-12-13) 1 commit - index-format.txt: clarify what is invalid Will merge to 'next'. * as/doc-for-devs (2012-12-16) 2 commits - Documentation: move support for old compilers to CodingGuidelines - SubmittingPatches: add convention of prefixing commit messages It might be a better idea to move the text the bottom one adds to the extended description from the quick checklist part. * cc/no-git-gui-rebuild-depend (2012-12-16) 2 commits - Makefile: detect when PYTHON_PATH changes - Makefile: remove tracking of TCLTK_PATH The bottom one associates the issue with git-gui, but what it removes is a remnant of gitk support when it did not have a separate Makefile; we may need to add the logic there. * dm/port (2012-12-15) 3 commits - Generalize the inclusion of strings.h - Detect when the passwd struct is missing pw_gecos - Support builds when sys/param.h is missing It could turn out that we may be able to get rid of sys/param.h altogether, but one step at a time. Inputs from people on minority platforms are very much appreciated---does your platform build fine when the inclusion of the file is removed from git-compat-util.h? Will merge to 'next'. * jc/fetch-tags-doc (2012-12-13) 1 commit - fetch --tags: clarify documentation The explanation for fetch --tags was actually talking more about fetch --no-tags. Clariify what --tags really means. Will merge to 'next'. * jk/avoid-mailto-invalid-in-doc (2012-12-16) 1 commit - Documentation: don't link to example mail addresses Avoids invalid sample e-mail addresses from becoming mailto links in the formatted output, which by itself is Meh for me (who cares?) but it highlights some issues with ``pretty quotes''. Will merge to 'next'. * jk/complete-commit-c (2012-12-15) 1 commit - completion: complete refs for git commit -c Complete git commmit -c fooTAB into a refname that begins with foo. Will merge to 'next'. * jk/error-const-return (2012-12-15) 2 commits - silence some -Wuninitialized false positives - make error()'s constant return value more visible Help compilers' flow analysis by making it more explicit that error() always returns -1, to reduce false variable used uninitialized warnings. This is still an RFC. * mk/qnx (2012-12-15) 2 commits - Port to QNX - Make lock local to fetch_pack Port to QNX; we may want to rebase this on top of dm/port topic as it also wants to use the HAVE_STRINGS_H mechanism it introduces. * rj/maint-cygwin-say-color (2012-12-15) 1 commit - tests: Allow customization of how say_color() prints Even though I do not think of a cleaner way to do this, I am not happy with the way how $GIT_TEST_PRINT and $GIT_TEST_PRINT_LN are interpolated into the command line with token splitting at $IFS. * sl/readme-gplv2 (2012-12-15) 2 commits - README: it does not matter who the current maintainer is - README: Git is released under the GPLv2, not just the GPL Clarify that the project as a whole is GPLv2 only, with some parts borrowed under different licenses that are compatible with GPLv2. Will merge to 'next'. * ta/api-index-doc (2012-12-16) 1 commit - Remove misleading date
Re: [PATCH v2 1/2] Makefile: remove tracking of TCLTK_PATH
From: Junio C Hamano gits...@pobox.com Christian Couder chrisc...@tuxfamily.org writes: It looks like we are tracking the value of TCLTK_PATH in the main Makefile for no good reason, as this is done in git-gui too and the GIT-GUI-VARS is not used in the Makefile. This was added to the main Makefile when we slurped gitk to our project at the top-level, so I am not surprised if git-gui were not depending on it at all. A better explanation is that t62ba514 (Move gitk to its own subdirectory, 2007-11-17) should have moved these lines to gitk-git/Makefile (and I think we should move them there in a separate patch). Yeah, I just sent an updated patch series that does this. 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 2/2] Documentation/git-checkout.txt: document 70c9ac2 behavior
On 17 December 2012 18:21, Junio C Hamano gits...@pobox.com wrote: does it format well (I didn't check)? It applied cleanly for me on latest master, and the output looked consistent with existing documentation. Regards, Andrew Ardill -- 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/2] Documentation/git-checkout.txt: document 70c9ac2 behavior
Andrew Ardill andrew.ard...@gmail.com writes: On 17 December 2012 18:21, Junio C Hamano gits...@pobox.com wrote: does it format well (I didn't check)? It applied cleanly for me on latest master, and the output looked consistent with existing documentation. 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 v2 1/2] Makefile: remove tracking of TCLTK_PATH
Christian Couder chrisc...@tuxfamily.org writes: From: Junio C Hamano gits...@pobox.com Christian Couder chrisc...@tuxfamily.org writes: It looks like we are tracking the value of TCLTK_PATH in the main Makefile for no good reason, as this is done in git-gui too and the GIT-GUI-VARS is not used in the Makefile. This was added to the main Makefile when we slurped gitk to our project at the top-level, so I am not surprised if git-gui were not depending on it at all. A better explanation is that t62ba514 (Move gitk to its own subdirectory, 2007-11-17) should have moved these lines to gitk-git/Makefile (and I think we should move them there in a separate patch). Yeah, I just sent an updated patch series that does this. It still seems to talk about git-gui which the snippet you removed does not have anything to do with, though. -- 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 3/4] gitk-git/Makefile: track TCLTK_PATH as it used to be tracked
Christian Couder chrisc...@tuxfamily.org writes: In 62ba514 (Move gitk to its own subdirectory, 2007-11-17) some code used to track TCLTK_PATH was left in the main Makefile instead of being moved to the new Makefile that was created in gitk-git/. The code left in the main Makefile should have been removed by a previous patch in the same series as this one. And this patch puts some code back to track TCLTK_PATH properly where it should be, that is in gitk-git/Makefile. Note that there is already some code to do that in git-gui/Makefile. Signed-off-by: Christian Couder chrisc...@tuxfamily.org --- .gitignore | 1 - gitk-git/.gitignore | 2 ++ gitk-git/Makefile | 16 ++-- I'll apply the .gitignore part to my tree, but could you split the rest out and have Paul apply to his tree at git://ozlabs.org/~paulus/gitk.git 3 files changed, 16 insertions(+), 3 deletions(-) create mode 100644 gitk-git/.gitignore diff --git a/.gitignore b/.gitignore index 086c5af..56a4b2b 100644 --- a/.gitignore +++ b/.gitignore @@ -171,7 +171,6 @@ /git-whatchanged /git-write-tree /git-core-*/?* -/gitk-git/gitk-wish /gitweb/GITWEB-BUILD-OPTIONS /gitweb/gitweb.cgi /gitweb/static/gitweb.js diff --git a/gitk-git/.gitignore b/gitk-git/.gitignore new file mode 100644 index 000..d7ebcaf --- /dev/null +++ b/gitk-git/.gitignore @@ -0,0 +1,2 @@ +/GIT-TCLTK-VARS +/gitk-wish diff --git a/gitk-git/Makefile b/gitk-git/Makefile index e1b6045..5acdc90 100644 --- a/gitk-git/Makefile +++ b/gitk-git/Makefile @@ -17,6 +17,16 @@ DESTDIR_SQ = $(subst ','\'',$(DESTDIR)) bindir_SQ = $(subst ','\'',$(bindir)) TCLTK_PATH_SQ = $(subst ','\'',$(TCLTK_PATH)) +### Detect Tck/Tk interpreter path changes +TRACK_TCLTK = $(subst ','\'',-DTCLTK_PATH='$(TCLTK_PATH_SQ)') + +GIT-TCLTK-VARS: FORCE + @VARS='$(TRACK_TCLTK)'; \ + if test x$$VARS != x`cat $@ 2/dev/null` ; then \ + echo 12 * new Tcl/Tk interpreter location; \ + echo $$VARS $@; \ + fi + ## po-file creation rules XGETTEXT ?= xgettext ifdef NO_MSGFMT @@ -49,9 +59,9 @@ uninstall:: $(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk clean:: - $(RM) gitk-wish po/*.msg + $(RM) gitk-wish po/*.msg GIT-TCLTK-VARS -gitk-wish: gitk +gitk-wish: gitk GIT-TCLTK-VARS $(QUIET_GEN)$(RM) $@ $@+ \ sed -e '1,3s|^exec .* $$0|exec $(subst |,'\|',$(TCLTK_PATH_SQ)) $$0|' gitk $@+ \ chmod +x $@+ \ @@ -65,3 +75,5 @@ $(ALL_MSGFILES): %.msg : %.po @echo Generating catalog $@ $(MSGFMT) --statistics --tcl $ -l $(basename $(notdir $)) -d $(dir $@) +.PHONY: all install uninstall clean update-po +.PHONY: FORCE -- 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: How to specify remote branch correctly
On 2012-12-17, Tomas Carnecky tomas.carne...@gmail.com wrote: On Mon, 17 Dec 2012 07:02:46 +, Woody Wu narkewo...@gmail.com wrote: On 2012-12-17, Tomas Carnecky tomas.carne...@gmail.com wrote: 'git checkout foo' has special meaning if a local branch with that name doesn't exist but there is a remote branch with that name. In that case it's equivalent to: git checkout -t -b foo origin/foo. Because that's what people usually want. I think this is what exactly happened to me in the first time I got the 'foo'. One new thing to me is the '-t'. I am not sure wether the '-t' was used or not in the background. How do I check the 'upstream' relationships? Is there any file under .git recoreded that kind of information? Yes, that information is recorded in a file somewhere in .git. However, for most users it's irrelevant which file it is. Git has commands to access this information. Try one of these: git branch -vv Run this on my local linux tree, I got: lgf2410-2.6.16.4 7af1fda - added a ignore rule in .gitignore (*~) * lgf2410-2.6.34.1350d3f9d ax88796b verbose debug output lgf2410-2.6.34.13-16C554 3ec82e0 more debug on 16C554 master 9489e9d [origin/master] Linux 3.7-rc7 Does this mean, I only have local branch master tracked to remote? git remote show origin Running this I got, ... linux-3.1.ytracked linux-3.2.ytracked linux-3.3.ytracked linux-3.4.ytracked linux-3.5.ytracked linux-3.6.ytracked linux-3.7.ynew (next fetch will store in remotes/origin) master tracked Local branch configured for 'git pull': master rebases onto remote master Local ref configured for 'git push': master pushes to master (local out of date) I am curious to know how the last 4 lines were printed by git. - Local branch configured for 'git pull': master rebases onto remote master - If I have addtional branch other than master that also track to some remote branch, will it also be listed under this 'git pull' line? Local ref configured for 'git push': master pushes to master (local out of date) --- This I totally don't understand, what it mean? I think I did not do a modification on the local 'master'. Thanks! -- woody I can't go back to yesterday - because I was a different person then. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] Cannot push some grafted branches
On Wed, 12 Dec 2012 11:57:47 -0800
Junio C Hamano gits...@pobox.com wrote:
Yann Dirson dir...@bertin.fr writes:
In this respect, they seem to be
lacking a few features, when compared to replace refs, but they have
different
uses, ...
Not reallyl; grafts were old hack whose use is still supported with
its original limitations; replace is meant to replace all uses of
grafts while removing grafts' largest warts.
OK, I'll take this into account.
But this situation should probably be make more clear in the docs. Currently,
gitrepository-layout.txt describes refs/replace/ (and shallow) by reference to
grafts,
and those are not marked as discouraged-use or anything.
And we may still want the bug fixed, or would we just list it as a known bug ?
At least it does not seem to occur with replace refs:
git-test$ rm .git/info/grafts
git-test$ echo fake merge | git commit-tree master^{tree} -p master^ -p maint
b821b2aa00973a47936d7cd25c9a5978b1c839c6
git-test$ git replace master b821b2aa00973a47936d7cd25c9a5978b1c839c6
git-test$ git push origin maint
...
50b03b0..79211fe maint - maint
--
Yann Dirson - Bertin Technologies
--
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
