[PATCH 07/10] t/t2025-worktree-add.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t2025-worktree-add.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t2025-worktree-add.sh b/t/t2025-worktree-add.sh index 3694174..0a804da 100755 --- a/t/t2025-worktree-add.sh +++ b/t/t2025-worktree-add.sh @@ -123,10 +123,10 @@ test_expect_success 'checkout from a bare repo without "add"' ' test_expect_success 'checkout with grafts' ' test_when_finished rm .git/info/grafts && test_commit abc && - SHA1=`git rev-parse HEAD` && + SHA1=$(git rev-parse HEAD) && test_commit def && test_commit xyz && - echo "`git rev-parse HEAD` $SHA1" >.git/info/grafts && + echo "$(git rev-parse HEAD) $SHA1" >.git/info/grafts && cat >expected <<-\EOF && xyz abc -- 2.3.3.GIT -- 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 02/10] t/t1401-symbolic-ref.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t1401-symbolic-ref.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t1401-symbolic-ref.sh b/t/t1401-symbolic-ref.sh index 20b022a..e6c5830 100755 --- a/t/t1401-symbolic-ref.sh +++ b/t/t1401-symbolic-ref.sh @@ -29,7 +29,7 @@ reset_to_sane test_expect_success 'symbolic-ref refuses bare sha1' ' echo content >file && git add file && git commit -m one && - test_must_fail git symbolic-ref HEAD `git rev-parse HEAD` + test_must_fail git symbolic-ref HEAD $(git rev-parse HEAD) ' reset_to_sane -- 2.3.3.GIT -- 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 10/10] t/t3100-ls-tree-restrict.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t3100-ls-tree-restrict.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t3100-ls-tree-restrict.sh b/t/t3100-ls-tree-restrict.sh index eb73c06..325114f 100755 --- a/t/t3100-ls-tree-restrict.sh +++ b/t/t3100-ls-tree-restrict.sh @@ -28,7 +28,7 @@ test_expect_success \ echo Mi >path2/baz/b && find path? \( -type f -o -type l \) -print | xargs git update-index --add && - tree=`git write-tree` && + tree=$(git write-tree) && echo $tree' test_output () { -- 2.3.3.GIT -- 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 09/10] t/t3030-merge-recursive.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t3030-merge-recursive.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t3030-merge-recursive.sh b/t/t3030-merge-recursive.sh index 6224187..f7b0e59 100755 --- a/t/t3030-merge-recursive.sh +++ b/t/t3030-merge-recursive.sh @@ -263,7 +263,7 @@ test_expect_success 'setup 8' ' test_ln_s_add e a && test_tick && git commit -m "rename a->e, symlink a->e" && - oln=`printf e | git hash-object --stdin` + oln=$(printf e | git hash-object --stdin) ' test_expect_success 'setup 9' ' -- 2.3.3.GIT -- 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 00/10] use the $( ... ) construct for command substitution
This patch series continues the changes introduced with the merge 6753d8a85d543253d95184ec2faad6dc197f248: Merge branch 'ep/shell-command-substitution' Adjust shell scripts to use $(cmd) instead of `cmd`. This is the second series, the other will be sent separately. Elia Pinto (10): t/t1100-commit-tree-options.sh: use the $( ... ) construct for command substitution t/t1401-symbolic-ref.sh: use the $( ... ) construct for command substitution t/t1410-reflog.sh: use the $( ... ) construct for command substitution t/t1511-rev-parse-caret.sh: use the $( ... ) construct for command substitution t/t1512-rev-parse-disambiguation.sh: use the $( ... ) construct for command substitution t/t1700-split-index.sh: use the $( ... ) construct for command substitution t/t2025-worktree-add.sh: use the $( ... ) construct for command substitution t/t2102-update-index-symlinks.sh: use the $( ... ) construct for command substitution t/t3030-merge-recursive.sh: use the $( ... ) construct for command substitution t/t3100-ls-tree-restrict.sh: use the $( ... ) construct for command substitution t/t1100-commit-tree-options.sh | 4 ++-- t/t1401-symbolic-ref.sh | 2 +- t/t1410-reflog.sh | 24 t/t1511-rev-parse-caret.sh | 4 ++-- t/t1512-rev-parse-disambiguation.sh | 8 t/t1700-split-index.sh | 2 +- t/t2025-worktree-add.sh | 4 ++-- t/t2102-update-index-symlinks.sh| 2 +- t/t3030-merge-recursive.sh | 2 +- t/t3100-ls-tree-restrict.sh | 2 +- 10 files changed, 27 insertions(+), 27 deletions(-) -- 2.3.3.GIT -- 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
[L10N] Kickoff of translation for Git 2.7.0 round 2
Hi guys, Another two new messages need to be translated, so let's start Git l10n for Git v2.7.0 round 2. l10n: git.pot: v2.7.0 round 2 (2 new, 2 removed) Generate po/git.pot from v2.7.0-rc1-44-g1d88dab for git v2.7.0 l10n round 2. Signed-off-by: Jiang XinYou can get it from the usual place: https://github.com/git-l10n/git-po/ As how to update your XX.po and help to translate Git, please see "Updating a XX.po file" and other sections in “po/README" file. -- Jiang Xin -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] use the $( ... ) construct for command substitution
This patch series continues the changes introduced with the merge 6753d8a85d543253d95184ec2faad6dc197f248: Merge branch 'ep/shell-command-substitution' Adjust shell scripts to use $(cmd) instead of `cmd`. This is the third serie, the other will be sent separately. Elia Pinto (10): t3101-ls-tree-dirname.sh: use the $( ... ) construct for command substitution t3210-pack-refs.sh: use the $( ... ) construct for command substitution t3403-rebase-skip.sh: use the $( ... ) construct for command substitution t3511-cherry-pick-x.sh: use the $( ... ) construct for command substitution t3600-rm.sh: use the $( ... ) construct for command substitution t3700-add.sh: use the $( ... ) construct for command substitution t5100-mailinfo.sh: use the $( ... ) construct for command substitution t5300-pack-object.sh: use the $( ... ) construct for command substitution t5301-sliding-window.sh: use the $( ... ) construct for command substitution t5302-pack-index.sh: use the $( ... ) construct for command substitution t/t3101-ls-tree-dirname.sh | 2 +- t/t3210-pack-refs.sh | 2 +- t/t3403-rebase-skip.sh | 2 +- t/t3511-cherry-pick-x.sh | 14 +++--- t/t3600-rm.sh | 4 ++-- t/t3700-add.sh | 16 t/t5100-mailinfo.sh| 12 ++-- t/t5300-pack-object.sh | 18 +- t/t5301-sliding-window.sh | 14 +++--- t/t5302-pack-index.sh | 34 +- 10 files changed, 59 insertions(+), 59 deletions(-) -- 2.3.3.GIT -- 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 08/10] t/t2102-update-index-symlinks.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t2102-update-index-symlinks.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t2102-update-index-symlinks.sh b/t/t2102-update-index-symlinks.sh index 4d0d0a3..22f2c73 100755 --- a/t/t2102-update-index-symlinks.sh +++ b/t/t2102-update-index-symlinks.sh @@ -23,7 +23,7 @@ git update-index symlink' test_expect_success \ 'the index entry must still be a symbolic link' ' -case "`git ls-files --stage --cached symlink`" in +case "$(git ls-files --stage --cached symlink)" in 12" "*symlink) echo pass;; *) echo fail; git ls-files --stage --cached symlink; (exit 1);; esac' -- 2.3.3.GIT -- 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 06/10] t/t1700-split-index.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t1700-split-index.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh index 193d55c..8aef49f 100755 --- a/t/t1700-split-index.sh +++ b/t/t1700-split-index.sh @@ -55,7 +55,7 @@ test_expect_success 'disable split index' ' EOF test_cmp ls-files.expect ls-files.actual && - BASE=`test-dump-split-index .git/index | grep "^own" | sed "s/own/base/"` && + BASE=$(test-dump-split-index .git/index | grep "^own" | sed "s/own/base/") && test-dump-split-index .git/index | sed "/^own/d" >actual && cat >expect
[PATCH 01/10] t/t1100-commit-tree-options.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t1100-commit-tree-options.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t1100-commit-tree-options.sh b/t/t1100-commit-tree-options.sh index f8457f9..b7e9b4fc 100755 --- a/t/t1100-commit-tree-options.sh +++ b/t/t1100-commit-tree-options.sh @@ -35,11 +35,11 @@ test_expect_success \ GIT_COMMITTER_NAME="Committer Name" \ GIT_COMMITTER_EMAIL="committer@email" \ GIT_COMMITTER_DATE="2005-05-26 23:30" \ - TZ=GMT git commit-tree `cat treeid` >commitid 2>/dev/null' + TZ=GMT git commit-tree $(cat treeid) >commitid 2>/dev/null' test_expect_success \ 'read commit' \ -'git cat-file commit `cat commitid` >commit' +'git cat-file commit $(cat commitid) >commit' test_expect_success \ 'compare commit' \ -- 2.3.3.GIT -- 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 05/10] t/t1512-rev-parse-disambiguation.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t1512-rev-parse-disambiguation.sh | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/t/t1512-rev-parse-disambiguation.sh b/t/t1512-rev-parse-disambiguation.sh index 4a155c8..e221167 100755 --- a/t/t1512-rev-parse-disambiguation.sh +++ b/t/t1512-rev-parse-disambiguation.sh @@ -275,19 +275,19 @@ test_expect_success 'rev-parse --disambiguate' ' test_expect_success 'ambiguous 40-hex ref' ' TREE=$(git mktree err` = $REF && + test $(git rev-parse $REF 2>err) = $REF && grep "refname.*${REF}.*ambiguous" err ' test_expect_success 'ambiguous short sha1 ref' ' TREE=$(git mktree err` = $VAL && + test $(git rev-parse $REF 2>err) = $VAL && grep "refname.*${REF}.*ambiguous" err ' -- 2.3.3.GIT -- 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 04/10] t/t1511-rev-parse-caret.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t1511-rev-parse-caret.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t1511-rev-parse-caret.sh b/t/t1511-rev-parse-caret.sh index 15973f2..7043ba7 100755 --- a/t/t1511-rev-parse-caret.sh +++ b/t/t1511-rev-parse-caret.sh @@ -6,11 +6,11 @@ test_description='tests for ref^{stuff}' test_expect_success 'setup' ' echo blob >a-blob && - git tag -a -m blob blob-tag `git hash-object -w a-blob` && + git tag -a -m blob blob-tag $(git hash-object -w a-blob) && mkdir a-tree && echo moreblobs >a-tree/another-blob && git add . && - TREE_SHA1=`git write-tree` && + TREE_SHA1=$(git write-tree) && git tag -a -m tree tree-tag "$TREE_SHA1" && git commit -m Initial && git tag -a -m commit commit-tag && -- 2.3.3.GIT -- 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 03/10] t/t1410-reflog.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t1410-reflog.sh | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh index b79049f..fbed8d7 100755 --- a/t/t1410-reflog.sh +++ b/t/t1410-reflog.sh @@ -62,18 +62,18 @@ test_expect_success setup ' git add . && test_tick && git commit -m rabbit && - H=`git rev-parse --verify HEAD` && - A=`git rev-parse --verify HEAD:A` && - B=`git rev-parse --verify HEAD:A/B` && - C=`git rev-parse --verify HEAD:C` && - D=`git rev-parse --verify HEAD:A/D` && - E=`git rev-parse --verify HEAD:A/B/E` && + H=$(git rev-parse --verify HEAD) && + A=$(git rev-parse --verify HEAD:A) && + B=$(git rev-parse --verify HEAD:A/B) && + C=$(git rev-parse --verify HEAD:C) && + D=$(git rev-parse --verify HEAD:A/D) && + E=$(git rev-parse --verify HEAD:A/B/E) && check_fsck && test_chmod +x C && git add C && test_tick && git commit -m dragon && - L=`git rev-parse --verify HEAD` && + L=$(git rev-parse --verify HEAD) && check_fsck && rm -f C A/B/E && @@ -81,15 +81,15 @@ test_expect_success setup ' echo horse >A/G && git add F A/G && test_tick && git commit -a -m sheep && - F=`git rev-parse --verify HEAD:F` && - G=`git rev-parse --verify HEAD:A/G` && - I=`git rev-parse --verify HEAD:A` && - J=`git rev-parse --verify HEAD` && + F=$(git rev-parse --verify HEAD:F) && + G=$(git rev-parse --verify HEAD:A/G) && + I=$(git rev-parse --verify HEAD:A) && + J=$(git rev-parse --verify HEAD) && check_fsck && rm -f A/G && test_tick && git commit -a -m monkey && - K=`git rev-parse --verify HEAD` && + K=$(git rev-parse --verify HEAD) && check_fsck && check_have A B C D E F G H I J K L && -- 2.3.3.GIT -- 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 09/10] t5301-sliding-window.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t5301-sliding-window.sh | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/t/t5301-sliding-window.sh b/t/t5301-sliding-window.sh index 2fc5af6..cae8c2e 100755 --- a/t/t5301-sliding-window.sh +++ b/t/t5301-sliding-window.sh @@ -16,12 +16,12 @@ test_expect_success \ git update-index --add $i || return 1 done && echo d >d && cat c >>d && git update-index --add d && - tree=`git write-tree` && - commit1=`git commit-tree $tree http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] t3210-pack-refs.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t3210-pack-refs.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t3210-pack-refs.sh b/t/t3210-pack-refs.sh index db244d2..9b182a0 100755 --- a/t/t3210-pack-refs.sh +++ b/t/t3210-pack-refs.sh @@ -27,7 +27,7 @@ SHA1= test_expect_success \ 'see if git show-ref works as expected' \ 'git branch a && - SHA1=`cat .git/refs/heads/a` && + SHA1=$(cat .git/refs/heads/a) && echo "$SHA1 refs/heads/a" >expect && git show-ref a >result && test_cmp expect result' -- 2.3.3.GIT -- 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 06/10] t3700-add.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t3700-add.sh | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/t/t3700-add.sh b/t/t3700-add.sh index f7ff1f5..f14a665 100755 --- a/t/t3700-add.sh +++ b/t/t3700-add.sh @@ -25,7 +25,7 @@ test_expect_success \ echo foo >xfoo1 && chmod 755 xfoo1 && git add xfoo1 && -case "`git ls-files --stage xfoo1`" in +case "$(git ls-files --stage xfoo1)" in 100644" "*xfoo1) echo pass;; *) echo fail; git ls-files --stage xfoo1; (exit 1);; esac' @@ -33,7 +33,7 @@ test_expect_success \ test_expect_success 'git add: filemode=0 should not get confused by symlink' ' rm -f xfoo1 && test_ln_s_add foo xfoo1 && - case "`git ls-files --stage xfoo1`" in + case "$(git ls-files --stage xfoo1)" in 12" "*xfoo1) echo pass;; *) echo fail; git ls-files --stage xfoo1; (exit 1);; esac @@ -45,7 +45,7 @@ test_expect_success \ echo foo >xfoo2 && chmod 755 xfoo2 && git update-index --add xfoo2 && -case "`git ls-files --stage xfoo2`" in +case "$(git ls-files --stage xfoo2)" in 100644" "*xfoo2) echo pass;; *) echo fail; git ls-files --stage xfoo2; (exit 1);; esac' @@ -53,7 +53,7 @@ test_expect_success \ test_expect_success 'git add: filemode=0 should not get confused by symlink' ' rm -f xfoo2 && test_ln_s_add foo xfoo2 && - case "`git ls-files --stage xfoo2`" in + case "$(git ls-files --stage xfoo2)" in 12" "*xfoo2) echo pass;; *) echo fail; git ls-files --stage xfoo2; (exit 1);; esac @@ -63,7 +63,7 @@ test_expect_success \ 'git update-index --add: Test that executable bit is not used...' \ 'git config core.filemode 0 && test_ln_s_add xfoo2 xfoo3 && # runs git update-index --add -case "`git ls-files --stage xfoo3`" in +case "$(git ls-files --stage xfoo3)" in 12" "*xfoo3) echo pass;; *) echo fail; git ls-files --stage xfoo3; (exit 1);; esac' @@ -173,14 +173,14 @@ test_expect_success 'git add with filemode=0, symlinks=0 prefers stage 2 over st test_expect_success 'git add --refresh' ' >foo && git add foo && git commit -a -m "commit all" && - test -z "`git diff-index HEAD -- foo`" && + test -z "$(git diff-index HEAD -- foo)" && git read-tree HEAD && - case "`git diff-index HEAD -- foo`" in + case "$(git diff-index HEAD -- foo)" in :100644" "*"M foo") echo pass;; *) echo fail; (exit 1);; esac && git add --refresh -- foo && - test -z "`git diff-index HEAD -- foo`" + test -z "$(git diff-index HEAD -- foo)" ' test_expect_success 'git add --refresh with pathspec' ' -- 2.3.3.GIT -- 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 10/10] t5302-pack-index.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t5302-pack-index.sh | 34 +- 1 file changed, 17 insertions(+), 17 deletions(-) diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh index 3dc5ec4..c2fc584 100755 --- a/t/t5302-pack-index.sh +++ b/t/t5302-pack-index.sh @@ -14,21 +14,21 @@ test_expect_success \ i=1 && while test $i -le 100 do - iii=`printf '%03i' $i` + iii=$(printf '%03i' $i) test-genrandom "bar" 200 > wide_delta_$iii && test-genrandom "baz $iii" 50 >> wide_delta_$iii && test-genrandom "foo"$i 100 > deep_delta_$iii && - test-genrandom "foo"`expr $i + 1` 100 >> deep_delta_$iii && - test-genrandom "foo"`expr $i + 2` 100 >> deep_delta_$iii && + test-genrandom "foo"$(expr $i + 1) 100 >> deep_delta_$iii && + test-genrandom "foo"$(expr $i + 2) 100 >> deep_delta_$iii && echo $iii >file_$iii && test-genrandom "$iii" 8192 >>file_$iii && git update-index --add file_$iii deep_delta_$iii wide_delta_$iii && - i=`expr $i + 1` || return 1 + i=$(expr $i + 1) || return 1 done && { echo 101 && test-genrandom 100 8192; } >file_101 && git update-index --add file_101 && - tree=`git write-tree` && - commit=`git commit-tree $tree obj-list && @@ -152,10 +152,10 @@ test_expect_success \ '[index v1] 2) create a stealth corruption in a delta base reference' \ '# This test assumes file_101 is a delta smaller than 16 bytes. # It should be against file_100 but we substitute its base for file_099 - sha1_101=`git hash-object file_101` && - sha1_099=`git hash-object file_099` && - offs_101=`index_obj_offset 1.idx $sha1_101` && - nr_099=`index_obj_nr 1.idx $sha1_099` && + sha1_101=$(git hash-object file_101) && + sha1_099=$(git hash-object file_099) && + offs_101=$(index_obj_offset 1.idx $sha1_101) && + nr_099=$(index_obj_nr 1.idx $sha1_099) && chmod +w ".git/objects/pack/pack-${pack1}.pack" && dd of=".git/objects/pack/pack-${pack1}.pack" seek=$(($offs_101 + 1)) \ if=".git/objects/pack/pack-${pack1}.idx" \ @@ -193,10 +193,10 @@ test_expect_success \ '[index v2] 2) create a stealth corruption in a delta base reference' \ '# This test assumes file_101 is a delta smaller than 16 bytes. # It should be against file_100 but we substitute its base for file_099 - sha1_101=`git hash-object file_101` && - sha1_099=`git hash-object file_099` && - offs_101=`index_obj_offset 1.idx $sha1_101` && - nr_099=`index_obj_nr 1.idx $sha1_099` && + sha1_101=$(git hash-object file_101) && + sha1_099=$(git hash-object file_099) && + offs_101=$(index_obj_offset 1.idx $sha1_101) && + nr_099=$(index_obj_nr 1.idx $sha1_099) && chmod +w ".git/objects/pack/pack-${pack1}.pack" && dd of=".git/objects/pack/pack-${pack1}.pack" seek=$(($offs_101 + 1)) \ if=".git/objects/pack/pack-${pack1}.idx" \ @@ -222,11 +222,11 @@ test_expect_success \ 'rm -f .git/objects/pack/* && git index-pack --index-version=2 --stdin < "test-1-${pack1}.pack" && git verify-pack ".git/objects/pack/pack-${pack1}.pack" && - obj=`git hash-object file_001` && - nr=`index_obj_nr ".git/objects/pack/pack-${pack1}.idx" $obj` && + obj=$(git hash-object file_001) && + nr=$(index_obj_nr ".git/objects/pack/pack-${pack1}.idx" $obj) && chmod +w ".git/objects/pack/pack-${pack1}.idx" && printf | dd of=".git/objects/pack/pack-${pack1}.idx" conv=notrunc \ -bs=1 count=4 seek=$((8 + 256 * 4 + `wc -l /dev/null || exit 1 done http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] t3101-ls-tree-dirname.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t3101-ls-tree-dirname.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t3101-ls-tree-dirname.sh b/t/t3101-ls-tree-dirname.sh index 026f9f8..425d858 100755 --- a/t/t3101-ls-tree-dirname.sh +++ b/t/t3101-ls-tree-dirname.sh @@ -35,7 +35,7 @@ test_expect_success 'setup' ' echo 222 >path3/2.txt && find *.txt path* \( -type f -o -type l \) -print | xargs git update-index --add && - tree=`git write-tree` && + tree=$(git write-tree) && echo $tree ' -- 2.3.3.GIT -- 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 04/10] t3511-cherry-pick-x.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t3511-cherry-pick-x.sh | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/t/t3511-cherry-pick-x.sh b/t/t3511-cherry-pick-x.sh index b7dff09..9cce5ae 100755 --- a/t/t3511-cherry-pick-x.sh +++ b/t/t3511-cherry-pick-x.sh @@ -77,7 +77,7 @@ test_expect_success setup ' test_expect_success 'cherry-pick -x inserts blank line after one line subject' ' pristine_detach initial && - sha1=`git rev-parse mesg-one-line^0` && + sha1=$(git rev-parse mesg-one-line^0) && git cherry-pick -x mesg-one-line && cat <<-EOF >expect && $mesg_one_line @@ -114,7 +114,7 @@ test_expect_success 'cherry-pick -s inserts blank line after non-conforming foot test_expect_success 'cherry-pick -x inserts blank line when conforming footer not found' ' pristine_detach initial && - sha1=`git rev-parse mesg-no-footer^0` && + sha1=$(git rev-parse mesg-no-footer^0) && git cherry-pick -x mesg-no-footer && cat <<-EOF >expect && $mesg_no_footer @@ -139,7 +139,7 @@ test_expect_success 'cherry-pick -s inserts blank line when conforming footer no test_expect_success 'cherry-pick -x -s inserts blank line when conforming footer not found' ' pristine_detach initial && - sha1=`git rev-parse mesg-no-footer^0` && + sha1=$(git rev-parse mesg-no-footer^0) && git cherry-pick -x -s mesg-no-footer && cat <<-EOF >expect && $mesg_no_footer @@ -164,7 +164,7 @@ test_expect_success 'cherry-pick -s adds sob when last sob doesnt match committe test_expect_success 'cherry-pick -x -s adds sob when last sob doesnt match committer' ' pristine_detach initial && - sha1=`git rev-parse mesg-with-footer^0` && + sha1=$(git rev-parse mesg-with-footer^0) && git cherry-pick -x -s mesg-with-footer && cat <<-EOF >expect && $mesg_with_footer @@ -187,7 +187,7 @@ test_expect_success 'cherry-pick -s refrains from adding duplicate trailing sob' test_expect_success 'cherry-pick -x -s adds sob even when trailing sob exists for committer' ' pristine_detach initial && - sha1=`git rev-parse mesg-with-footer-sob^0` && + sha1=$(git rev-parse mesg-with-footer-sob^0) && git cherry-pick -x -s mesg-with-footer-sob && cat <<-EOF >expect && $mesg_with_footer_sob @@ -200,7 +200,7 @@ test_expect_success 'cherry-pick -x -s adds sob even when trailing sob exists fo test_expect_success 'cherry-pick -x treats "(cherry picked from..." line as part of footer' ' pristine_detach initial && - sha1=`git rev-parse mesg-with-cherry-footer^0` && + sha1=$(git rev-parse mesg-with-cherry-footer^0) && git cherry-pick -x mesg-with-cherry-footer && cat <<-EOF >expect && $mesg_with_cherry_footer @@ -223,7 +223,7 @@ test_expect_success 'cherry-pick -s treats "(cherry picked from..." line as part test_expect_success 'cherry-pick -x -s treats "(cherry picked from..." line as part of footer' ' pristine_detach initial && - sha1=`git rev-parse mesg-with-cherry-footer^0` && + sha1=$(git rev-parse mesg-with-cherry-footer^0) && git cherry-pick -x -s mesg-with-cherry-footer && cat <<-EOF >expect && $mesg_with_cherry_footer -- 2.3.3.GIT -- 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 07/10] t5100-mailinfo.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t5100-mailinfo.sh | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh index e97cfb2..4e52b3b 100755 --- a/t/t5100-mailinfo.sh +++ b/t/t5100-mailinfo.sh @@ -9,9 +9,9 @@ test_description='git mailinfo and git mailsplit test' test_expect_success 'split sample box' \ 'git mailsplit -o. "$TEST_DIRECTORY"/t5100/sample.mbox >last && - last=`cat last` && + last=$(cat last) && echo total is $last && - test `cat last` = 17' + test $(cat last) = 17' check_mailinfo () { mail=$1 opt=$2 @@ -23,7 +23,7 @@ check_mailinfo () { } -for mail in `echo 00*` +for mail in $(echo 00*) do test_expect_success "mailinfo $mail" ' check_mailinfo $mail "" && @@ -47,11 +47,11 @@ test_expect_success 'split box with rfc2047 samples' \ 'mkdir rfc2047 && git mailsplit -orfc2047 "$TEST_DIRECTORY"/t5100/rfc2047-samples.mbox \ >rfc2047/last && - last=`cat rfc2047/last` && + last=$(cat rfc2047/last) && echo total is $last && - test `cat rfc2047/last` = 11' + test $(cat rfc2047/last) = 11' -for mail in `echo rfc2047/00*` +for mail in $(echo rfc2047/00*) do test_expect_success "mailinfo $mail" ' git mailinfo -u $mail-msg $mail-patch <$mail >$mail-info && -- 2.3.3.GIT -- 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 05/10] t3600-rm.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t3600-rm.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t3600-rm.sh b/t/t3600-rm.sh index 9d90d2c..2e47a2b 100755 --- a/t/t3600-rm.sh +++ b/t/t3600-rm.sh @@ -115,7 +115,7 @@ test_expect_success '"rm" command printed' ' git add test-file && git commit -m "add file for rm test" && git rm test-file > rm-output && - test `grep "^rm " rm-output | wc -l` = 1 && + test $(grep "^rm " rm-output | wc -l) = 1 && rm -f test-file rm-output && git commit -m "remove file from rm test" ' @@ -125,7 +125,7 @@ test_expect_success '"rm" command suppressed with --quiet' ' git add test-file && git commit -m "add file for rm --quiet test" && git rm --quiet test-file > rm-output && - test `wc -l < rm-output` = 0 && + test $(wc -l < rm-output) = 0 && rm -f test-file rm-output && git commit -m "remove file from rm --quiet test" ' -- 2.3.3.GIT -- 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 08/10] t5300-pack-object.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t5300-pack-object.sh | 18 +- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh index 20c1961..fc2be63 100755 --- a/t/t5300-pack-object.sh +++ b/t/t5300-pack-object.sh @@ -8,7 +8,7 @@ test_description='git pack-object ' . ./test-lib.sh -TRASH=`pwd` +TRASH=$(pwd) test_expect_success \ 'setup' \ @@ -20,8 +20,8 @@ test_expect_success \ test-genrandom "seed b" 2097152 > b_big && git update-index --add a a_big b b_big c && cat c >d && echo foo >>d && git update-index --add d && - tree=`git write-tree` && - commit=`git commit-tree $tree expect' @@ -147,7 +147,7 @@ test_expect_success \ git diff-tree --root -p $commit && while read object do - t=`git cat-file -t $object` && + t=$(git cat-file -t $object) && git cat-file $t $object || return 1 done current && @@ -162,7 +162,7 @@ test_expect_success \ git diff-tree --root -p $commit && while read object do - t=`git cat-file -t $object` && + t=$(git cat-file -t $object) && git cat-file $t $object || return 1 done current && @@ -177,7 +177,7 @@ test_expect_success \ git diff-tree --root -p $commit && while read object do - t=`git cat-file -t $object` && + t=$(git cat-file -t $object) && git cat-file $t $object || return 1 done current && @@ -252,8 +252,8 @@ test_expect_success \ test_expect_success \ 'verify-pack catches a corrupted sum of the index file itself' \ -'l=`wc -c test-3.pack && printf "%20s" "" | dd of=test-3.idx count=20 bs=1 conv=notrunc seek=$l && if git verify-pack test-3.pack -- 2.3.3.GIT -- 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 03/10] t3403-rebase-skip.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/t3403-rebase-skip.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/t/t3403-rebase-skip.sh b/t/t3403-rebase-skip.sh index 3968020..1f5122b 100755 --- a/t/t3403-rebase-skip.sh +++ b/t/t3403-rebase-skip.sh @@ -67,7 +67,7 @@ test_expect_success 'rebase --skip with --merge' ' ' test_expect_success 'merge and reference trees equal' ' - test -z "`git diff-tree skip-merge skip-reference`" + test -z "$(git diff-tree skip-merge skip-reference)" ' test_expect_success 'moved back to branch correctly' ' -- 2.3.3.GIT -- 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
Building Git with HTTPS support: avoiding libcurl?
I'm trying to build Git (2.6.4) on GNU/Linux, but without any requirements (other than basic libc etc.) on the local system. This works fine except for one thing: git-remote-https. In order to build this I need to have libcurl, but libcurl is a MONSTER library with an enormous number of prerequisites (see below). Just wondering if anyone has considered an alternative to libcurl; maybe I'm wrong but it seems to me that HTTPS support for Git would require only a tiny fraction of the libcurl features and maybe there's an alternative available which would be more targeted? I realize this is not a short-term thing in that there won't be an API compatible library that can just be dropped in. This is more a forward -looking question. For now I'm looking to see if I can rebuild libcurl myself without most of these dependencies such as Kerberos, LDAP, etc. $ ldd /usr/lib/x86_64-linux-gnu/libcurl.so.4 linux-vdso.so.1 => (0x7fff37d81000) libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 (0x7f682b921000) librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 (0x7f682b704000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x7f682b49a000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x7f682b058000) libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x7f682ae0e000) liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x7f682abfe000) libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x7f682a9ac000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f682a792000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f682a573000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f682a1a9000) libgnutls-deb0.so.28 => /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28 (0x7f6829e8d000) libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 (0x7f6829c59000) libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 (0x7f6829a23000) libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x7f68297a3000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f682959e000) libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 (0x7f68292cc000) libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 (0x7f682909d000) libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x7f6828e98000) libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 (0x7f6828c8d000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f6828a71000) libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (0x7f6828855000) libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 (0x7f6828615000) /lib64/ld-linux-x86-64.so.2 (0x559b03259000) libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 (0x7f68283b) libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 (0x7f682819c000) libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x7f6827f98000) libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 (0x7f6827d8e000) libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 (0x7f6827b04000) libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 (0x7f6827861000) libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 (0x7f682762d000) libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 (0x7f6827418000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x7f682721) libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 (0x7f6826fe6000) libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 (0x7f6826dd7000) libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 (0x7f6826b8c000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f68268be000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x7f6826686000) -- 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: RefTree: Alternate ref backend
Shawn Pearcewrites: > On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamano wrote: >> Shawn Pearce writes: >> But really, aside from slightly helping disambiguate references from paths in the command line, what is it good for? >>> >>> Nothing really; today refs/ prefix is used to encourage to the tools >>> that you really meant refs/heads/master and not >>> refs/heads/heads/master or some other crazy construct. You can thank >>> the DWIMery inside the ref rev parse logic for needing this. >> >> Aren't you two forgetting one minor thing, though? >> >> A layout without refs/, i.e. $GIT_DIR/{heads,tags,...}, will force >> us to keep track of where the tips of histories are anchored for >> reachability purposes, every time you would add a new hierarchy >> (e.g. $GIT_DIR/changes)--and those unfortunate souls who run a >> slightly older version of Git that is unaware of 'changes' hierarchy >> would weep after running "git gc", no? > > You still store them under refs/ Well I know; the comment was merely a reaction to the exchange between you two, "What is refs/ good for?", "Nothing really". You'd benefit by having "refs/" that is known to contain all the anchoring points for reachability without knowing what subhierarchy it may contain in the future, that is what it is good for. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Rebase Issue
Hi, On Tue, Dec 22, 2015 at 6:53 PM, Pierre-Luc Loyerwrote: > Hi, > > I've encountered a situation using rebase for which I don't understand the > results, even after reading the documentation. > I'm currently working in my feature branch and then I want to squash commits, > thus I use interactive rebase. After successfully completing the rebase, I > end up in a detached HEAD state, rather than back on my branch, which is > confusing. The command that is causing me to be in detached HEAD mode is: git > rebase -i HEAD~2 HEAD > From the documentation, I read that my second parameter (HEAD) is the > parameter: > >git rebase [-i | --interactive] [options] [--exec ] [--onto ] > >[] [] > >If is specified, git rebase will perform an automatic git > checkout before doing anything else. Otherwise it remains on the > current branch. > Working branch; defaults to HEAD. > >Upon completion, will be the current branch. > > Here is a full example than can be used to easily repro the issue. Go to an > empty folder. > git init > git echo text > file.txt > git add . > git commit -m "Add file.txt" > git echo text2 > file.txt > git commit -am "Modify file.txt" > git echo text3 > file.txt > git commit -am "Remodify file.txt" > > Now the interesting part: > $ git rebase -i HEAD~2 HEAD > [detached HEAD 9178b93] Modify file > 1 file changed, 1 insertion(+), 1 deletion(-) > Successfully rebased and updated detached HEAD. > > From the documentation it says that (which is HEAD) will be checked > out before doing anything and that upon completion, will be the > current branch. However, this doesn't seem to happen. In fact, it seems more > like the following is happening during the rebase: > 1) detach HEAD > 2) rebase > 3) reattach to > > If is HEAD, then is does nothing and remains detached. > I find this behavior confusing since I would expect it to return to whatever > HEAD was pointing to at the start of the command, such as my branch. Also, > the documentation says that the parameter defaults to HEAD, so > passing 'HEAD' explicitly should result in the same behavior as not passing > it: > Working branch; defaults to HEAD. You are right, it is probably a bug. I guess usually people just use "git rebase -i HEAD~2" or "git rebase -i master" and don't give the [] argument when using -i. If you are interested in helping us debug this you might first want to check if older git versions behaved like 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
[PATCH V2 1/2] glossary: define the term shallow clone
There are several places in the documentation that the term shallow clone is used. Defining the term enables its use elsewhere with a known definition. --- Documentation/glossary-content.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index e225974..cecc83d 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -531,6 +531,10 @@ The most notable example is `HEAD`. "Secure Hash Algorithm 1"; a cryptographic hash function. In the context of Git used as a synonym for <>. +[[def_shallow_clone]]shallow clone:: + A clone of a < > which creates a + < >. + [[def_shallow_repository]]shallow repository:: A shallow < > has an incomplete history some of whose < > have < > cauterized away (in other -- 2.6.3.368.gf34be46 -- 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: RefTree: Alternate ref backend
On Tue, Dec 22, 2015 at 9:17 AM, Michael Haggertywrote: > > etc. But we store branches into the main "refs/remotes/origin/" > namespace, leaving no reserved space for the remote "HEAD" (not to > mention other namespaces that might appear on the remote, such as > "refs/changes/*", "refs/pull/*", a separate record of the remote's > "refs/tags/*", etc). > > Maybe that is why my gut reaction to your proposal to elide the "refs" > part of the reference hierarchy and store "HEAD" as (effectively) > "refs/..HEAD" was negative, even though I can't think of any practical > objections. Good point; if the client's refs/remotes/origin/ namespace more closely mirrored the remote's own namespace (refs/remotes/origin/heads/master), this seems a lot less fishy. The mapping certainly makes a bit more sense. Etc. Its a user visible shift however; what was origin/master is now origin/heads/master. Which is part of the reason why the mapping works the way it does today. We hardly ever call a branch here heads/master, we just call it master. So we call origin's master, origin/master. :) > At a deeper level, the "refs/" part of reference names is actually > pretty useless in general. I suppose it originated in the practice of > storing loose references under "refs/" to keep them separate from other > metadata in $GIT_DIR. Correct. In the beginning you used echo $sha1 >.git/HEAD and it was good. Later more refs came along and they had to go somewhere, and so .git/refs was born with .git/refs/heads/master. Existing tools that knew how to write to .git/HEAD given the name HEAD could magically work with refs/heads/master too, and it was good. But that was an awefully long name to type, so shorthand of "master" for maybe refs/heads/master or maybe refs/tags/master or maybe no prefix at all (hi HEAD) came along. Basically its the origin story of Git. :) > But really, aside from slightly helping > disambiguate references from paths in the command line, what is it good > for? Nothing really; today refs/ prefix is used to encourage to the tools that you really meant refs/heads/master and not refs/heads/heads/master or some other crazy construct. You can thank the DWIMery inside the ref rev parse logic for needing this. > The client not only has to remember the server's reftree, but also must > verify that it still has all of the objects implied by that reftree, in > case a reference somehow got deleted under "refs/remotes/origin/*". At > that point, there is no special reason to use a SHA-1 in the > negotiation; any unique token generated by the server would suffice if > the server can connect it back to a set of references that was sent to > the client in the past. True, but its a nicer implementation if the token exchanged has simple meaning to the server. And its just a diff-tree at the server to compute the modifications the client might need to learn about. I see your point about the client being able to use that to say "If I not only have this, I also have all of the objects". It vastly simplifies the client's negotiation with the server. The client is negotiating the common ancestor of the reftree and that immediately gets the main graph ancestor negotiation system very close to a good set. The client may still be usefully ahead on other branches, e.g. she has pulled from the upstream and is now pulling from a lieutenant's tree, who also recently pulled from the upstream. > In practice, in my first "haves" announcement I would probably list a > few "famous" namespaces in the hope that one or more of them are > recognized by the server: > > have-tree > have-tree > have-tree > have-tree > have-tree Yes, but we also have to be careful about how long we get the "famous" list get. :) >> [...] >> FWIW, JGit is able to scan the canonical trees out of a pack file and >> inflate them in approximately the same time it takes to scan the >> packed-refs file for some 70k references. So we don't really slow down >> much to use this. And there's huge gains to be had by taking advantage >> of the tree structure and only inflating the components you need to >> answer a particular read. > > Yes, that's another nice aspect of the design. > > I do worry a bit that the hierarchical storage only helps if people > shard their reference namespace reasonably. Somebody who stores 100k > references in a single reference "directory" (imagine a > "refs/ci-tests/*") is going to suffer from expensive reference update > performance. But I guess they will suffer from poor performance within > Git as well, and that will probably encourage them to improve their > practices :-) I suppose this is not really much different than people > who store 100k files within a single directory of their working tree. Yup. Gerrit Code Review shards refs/changes/ across 100 directories for this reason as local filesystems don't like large numbers of files or directories in a directory. But at 100k change entries you
Re: [PATCH v2 0/2] do_compare_entry: use already-computed path
David Turnerwrites: > On Mon, 2015-12-21 at 15:34 -0800, Junio C Hamano wrote: >> Great. Thanks, will queue w/o 1/2 (though I do not think it would >> hurt). >> >> On Mon, Dec 21, 2015 at 3:33 PM, David Turner < >> dtur...@twopensource.com> wrote: >> > On Mon, 2015-12-21 at 15:27 -0800, Junio C Hamano wrote: >> > > Thanks. Does the number still stay at 25% improvement? >> > >> > Yes. > > BTW, that function, via ce_in_traverse_path, gets called about 40 > million times when switching (checking out) between master and a > branch that's a few months old (and that contains relatively small > changes from master-as-of-then. Our repo only has approximately a > quarter -million files. This seems somewhat unreasonable to me, > but I haven't really looked into what's going on. Do you happen > to know why this is and whether it is likely to be a bug? That does sound excessive; smells like somebody is being overly cautious (i.e. a performance bug). We might be seeing something similar to what e53e6b44 observed and attempted to correct. I dunno. -- 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] l10n: de.po: translate 68 new messages
Am 22. Dezember 2015 um 18:39 schrieb Ralf Thielow: > #: builtin/tag.c:25 > -#, fuzzy > msgid "" > "git tag -l [-n[]] [--contains ] [--points-at ]\n" > "\t\t[--format=] [--[no-]merged []] [...]" > msgstr "" > "git tag -l [-n[]] [--contains ] [--points-at ]\n" > -"\t\t[...]" > +"\t\t[--format=] [--[no-]merged []] [Muster>...]" > Should be "". Will be fixed in v2. -- 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: RefTree: Alternate ref backend
Martin Fickwrites: > ... What if we added > a leading slash for absolute references? Then I could do > something like: > > /HEAD > /refs/heads/master > /refs/tags/v1.0.0 > /refs/remotes/origin/master Yeah, that is one way to allow a tool to be absolutely certain there is no funny DWIMmery going on. > This is a long term idea, but it might make sense to > consider it now just for the sake of storing refs, it would > eliminate the need for the ".." notation for "refs/..HEAD". I do not see how the absolute notation has anything to do with eliminating "the need for the '..' notation" at all, though. The funny "..HEAD" was brought up only because Shawn wanted to omit a single level of dereferencing of a tree object, so that the top-level tree for his ref backend would have "heads/", "tags/", etc. in it, and because "HEAD" is not next to "heads/" and "tags/", it needed some funny notation to avoid squatting on "HEAD" that should mean "refs/HEAD" in the notation. > Now if we could only figure out a way to tell plumbing that > something is a SHA, not a ref? :) You do not need :) there; I think we discussed something along that line in the past few weeks (see the list archive). -- 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 07/10] t5100-mailinfo.sh: use the $( ... ) construct for command substitution
Am 22.12.2015 um 16:27 schrieb Elia Pinto: -for mail in `echo 00*` +for mail in $(echo 00*) -for mail in `echo rfc2047/00*` +for mail in $(echo rfc2047/00*) True, these are equvalence transformations. But a better way to get rid of the back-quotes is to write these lines as for mail in echo 00* for mail in echo rfc2047/00* No? -- Hannes -- 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: RefTree: Alternate ref backend
On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamanowrote: > Shawn Pearce writes: > >>> But really, aside from slightly helping >>> disambiguate references from paths in the command line, what is it good >>> for? >> >> Nothing really; today refs/ prefix is used to encourage to the tools >> that you really meant refs/heads/master and not >> refs/heads/heads/master or some other crazy construct. You can thank >> the DWIMery inside the ref rev parse logic for needing this. > > Aren't you two forgetting one minor thing, though? > > A layout without refs/, i.e. $GIT_DIR/{heads,tags,...}, will force > us to keep track of where the tips of histories are anchored for > reachability purposes, every time you would add a new hierarchy > (e.g. $GIT_DIR/changes)--and those unfortunate souls who run a > slightly older version of Git that is unaware of 'changes' hierarchy > would weep after running "git gc", no? You still store them under refs/ All of the code that is handed a ref name knows its a ref name and not a sha-1 object name in the objects directory. The catch is a few things accept HEAD, MERGE_HEAD, FETCH_HEAD, etc. Those have to be handled even though they aren't in the refs/ directory. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git Rebase Issue
Pierre-Luc Loyerwrites: > From the documentation it says that (which is HEAD) will be checked > out before doing anything and that upon completion, will be the > current branch. However, this doesn't seem to happen. In fact, it seems more > like the following is happening during the rebase: > 1) detach HEAD > 2) rebase > 3) reattach to You do not have to say "HEAD" for "", if you are rebasing the current branch. Either leave it unsaid, or name the branch. Passing "HEAD" (or any of its variants that names the exact commit at the tip of the current branch, without using the name of the current branch, e.g. "master^0") as the "branch to rebase" is an advanced technique to use when you want to avoid messing with the branch itself. It is deliberate that the HEAD is left detached. You'd (once you learn Git sufficently and got comfortable with working on a detached HEAD, that is) often find yourself doing things like this: 1. rebase temporarily on detached HEAD $ git rebase -i HEAD~2 HEAD ;# amend the tip two 2. double check the result and convince yourself that it is better than the original $ git diff master HEAD $ git log master.. >updated $ git log -2 master >original $ diff -u original updated 3-a. once satisfied, update the branch $ git checkout -B master 3-b. or abandon if the result is undesirable. $ git checkout master -- 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 07/10] t5100-mailinfo.sh: use the $( ... ) construct for command substitution
Am 22.12.2015 um 19:35 schrieb Johannes Sixt: Am 22.12.2015 um 16:27 schrieb Elia Pinto: -for mail in `echo 00*` +for mail in $(echo 00*) -for mail in `echo rfc2047/00*` +for mail in $(echo rfc2047/00*) True, these are equvalence transformations. But a better way to get rid of the back-quotes is to write these lines as for mail in echo 00* for mail in echo rfc2047/00* Ahem... both of these lines without the 'echo', of course! No? -- Hannes -- 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] pretty: Pass graph width to pretty formatting for use in '%>|(N)'
Duy Nguyenwrites: > (I'm joining the newer thread [1] back to this one, thanks for > reminding me about this) > > [1] http://thread.gmane.org/gmane.comp.version-control.git/282771 > > On Tue, Sep 22, 2015 at 2:40 AM, Junio C Hamano wrote: >> Josef Kufner writes: >> >>> Pass graph width to pretty formatting, so N in '%>|(N)' includes columns >>> consumed by graph rendered when --graph option is in use. >>> >>> Example: >>> git log --all --graph --pretty='format: [%>|(20)%h] %ar%d' >>> >>> All commit hashes should be aligned at 20th column from edge of the >>> terminal, not from the edge of the graph. >>> >>> Signed-off-by: Josef Kufner >>> --- >> >> [CC'ed Duy for ideas, as the "%>|(ALIGN)" thing is his invention] >> ... >> >> I have a suspicion that 50% of the users would appreciate this >> change, and the remainder of the users see this break their >> expectation. To avoid such a regression, we may be better off if we >> introduced a new alignment operator that is different from '%>|(N)' >> so that this new behaviour is available to those who want to use it, >> without negatively affecting existing uses. > > I tend to agree with Josef. >|(N) is about columns relative to the > left edge of the screen. You can already use >(N) to be relative to > the left edge of the space given to the commit. OK. I didn't check if >(N) with that old patch still behaves that way, but if that is sensible, then it is not breaking anything, so it may be a good idea to salvage it. I dunno. -- 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 v7] ls-files: Add eol diagnostics
Torsten Bögershausenwrites: > When working in a cross-platform environment, a user wants to > check if text files are stored normalized in the repository and if > .gitattributes are set appropriately. > > Make it possible to let Git show the line endings in the index and > in the working tree and the effective text/eol attributes. > > The end of line ("eolinfo") are shown like this: > "binary" binary file > "text-no-eol" text file without any EOL > "text-lf" text file with LF > "text-crlf"text file with CRLF > "text-crlf-lf" text file with mixed line endings. > > The effective text/eol attribute is one of these: > "", "-text", "text", "text=auto", "eol=lf", "eol=crlf" > > git ls-files --eol gives an output like this: > > i/text-no-eol w/text-no-eol attr/text=auto t/t5100/empty > i/binaryw/binaryattr/-text t/test-binary-2.png > i/text-lf w/text-lf attr/eol=lft/t5100/rfc2047-info-0007 > i/text-lf w/text-crlf attr/eol=crlf doit.bat > i/text-crlf-lf w/text-crlf-lf attr/ locale/XX.po > > Note that the output is meant to be human-readable and may change. Wait, what? I've been assuming that these output being designed was to be read by machine, because this new feature is implemented as a part of the command "ls-files", which is plumbing whose output is meant for script consumption. > +--eol:: > + Show line endings ("eolinfo") and the text/eol attributes > ("texteolattr") of files. > + "eolinfo" is the file content identification used by Git when > + the "text" attribute is "auto", or core.autocrlf != false. > + > + "eolinfo" is either "" (when the the info is not available"), or one of > "binary", > + "text-no-eol", "text-lf", "text-crlf" or "text-crlf-lf". > + The "texteolattr" can be "", "-text", "text", "text=auto", "eol=lf", > "eol=crlf". > + > + Both the content in the index ("i/") and the content in the working > tree ("w/") > + are shown for regular files, followed by the "texteolattr ("attr/"). > + Does this format well, or would the second and third paragraph be format in a funny way? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1] git-p4: ignore P4 changelists that only touch files
Lars Schneiderwrites: > Junio just made me aware of the inappropriate phrasing here. > This is what I wanted to express: > > This patch is based on master as it depends on "git-p4: add option to keep > empty commits" (4ae048e)" Thanks. It wasn't "inappropriate", but was merely prone to be misunderstood. And I did misunderstand it. Sorry for the noise. -- 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] Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"
Duy Nguyenwrites: > On Tue, Dec 22, 2015 at 1:31 AM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >>> Nguyễn Thái Ngọc Duy writes: >>> This commit has caused three regression reports so far. All of them are about spawning git subprocesses, where the new presence of GIT_WORK_TREE either changes command behaviour (git-init or git-clone), or how repo/worktree is detected (from aliases), with or without $GIT_DIR. The original bug will be re-fixed another way. Signed-off-by: Nguyễn Thái Ngọc Duy --- On Thu, Dec 3, 2015 at 12:09 AM, Junio C Hamano wrote: > OK, when/if you decide that our first step should be a revert of > d95138e please send in a patch to do so with a brief write-up of a > follow-up plan. Three reports to me are enough. And I obviously could not push the fix out fast enough. So if you want to revert it, here's the patch on maint. >> >> Also, can you reference these three reports for future reference? > > http://article.gmane.org/gmane.comp.version-control.git/281608 > http://article.gmane.org/gmane.comp.version-control.git/281979 > http://article.gmane.org/gmane.comp.version-control.git/282691 > > The last one is not confirmed by the reporter yet. But I'm pretty sure > i'll trigger the special case "when GIT_WORK_TREE is set but GIT_DIR > is not" in setup code Thanks, I'll leave these breadcrumbs in the log message for future reference. I think the last sentence of the original commit is telling how this bug came about. "It does not harm if $GIT_WORK_TREE is set while $GIT_DIR is not." forgets to consider the possibility that scripts may be relying on the "Go to the top of the working tree and setting GIT_DIR would give you a reasonable environment". That is true if GIT_WORK_TREE is not set, and these scripts weren't getting the environment exported [*1*]. These scripts now have to unset GIT_WORK_TREE themselves (or set it to their $cwd if they are indeed at the top), just in case the process that calls them exports it X-<. Thanks. [Footnote] *1* If the end user has GIT_WORK_TREE in the environment, even if Git stops exporting it by reverting d95138e, such a script may break. So in that sense, d95138e did not quite change the rule of the game for these scripts, but made it more obvious when these scripts were written sloppily. -- 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] user-manual: add section documenting shallow clones
Rather than merely pointing readers at the 1.5 release notes to learn about shallow clones, document them formally. --- Documentation/user-manual.txt | 21 ++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 1c790ac..bdfe984 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2128,6 +2128,24 @@ The gitweb cgi script provides users an easy way to browse your project's files and history without having to install Git; see the file gitweb/INSTALL in the Git source tree for instructions on setting it up. +[[how-to-get-a-git-repository-with-minimal-history]] +How to get a Git repository with minimal history + + +A <> is useful when the recent +history of a project is needed and getting real history recorded in +the upstream is expensive. The resultant cloned < > +has truncated history. This clone could be used to look at history +near the tip of a branch and contribute email patches to the project. + +A < > is created by specifying the +depth when creating a clone of a repository using the +linkgit:git-clone[1] `--depth` switch. The depth can later be changed +by using the linkgit:git-fetch[1] `--depth` switch. If there is later +a need to fetch the entire history and if the source repository is +complete, the linkgit:git-fetch[1] `--unshallow` switch can be used to +convert a shallow repository to a complete one. + [[sharing-development-examples]] Examples @@ -4645,9 +4663,6 @@ standard end-of-chapter section? Include cross-references to the glossary, where appropriate. -Document shallow clones? See draft 1.5.0 release notes for some -documentation. - Add a section on working with other version control systems, including CVS, Subversion, and just imports of series of release tarballs. -- 2.6.3.368.gf34be46 -- 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: RefTree: Alternate ref backend
Shawn Pearcewrites: >> But really, aside from slightly helping >> disambiguate references from paths in the command line, what is it good >> for? > > Nothing really; today refs/ prefix is used to encourage to the tools > that you really meant refs/heads/master and not > refs/heads/heads/master or some other crazy construct. You can thank > the DWIMery inside the ref rev parse logic for needing this. Aren't you two forgetting one minor thing, though? A layout without refs/, i.e. $GIT_DIR/{heads,tags,...}, will force us to keep track of where the tips of histories are anchored for reachability purposes, every time you would add a new hierarchy (e.g. $GIT_DIR/changes)--and those unfortunate souls who run a slightly older version of Git that is unaware of 'changes' hierarchy would weep after running "git gc", no? -- 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 00/10] use the $( ... ) construct for command substitution
Elia Pinto wrote: > This is the second series, the other will be sent separately. Reviewed-by: Jonathan Nieder-- 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 00/16] LMDB refs backend atop pre-vtable
On Wed, 2015-12-02 at 19:35 -0500, David Turner wrote: > I'm starting the patchset numbering over from 1 here, because this > version of the patchset is a subset of the last version. I'm going out of town on 12/24 and will return 1/5. I won't be reading this email address. When I get back, I'll read any reviews. -- 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] push: don't mark options of recurse-submodules for translation
Signed-off-by: Ralf Thielow--- builtin/push.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/push.c b/builtin/push.c index cc29277..8963dbd 100644 --- a/builtin/push.c +++ b/builtin/push.c @@ -547,7 +547,7 @@ int cmd_push(int argc, const char **argv, const char *prefix) 0, CAS_OPT_NAME, , N_("refname>:
Git Rebase Issue
Hi, I've encountered a situation using rebase for which I don't understand the results, even after reading the documentation. I'm currently working in my feature branch and then I want to squash commits, thus I use interactive rebase. After successfully completing the rebase, I end up in a detached HEAD state, rather than back on my branch, which is confusing. The command that is causing me to be in detached HEAD mode is: git rebase -i HEAD~2 HEAD >From the documentation, I read that my second parameter (HEAD) is the >parameter: git rebase [-i | --interactive] [options] [--exec ] [--onto ] [] [] If is specified, git rebase will perform an automatic git checkout before doing anything else. Otherwise it remains on the current branch. Working branch; defaults to HEAD. Upon completion, will be the current branch. Here is a full example than can be used to easily repro the issue. Go to an empty folder. git init git echo text > file.txt git add . git commit -m "Add file.txt" git echo text2 > file.txt git commit -am "Modify file.txt" git echo text3 > file.txt git commit -am "Remodify file.txt" Now the interesting part: $ git rebase -i HEAD~2 HEAD [detached HEAD 9178b93] Modify file 1 file changed, 1 insertion(+), 1 deletion(-) Successfully rebased and updated detached HEAD. >From the documentation it says that (which is HEAD) will be checked >out before doing anything and that upon completion, will be the >current branch. However, this doesn't seem to happen. In fact, it seems more >like the following is happening during the rebase: 1) detach HEAD 2) rebase 3) reattach to If is HEAD, then is does nothing and remains detached. I find this behavior confusing since I would expect it to return to whatever HEAD was pointing to at the start of the command, such as my branch. Also, the documentation says that the parameter defaults to HEAD, so passing 'HEAD' explicitly should result in the same behavior as not passing it: Working branch; defaults to HEAD. Pierre-Luc Loyer -- 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 0/3] nd/clear-gitenv-upon-use-of-alias
Duy Nguyenwrites: > On Tue, Dec 22, 2015 at 5:57 PM, Duy Nguyen wrote: >> On Tue, Dec 22, 2015 at 4:18 AM, Junio C Hamano wrote: >>> Thanks. I wiggled these three on top of the "Revert the earlier >>> one"; while I think the result is correct, I'd appreciate if you can >>> double check the result when I push the topic out later today. >> >> Looks good. "prove" passed too by the way. > > Another by the way, this "forcing aliases as external commands" now > shows something like "error: git-log died of signal 13" when the pager > exits early, for an alias like "l1 = log --oneline". ... and we do not show that when we directly call "git log" is...? We do signal this with non-zero exit status like so: $ GIT_PAGER=true git log --oneline ; echo $? 141 and it is not surprising that the one that is catching the exit status of what was spawned and reporting "signal 13". -- 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] rebase: add --verify-signatures
Sorry, I didn't do a group-reply in my last mail. On Mon, Dec 21, 2015 at 03:46:54PM -0800, Junio C Hamano wrote: > Alexander 'z33ky' Hirsch <1ze...@gmail.com> writes: > > > On Thu, Dec 17, 2015 at 10:22:20AM -0800, Junio C Hamano wrote: > >> I suspect that you are missing the bigger workflow issues, if you > >> think this and merge are the same. > >> > >> git-merge will check the other history on the side branch that you > >> are merging _into_ the trunk, to give you an opportunity to reject > >> what does not pass and keep the trunk sane without doing anything > >> else. How you (or others who asked you to pull) clean up the side > >> branch is outside the scope of its verification. > >> > >> Your change to "git pull --rebase" checks the other way---the > >> history, which is already the trunk, onto which your work will be > >> rebased. There is nothing you can do without messing with the trunk > >> if the validation did not pass, be it with a rewind-and-rebuild or a > >> sealing empty commit which is pointless. > > > > It would still make sense for long-lived development branches that > > contain experimental or controversial features, or for forks/private > > copies that add a couple of commits onto a branch. Merging is certainly > > an option, but I don't see why rebasing would be a wrong alternative. > > Nobody says rebase is a wrong alternative. > > It is just the time you decide to rebase is a wrong time to check, > iow, too late, for the validation of the tip. In that case I would like to submit a patch that warns or even errors in case both --rebase and --verify-signatures is passed to git-pull. I think an error would be appropriate, but in theory this could break scripts that have done that, albeit it probably didn't do what the user expected, and I don't know git's policy about breaking something like this. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] push: don't mark options of recurse-submodules for translation
Ralf Thielowwrites: > Signed-off-by: Ralf Thielow > --- > builtin/push.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/builtin/push.c b/builtin/push.c > index cc29277..8963dbd 100644 > --- a/builtin/push.c > +++ b/builtin/push.c > @@ -547,7 +547,7 @@ int cmd_push(int argc, const char **argv, const char > *prefix) > 0, CAS_OPT_NAME, , N_("refname>: N_("require old value of ref to be at this value"), > PARSE_OPT_OPTARG, parseopt_push_cas_option }, > - { OPTION_CALLBACK, 0, "recurse-submodules", > _submodules, N_("check|on-demand|no"), > + { OPTION_CALLBACK, 0, "recurse-submodules", > _submodules, "check|on-demand|no", > N_("control recursive pushing of submodules"), > PARSE_OPT_OPTARG, option_parse_recurse_submodules }, > OPT_BOOL( 0 , "thin", , N_("use thin pack")), Makes sense. I should redo the -rc2 with this patch in. 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
[ANNOUNCE] Git v2.7.0-rc2
A release candidate Git v2.7.0-rc2 is now available for testing at the usual places. It is comprised of 511 non-merge commits since v2.6.0, contributed by 75 people, 24 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following public repositories all have a copy of the 'v2.7.0-rc2' tag and the 'master' branch that the tag points at: url = https://kernel.googlesource.com/pub/scm/git/git url = git://repo.or.cz/alt-git.git url = git://git.sourceforge.jp/gitroot/git-core/git.git url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core url = https://github.com/gitster/git New contributors whose contributions weren't in v2.6.0 are as follows. Welcome to the Git development community! Atousa Pahlevan Duprat, Ben Boeckel, Blake Burkhart, Dair Grant, Edmundo Carmona Antoranz, Eric N. Vander Weele, Fabio Porcedda, Gabor Bernat, GIRARD Etienne, James McCoy, Juerg Haefliger, Noam Postavsky, Rainer M. Canavan, Ray Donnelly, Remi Pommarel, Renee Margaret McConahy, Sidhant Sharma, Stefan Agner, Takashi Iwai, Tobias Klauser, Waldek Maleska, Xue Fuqiao, YOKOTA Hiroshi, and Андрей Рыбак. Returning contributors who helped this release are as follows. Thanks for your continued support. Alexey Shumkin, Alex Henrie, Alex Riesen, Antoine Delaite, Beat Bolli, brian m. carlson, Charles Bailey, Christian Couder, Clemens Buchacher, Daniel Knittl-Frank, David Aguilar, David Turner, Dennis Kaarsemaker, Dimitriy Ryazantcev, Doug Kelly, Elia Pinto, Fabian Ruch, Fredrik Medley, Giuseppe Bilotta, Jacob Keller, Jeff King, Johannes Schindelin, Johannes Sixt, John Keeping, Junio C Hamano, Karthik Nayak, Lars Schneider, Lukas Fleischer, Luke Diamand, Matthieu Moy, Max Kirillov, Michael Haggerty, Michael J Gruber, Michael Rappazzo, Mike Crowe, Namhyung Kim, Nguyễn Thái Ngọc Duy, Pat Thoyts, Paul Mackerras, Peter Krefting, Ralf Thielow, Ramsay Jones, René Scharfe, Ronnie Sahlberg, Stefan Beller, Stefan Naewe, Stephan Beyer, SZEDER Gábor, Techlive Zheng, Torsten Bögershausen, and Trần Ngọc Quân. Git 2.7 Release Notes (draft) = Updates since v2.6 -- UI, Workflows & Features * The appearance of "gitk", particularly on high DPI monitors, have been improved. "gitk" also comes with an undated translation for Swedish and Japanese. * "git remote" learned "get-url" subcommand to show the URL for a given remote name used for fetching and pushing. * There was no way to defeat a configured rebase.autostash variable from the command line, as "git rebase --no-autostash" was missing. * "git log --date=local" used to only show the normal (default) format in the local timezone. The command learned to take 'local' as an instruction to use the local timezone with other formats, * The refs used during a "git bisect" session is now per-worktree so that independent bisect sessions can be done in different worktrees created with "git worktree add". * Users who are too busy to type three extra keystrokes to ask for "git stash show -p" can now set stash.showPatch configuration variable to true to always see the actual patch, not just the list of paths affected with feel for the extent of damage via diffstat. * "quiltimport" allows to specify the series file by honoring the $QUILT_SERIES environment and also --series command line option. * The use of 'good/bad' in "git bisect" made it confusing to use when hunting for a state change that is not a regression (e.g. bugfix). The command learned 'old/new' and then allows the end user to say e.g. "bisect start --term-old=fast --term-new=slow" to find a performance regression. * "git interpret-trailers" can now run outside of a Git repository. * "git p4" learned to reencode the pathname it uses to communicate with the p4 depot with a new option. * Give progress meter to "git filter-branch". * Allow a later "!/abc/def" to override an earlier "/abc" that appears in the same .gitignore file to make it easier to express "everything in /abc directory is ignored, except for ...". * Teach "git p4" to send large blobs outside the repository by talking to Git LFS. * Prepare for Git on-disk repository representation to undergo backward incompatible changes by introducing a new repository format version "1", with an extension mechanism. * "git worktree" learned a "list" subcommand. * "git clone --dissociate" learned that it can be used even when "--reference" was not used at the same time. * "git blame" learnt to take "--first-parent" and "--reverse" at the same time when it makes sense. * "git checkout" did not follow the usual "--[no-]progress" convention and implemented only "--quiet" that is essentially a superset of "--no-progress". Extend the command to support the
[PATCH V3 2/2] user-manual: add section documenting shallow clones
Rather than merely pointing readers at the 1.5 release notes to learn about shallow clones, document them formally. Signed-off-by: Stephen P. Smith--- Documentation/user-manual.txt | 21 ++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt index 1c790ac..bdfe984 100644 --- a/Documentation/user-manual.txt +++ b/Documentation/user-manual.txt @@ -2128,6 +2128,24 @@ The gitweb cgi script provides users an easy way to browse your project's files and history without having to install Git; see the file gitweb/INSTALL in the Git source tree for instructions on setting it up. +[[how-to-get-a-git-repository-with-minimal-history]] +How to get a Git repository with minimal history + + +A < > is useful when the recent +history of a project is needed and getting real history recorded in +the upstream is expensive. The resultant cloned < > +has truncated history. This clone could be used to look at history +near the tip of a branch and contribute email patches to the project. + +A < > is created by specifying the +depth when creating a clone of a repository using the +linkgit:git-clone[1] `--depth` switch. The depth can later be changed +by using the linkgit:git-fetch[1] `--depth` switch. If there is later +a need to fetch the entire history and if the source repository is +complete, the linkgit:git-fetch[1] `--unshallow` switch can be used to +convert a shallow repository to a complete one. + [[sharing-development-examples]] Examples @@ -4645,9 +4663,6 @@ standard end-of-chapter section? Include cross-references to the glossary, where appropriate. -Document shallow clones? See draft 1.5.0 release notes for some -documentation. - Add a section on working with other version control systems, including CVS, Subversion, and just imports of series of release tarballs. -- 2.6.3.368.gf34be46 -- 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 08/16] refs: add methods to init refs backend and db
On 12/03/2015 01:35 AM, David Turner wrote: > Alternate refs backends might not need the refs/heads directory and so > on, so we make ref db initialization part of the backend. We also > might need to initialize ref backends themselves, so we'll add a > method for that as well. > > Signed-off-by: David Turner> --- > builtin/init-db.c| 14 -- > refs.c | 8 +++- > refs.h | 4 +++- > refs/files-backend.c | 23 +++ > refs/refs-internal.h | 4 > 5 files changed, 41 insertions(+), 12 deletions(-) > > [...] > diff --git a/refs.c b/refs.c > index 9a2fed7..bdeb276 100644 > --- a/refs.c > +++ b/refs.c > @@ -22,13 +22,14 @@ struct ref_be *refs_backends = _be_files; > /* > * This function is used to switch to an alternate backend. > */ > -int set_refs_backend(const char *name) > +int set_refs_backend(const char *name, void *data) The purpose of the data argument is rather mysterious at this point, especially since set_refs_backend() still doesn't have any callers. I hope that will become clearer later in the series. Nevertheless, it would be nice for its use to be described in the docstring (which should preferably be moved to the header file). > [...] > diff --git a/refs/files-backend.c b/refs/files-backend.c > index e769242..6600c02 100644 > --- a/refs/files-backend.c > +++ b/refs/files-backend.c > @@ -3313,6 +3313,11 @@ static int ref_present(const char *refname, > return string_list_has_string(affected_refnames, refname); > } > > +void files_init_backend(void *data) > +{ > + /* do nothing */ > +} > + > static int files_initial_transaction_commit(struct ref_transaction > *transaction, > struct strbuf *err) > { > @@ -3534,9 +3539,27 @@ static int files_reflog_expire(const char *refname, > const unsigned char *sha1, > return -1; > } > > +static int files_init_db(struct strbuf *err, int shared) > +{ > + /* > + * Create .git/refs/{heads,tags} > + */ > + safe_create_dir(git_path("refs"), 1); > + safe_create_dir(git_path("refs/heads"), 1); > + safe_create_dir(git_path("refs/tags"), 1); > + if (shared) { > + adjust_shared_perm(git_path("refs")); > + adjust_shared_perm(git_path("refs/heads")); > + adjust_shared_perm(git_path("refs/tags")); > + } > + return 0; > +} > + > struct ref_be refs_be_files = { > NULL, > "files", > + files_init_backend, > + files_init_db, > files_transaction_commit, > files_initial_transaction_commit, > > diff --git a/refs/refs-internal.h b/refs/refs-internal.h > index 478ad54..85a0b91 100644 > --- a/refs/refs-internal.h > +++ b/refs/refs-internal.h > @@ -208,6 +208,8 @@ const char *find_descendant_ref(const char *dirname, > int rename_ref_available(const char *oldname, const char *newname); > > /* refs backends */ > +typedef void ref_backend_init_fn(void *data); > +typedef int ref_backend_init_db_fn(struct strbuf *err, int shared); > typedef int ref_transaction_commit_fn(struct ref_transaction *transaction, > struct strbuf *err); > > @@ -267,6 +269,8 @@ typedef int for_each_replace_ref_fn(each_ref_fn fn, void > *cb_data); > struct ref_be { > struct ref_be *next; > const char *name; > + ref_backend_init_fn *init_backend; > + ref_backend_init_db_fn *init_db; > ref_transaction_commit_fn *transaction_commit; > ref_transaction_commit_fn *initial_transaction_commit; > > Your naming seems inconsistent here. I would have expected a "files_init_backend()" function to satisfy the typedef "ref_backend_init_backend_fn" or "ref_init_backend_fn", not "ref_backend_init_fn". Or, conversely, for the function implementing "ref_backend_init_fn" to be called "files_init()". More generally, it would be nice to have a consistent naming pattern between (1) the name of the typedef, (2) the name of the member in "struct ref_be", (3) the names of concrete, backend-specific implementations of the functions. Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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: RefTree: Alternate ref backend
On 12/22/2015 08:34 PM, Junio C Hamano wrote: > Shawn Pearcewrites: > >> On Tue, Dec 22, 2015 at 11:09 AM, Junio C Hamano wrote: >>> Shawn Pearce writes: >>> > But really, aside from slightly helping > disambiguate references from paths in the command line, what is it good > for? Nothing really; today refs/ prefix is used to encourage to the tools that you really meant refs/heads/master and not refs/heads/heads/master or some other crazy construct. You can thank the DWIMery inside the ref rev parse logic for needing this. >>> >>> Aren't you two forgetting one minor thing, though? >>> >>> A layout without refs/, i.e. $GIT_DIR/{heads,tags,...}, will force >>> us to keep track of where the tips of histories are anchored for >>> reachability purposes, every time you would add a new hierarchy >>> (e.g. $GIT_DIR/changes)--and those unfortunate souls who run a >>> slightly older version of Git that is unaware of 'changes' hierarchy >>> would weep after running "git gc", no? >> >> You still store them under refs/ > > Well I know; the comment was merely a reaction to the exchange > between you two, "What is refs/ good for?", "Nothing really". > > You'd benefit by having "refs/" that is known to contain all the > anchoring points for reachability without knowing what subhierarchy > it may contain in the future, that is what it is good for. You are answering "What is 'refs/' good for in the pathnames of files that store loose references?" I was asking "What is 'refs/' good for in the logical names of references?" It would have been totally possible to make the full name of a branch be, for example, "heads/master" and nevertheless store its loose reference in "$GIT_DIR/refs/heads/master". The obvious place to store HEAD in such a scheme would have been "$GIT_DIR/refs/HEAD" while still calling it "HEAD". This could have avoided the problem that we now have with pseudo-references like FETCH_HEAD being stored directly in $GIT_DIR. On 12/22/2015 09:56 PM, Martin Fick wrote: > On Tuesday, December 22, 2015 06:17:28 PM you wrote: >> On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggerty > wrote: >> >> [...] Would we really be worse off if >> references' full names were >> >> HEAD >> heads/master >> tags/v1.0.0 >> remotes/origin/master (or remotes/origin/heads/master) > > I think this is a bit off, because > > HEAD != refs/HEAD > > so not quite useless. A reference called "refs/HEAD" is not forbidden today but it's still not very useful, is it? Do you know of some system that uses reference names like this or are you just pointing out that it's theoretically possible? > But, I agree that the whole refs notation has always bugged > me, it is quirky. It makes it hard to disambiguate when > something is meant to be absolute or not. What if we added > a leading slash for absolute references? Then I could do > something like: > > /HEAD > /refs/heads/master > /refs/tags/v1.0.0 > /refs/remotes/origin/master I like the idea of having a way to express "absolute" reference names. But maybe if we do so we could take a step towards deprecating "refs/" in references' logical names, by instead using the following absolute notation for the above references: /HEAD /heads/master /tags/v1.0.0 /remotes/origin/master Specifically: * Any name of the form "/$name" for which is_pseudoref_syntax($name) returns true would be mapped to what we today call "$name" (e.g., "/FETCH_HEAD" would be mapped to today's "FETCH_HEAD") * Any other name of the form "/$name" would be mapped to today's "refs/$name". Note that all of the absolute reference listed above, with their leading "/" removed, have the same interpretation under DWIM as they would as absolute names under my proposal (provided of course, that there is no DWIM ambiguity with other reference names). The only disadvantage that I can see with this scheme is that there would be no "absolute" notation for a reference that currently has a full name like "refs/HEAD" (or more generally a reference currently called "refs/$name" where is_pseudoref_syntax($name) returns true). I think that is acceptable: (1) such references are probably not in wide use; (2) we wouldn't (yet) have to prohibit such references; even though there would be no absolute notation to represent them, their old-style names would still work. If we ever decide to go further in banishing "refs/", the next step in the transition would be to disallow names like "refs/HEAD", treat the absolute reference names as the "canonical" version, and adding DWIM rules that treat a prefix "refs/" very much like a leading "/". Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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 11/16] refs: move duplicate check to common code
On 12/03/2015 01:35 AM, David Turner wrote: > The check for duplicate refnames in a transaction is needed for > all backends, so move it to the common code. > > ref_transaction_commit_fn gains a new argument, the sorted > string_list of affected refnames. > > Signed-off-by: David Turner> --- > refs.c | 71 > ++-- > refs/files-backend.c | 57 - > refs/refs-internal.h | 1 + > 3 files changed, 75 insertions(+), 54 deletions(-) > > diff --git a/refs.c b/refs.c > index 1b79630..808053f 100644 > --- a/refs.c > +++ b/refs.c > @@ -1093,6 +1093,37 @@ const char *find_descendant_ref(const char *dirname, > return NULL; > } > > +/* > + * Return 1 if there are any duplicate refnames in the updates in > + * `transaction`, and fill in err with an appropriate error message. > + * Fill in `refnames` with the refnames from the transaction. > + */ > + > +static int ref_update_reject_duplicates(struct ref_transaction *transaction, > + struct string_list *refnames, > + struct strbuf *err) I like that you extract this code into a function. Though it feels awkward to have a function called "ref_update_reject_duplicates()" that has a side effect of filling the names into a string list. I think it would feel more natural to call the function get_affected_refnames(), and treat the duplicate check as an extra bonus. You could go even farther and split it into two functions, void get_affected_refnames(struct ref_transaction *transaction, struct string_list *refnames); int ref_update_reject_duplicates(struct string_list *refnames, struct strbuf *err); > +{ > + int i, n = transaction->nr; > + struct ref_update **updates; > + > + assert(err); > + > + updates = transaction->updates; > + /* Fail if a refname appears more than once in the transaction: */ > + for (i = 0; i < n; i++) > + string_list_append(refnames, updates[i]->refname); > + string_list_sort(refnames); > + > + for (i = 1; i < n; i++) > + if (!strcmp(refnames->items[i - 1].string, > refnames->items[i].string)) { > + strbuf_addf(err, > + "Multiple updates for ref '%s' not > allowed.", > + refnames->items[i].string); > + return 1; > + } > + return 0; > +} > + > /* backend functions */ > int refs_init_db(struct strbuf *err, int shared) > { > @@ -1102,7 +1133,29 @@ int refs_init_db(struct strbuf *err, int shared) > int ref_transaction_commit(struct ref_transaction *transaction, > struct strbuf *err) > { > - return the_refs_backend->transaction_commit(transaction, err); > + int ret = -1; > + struct string_list affected_refnames = STRING_LIST_INIT_NODUP; > + > + assert(err); > + > + if (transaction->state != REF_TRANSACTION_OPEN) > + die("BUG: commit called for transaction that is not open"); > + > + if (!transaction->nr) { > + transaction->state = REF_TRANSACTION_CLOSED; > + return 0; > + } > + > + if (ref_update_reject_duplicates(transaction, _refnames, err)) > { > + ret = TRANSACTION_GENERIC_ERROR; > + goto done; > + } > + > + ret = the_refs_backend->transaction_commit(transaction, > +_refnames, err); > +done: > + string_list_clear(_refnames, 0); > + return ret; > } Here you are avoiding a small amount of code duplication by calling ref_update_reject_duplicates() here rather than in the backend-specific code. But you are doing so at the cost of having to compute affected_refnames here and pass it (redundantly) to the backend's transaction_commit function. This increases the coupling between these functions, which in my opinion is worse than the small amount of code duplication. But maybe it's just me. The check of transaction->state, on the other hand, makes sense here. > [...] Michael -- Michael Haggerty mhag...@alum.mit.edu -- 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 x/2] user-manual: add section documenting shallow clones
I just realized that the two patches I sent earlier were missing the Signed by lines. I will be resending them. sps -- 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 08/16] refs: add methods to init refs backend and db
On Wed, 2015-12-23 at 06:33 +0100, Michael Haggerty wrote: > On 12/03/2015 01:35 AM, David Turner wrote: > > Alternate refs backends might not need the refs/heads directory and > > so > > on, so we make ref db initialization part of the backend. We also > > might need to initialize ref backends themselves, so we'll add a > > method for that as well. > > > > Signed-off-by: David Turner> > --- > > builtin/init-db.c| 14 -- > > refs.c | 8 +++- > > refs.h | 4 +++- > > refs/files-backend.c | 23 +++ > > refs/refs-internal.h | 4 > > 5 files changed, 41 insertions(+), 12 deletions(-) > > > > [...] > > diff --git a/refs.c b/refs.c > > index 9a2fed7..bdeb276 100644 > > --- a/refs.c > > +++ b/refs.c > > @@ -22,13 +22,14 @@ struct ref_be *refs_backends = _be_files; > > /* > > * This function is used to switch to an alternate backend. > > */ > > -int set_refs_backend(const char *name) > > +int set_refs_backend(const char *name, void *data) > > The purpose of the data argument is rather mysterious at this point, > especially since set_refs_backend() still doesn't have any callers. I > hope that will become clearer later in the series. Nevertheless, it > would be nice for its use to be described in the docstring (which > should > preferably be moved to the header file). Will fix. > > struct ref_be { > > struct ref_be *next; > > const char *name; > > + ref_backend_init_fn *init_backend; > > + ref_backend_init_db_fn *init_db; > > ref_transaction_commit_fn *transaction_commit; > > ref_transaction_commit_fn *initial_transaction_commit; > > > > > > Your naming seems inconsistent here. I would have expected a > "files_init_backend()" function to satisfy the typedef > "ref_backend_init_backend_fn" or "ref_init_backend_fn", not > "ref_backend_init_fn". Or, conversely, for the function implementing > "ref_backend_init_fn" to be called "files_init()". > > More generally, it would be nice to have a consistent naming pattern > between (1) the name of the typedef, (2) the name of the member in > "struct ref_be", (3) the names of concrete, backend-specific > implementations of the functions. I'll change this to "refs_init_backend_fn *init_backend" and "refs_init_db_fn *init_db" (since we already have an init_db function), and make any other similar changes I happen to notice. On the naming in general, I am somewhat at the mercy of history here. For example, git presently has functions named ref_transaction_commit (object_verb) and create_reflog (verb_object). So nothing I do will be consistent with everything. I could, of course, do some initial commits to clean up the naming, but that would create code churn. -- 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: RefTree: Alternate ref backend
On 12/17/2015 10:02 PM, Shawn Pearce wrote: > I started playing around with the idea of storing references directly > in Git. Exploiting the GITLINK tree entry, we can associate a name to > any SHA-1. > > By storing all references in a single tree, atomic transactions are > possible. Its a simple compare-and-swap of a single 40 byte SHA-1. > This of course leads to a bootstrapping problem, where do we store the > 40 byte SHA-1? For this example its just $GIT_DIR/refs/txn/committed > as a classical loose reference. I like this general idea a lot, even while recognizing some practical problems that other people have pointed out. I especially like the idea of having truly atomic multi-reference updates. I'm curious why you decided to store all of the references in a single list, similar to the packed-refs file. This design means that the whole object has to be rewritten whenever any reference is updated [1]. Certainly, storing the references in a single tree *object* is not a requirement for having atomic transitions. I would have expected a design where the layout of the references in trees mimics the layout of loose references in the filesystem; e.g., one tree object for "refs/", one for "refs/heads/" one for "refs/remotes/" etc. This design would reduce the amount of rewriting that is needed when one or a few references are updated. Another reason that I find a hierarchical layout intriguing would be that one could imagine using the SHA-1s of reference namespace subtrees to speed up the negotiation phase of "git fetch". In the common case that I use the local namespace "refs/remotes/origin" to track an upstream repo, the SHA-1 of my "refs/remotes/origin" tree would usually represent a complete description of the state of the upstream references at the time that I last fetched. My client could tell the server have-tree $SHA1 , where $SHA1 is the hash of the tree representing "refs/remotes/origin/". If the server keeps a reflog as you have described (but hierarchically), then the server could look up $SHA1 and immediately know the full set of references, and therefore of objects, that I fetched last time. More generally, the negotiation could proceed down the reference namespace tree and stop whenever commonality is found. There are a lot of "if"s in that last paragraph, and maybe it's not workable. For example, if I'm not pruning on fetch, then my reference tree won't be identical to one that was ever present on the server and this technique wouldn't necessarily help. But if, for example, we change the default to pruning, or perhaps record some extra reftree SHA-1's, then in most cases I would expect that this trick could reduce the effort of negotiation to negligible in most cases, and reduce the time of the whole fetch to negligible in the case that the clone is already up-to-date. Michael [1] At GitHub, we store public repositories in networks with a shared object store. The central repository in each network can have 10M+ references. So for us, rewriting that many references for every reference update would be unworkable. -- Michael Haggerty mhag...@alum.mit.edu -- 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 0/3] nd/clear-gitenv-upon-use-of-alias
On Tue, Dec 22, 2015 at 4:18 AM, Junio C Hamanowrote: > Thanks. I wiggled these three on top of the "Revert the earlier > one"; while I think the result is correct, I'd appreciate if you can > double check the result when I push the topic out later today. Looks good. "prove" passed too by the way. -- 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 7/8] config: add core.untrackedCache
On Tue, Dec 22, 2015 at 1:30 AM, Junio C Hamanowrote: > Duy Nguyen writes: > >> On Thu, Dec 17, 2015 at 2:44 PM, Jeff King wrote: >>> I think we may actually be thinking of the same thing. Naively, I would >>> expect: >>> >>> .. >>> - if there is cache data in the index but that config flag is not set, >>> presumably we would not update it (we could even explicitly drop it, >>> but my understanding is that is not necessary for correctness, but >>> only as a possible optimization). >> >> No, if somebody adds or removes something from the index, we either >> update or drop it, or it's stale. There's the invalidate_untracked() >> or something in dir.c that we can hook in, check config var and do >> that. And because config is cached recently, it should be a cheap >> operation. > > Checking the config may be cheap, but it bothers me a lot that we > have to call that "invalidate" thing every time we go into the > codepath to deal with the index, from code cleanliness point of > view. In that case we can just check config once in read_index_from and destroy UNTR extension. Or the middle ground, we check config once in that place, make a note in struct index_state, and make invalidate_* check that note instead of config file. The middle ground has an advantage over destroying UNTR: (probably) many operations will touch index but do not add or remove entries. Though I may be wrong, replacing an entry may be implemented as delete then add, I haven't checked the code. -- 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: "git stash pop" is doing an unwanted "git add" when there are conflicts.
On ma, 2015-12-21 at 14:29 +, Alan Mackenzie wrote: > Hello, git project. > > Last night, whilst clearing out a stale "stash stack", I did "git stash > pop". There were conflicts in two files. > > However, all the popped files became staged. This doesn't normally happen. > It was intensely irritating, and required me to do "git reset HEAD" on > each of the files, none of which I wanted to commit. > > I searched the git-stash man page for this scenario, but found nothing > about it. > > Surely staging all the files is a bug? That depends. A stash is two commits: one for all changes that were in the index when you ran 'git stash save' and one for all changes not yet in the index. When you pop the stash, these then get restored as staged resp. unstaged changes. So if your changes are now all staged, I'd wager that they were staged when you ran git stash save. -- Dennis Kaarsemaker www.kaarsemaker.net -- 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 v1 0/2] git-p4: kill watchdog and suppress irrelevant output
On 21 Dec 2015, at 21:31, Junio C Hamanowrote: > larsxschnei...@gmail.com writes: > >> From: Lars Schneider >> >> Hi, >> >> these patches extend "git-p4: add trap to kill p4d on test exit" (dfe90e8) >> and therefore should be applied on master. > > Wait, wait. Please be a bit more careful when you use such a > phrasing. Did somebody review these and said that these are > trivially correct improvements? > > This depends on what you exactly meant "extend" and "improve" (for > the other one); if the "improvement" were to make something that > used to be unusable to usable, then the more sensible way forward > during the -rc stabilization period might be to revert the earlier > merges to 'master' that brought in undercooked topic. Oh. Thanks or making me aware of the inappropriate phrases! Nobody reviewed these patches, yet! My intention was to let the reviewer know that this patch series is based on "master" and not on "maint". Sorry for the confusion! The patch series "git-p4: kill watchdog and suppress irrelevant output" fixes something annoying that I did not spot earlier. In other words it changes "usable but a bit annoying (dfe90e8)" to "usable". The patch series "git-p4: ignore P4 changelists that only touch files" changes "usable (4ae048e)" to "maybe even better" depending on the reviewers opinion. Thanks, Lars -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "git stash pop" is doing an unwanted "git add" when there are conflicts.
On Tue, Dec 22, 2015 at 09:17:38AM +0100, Dennis Kaarsemaker wrote: > On ma, 2015-12-21 at 14:29 +, Alan Mackenzie wrote: > > Hello, git project. > > > > Last night, whilst clearing out a stale "stash stack", I did "git stash > > pop". There were conflicts in two files. > > > > However, all the popped files became staged. This doesn't normally happen. > > It was intensely irritating, and required me to do "git reset HEAD" on > > each of the files, none of which I wanted to commit. > > > > I searched the git-stash man page for this scenario, but found nothing > > about it. > > > > Surely staging all the files is a bug? > > That depends. A stash is two commits: one for all changes that were in > the index when you ran 'git stash save' and one for all changes not yet > in the index. When you pop the stash, these then get restored as staged > resp. unstaged changes. So if your changes are now all staged, I'd > wager that they were staged when you ran git stash save. No, I think there's something else going on. Try this: git init repo && cd repo && echo base >one && echo base >two && git add . && git commit -m base && echo stash >one && echo stash >two && git stash && echo "==> No conflicts, nothing staged" git stash apply && git reset --hard && echo changes >two && git commit -am changes && echo "==> Conflict stages non-conflicting file 'one'" ! git stash apply && git status It seems to be a side effect of merge-recursive to stage the results, and in the no-conflict path we explicitly reset the index. For the conflicting case, it's trickier, because we would want to retain the unmerged entries. So I agree it's kind of weird, but the conflicting case is inherently going to touch the index, and you'd generally have to `git add` to mark the resolutions (but if you really want to just touch the working tree, you'd need to `git reset`). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v1 2/2] git-p4: suppress non test relevant output
On 21 Dec 2015, at 21:38, Junio C Hamanowrote: > larsxschnei...@gmail.com writes: > >> From: Lars Schneider >> >> If tests are executed in verbose mode then the retry logic clutters the >> test output. Suppress that clutter. >> >> Signed-off-by: Lars Schneider >> --- >> t/lib-git-p4.sh | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/t/lib-git-p4.sh b/t/lib-git-p4.sh >> index 30bf7ae..03f29c1 100644 >> --- a/t/lib-git-p4.sh >> +++ b/t/lib-git-p4.sh >> @@ -174,7 +174,7 @@ retry_until_fail() { >> until ! "$@" 2>/dev/null || test $(time_in_seconds) -gt $timeout >> do >> sleep 1 >> -done >> +done >/dev/null 2>&1 > > Eh, what does this squelch? The sleep in the body of the loop is > silent, "test A -gt B" on the loop condition would be silent too, so > you are squelching the invocation of "$@" whose standard error > stream is already sent to 2>/dev/null? > > If so, why not do it there instead? You seem to run only "kill" to > send some signal to a process using this helper function, and it > would be silent on its standard output stream (even though it may > say "no such process" etc. on its standard error), so it is not > clear to me what you are doing with this change here... If I run git-p4 tests in verbose mode (e.g. "./t9823-git-p4-mock-lfs.sh -v") without this patch then the last lines of the output look like this: >>> Output Start >>> expecting success: kill_p4d ./lib-git-p4.sh: line 172: 26289 Killed: 9 while true; do if test $(time_in_seconds) -gt $timeout; then kill -9 $pid; exit 1; fi; sleep 1; done ok 8 - kill p4d # passed all 8 test(s) 1..8 <<< Output end <<< However, I want them to look like this: >>> Output Start >>> expecting success: kill_p4d ok 8 - kill p4d # passed all 8 test(s) 1..8 <<< Output end <<< This is achieved with the patch. I am no shell expert ... is there a nicer way to achieve the same? Thanks, Lars -- 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 v1] git-p4: ignore P4 changelists that only touch files
On 20 Dec 2015, at 15:59, larsxschnei...@gmail.com wrote: > From: Lars Schneider> > Hi, > > this patch improves "git-p4: add option to keep empty commits" (4ae048e) > and therefore should be applied on master. > > Thanks, > Lars Junio just made me aware of the inappropriate phrasing here. This is what I wanted to express: This patch is based on master as it depends on "git-p4: add option to keep empty commits" (4ae048e)" Sorry, Lars-- 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: `format:%>` padding and `git log --graph`
On Sun, Dec 20, 2015 at 10:41:44AM -0600, Elliott Cable wrote: > I'm not sure what version the `%>` / `<|` / etc padding showed up in, > but they're truly excellent for building beautiful one-line `git log` > output. Somebody found my code useful!! :-D > This may be a long-shot, but, unfortunately, these new formats sort of > fall flat in the presence of `git log --graph`: The ‘pad until column’ > feature, which when reading the manpage, I desperately hoped > *specifically exists* to replace the normal ‘pad with spaces’ in > situations where `--graph` adds an un-known number of characters to the > start of the line ... unfortunately doesn't seem to work that way. > > For instance, here's some truncated output from a basic `--graph`: > > $ git log --graph --abbrev=8 --pretty="tformat:%h %s" > ... > * | a4402023 + basic boilerplate for Liability / LiabilityFamily > * | 32ed6de8 Merge branch 'queueless' into queueless+ > |\ \ > | * \ 1e53ea10 (merge misc) Bring in some `bats` fixes, and re-sty > | |\ \ > | | |/ > | | * c8c270ff (!! new doc) Add rationale for basically *all* of the > > Here's what `%>|(16)%h` gives me: > > $ git log --graph --abbrev=8 --pretty="tformat:%>|(16)%h %s" > ... > * | a4402023 + basic boilerplate for Liability / LiabilityFa > * | 32ed6de8 Merge branch 'queueless' into queueless+ > |\ \ > | * \ 1e53ea10 (merge misc) Bring in some `bats` fixes, an > | |\ \ > | | |/ > | | * c8c270ff (!! new doc) Add rationale for basically *all > > Here's something like what I'd *like* to have seen: > > $ git log --graph --abbrev=8 --pretty="tformat:%>|(16)%h %s" > ... > * | a4402023 + basic boilerplate for Liability / LiabilityFamily > * | 32ed6de8 Merge branch 'queueless' into queueless+ > |\ \ > | * \ 1e53ea10 (merge misc) Bring in some `bats` fixes, and re-sty > | * \ 1e53ea10 (merge misc) Bring in some `bats` fixes, and re-sty > | |\ \ > | | |/ > | | * c8c270ff (!! new doc) Add rationale for basically *all* of t > > So: Is this nigh-unimplementable? I once [dove into the git-log > source][patch], and I recall the `--graph` code being terrifying; so if > this is difficult to support, I can see why it would be left out. Yeah graph drawing code does not fit well with other format specifiers. But it does not look that hard to achieve what you want, assuming that you specify the fixed width of the first column because calculating it dynamically can be very expensive and the first column could fill the entire screen (in merge forests like git.git). A starting point is something like this, which gives me something like your output. If you can add a new option to specify the graph width, then it may be an acceptable solution, I think. diff --git a/graph.c b/graph.c index c25a09a..8815984 100644 --- a/graph.c +++ b/graph.c @@ -430,6 +430,8 @@ static void graph_update_width(struct git_graph *graph, * Each column takes up 2 spaces */ graph->width = max_cols * 2; + if (graph->width < 20) + graph->width = 20; } static void graph_update_columns(struct git_graph *graph) > If I'm off, though, and this is just an oversight, it'd be really neat > to see somebody implement it! (= Nope. Your itch. Your patch ;) -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/3] nd/clear-gitenv-upon-use-of-alias
On Tue, Dec 22, 2015 at 5:57 PM, Duy Nguyenwrote: > On Tue, Dec 22, 2015 at 4:18 AM, Junio C Hamano wrote: >> Thanks. I wiggled these three on top of the "Revert the earlier >> one"; while I think the result is correct, I'd appreciate if you can >> double check the result when I push the topic out later today. > > Looks good. "prove" passed too by the way. Another by the way, this "forcing aliases as external commands" now shows something like "error: git-log died of signal 13" when the pager exits early, for an alias like "l1 = log --oneline". It's probably not a regression because other external git commands with pager should show the same message. But I haven't checked thoroughly yet. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v7] ls-files: Add eol diagnostics
When working in a cross-platform environment, a user wants to check if text files are stored normalized in the repository and if .gitattributes are set appropriately. Make it possible to let Git show the line endings in the index and in the working tree and the effective text/eol attributes. The end of line ("eolinfo") are shown like this: "binary" binary file "text-no-eol" text file without any EOL "text-lf" text file with LF "text-crlf"text file with CRLF "text-crlf-lf" text file with mixed line endings. The effective text/eol attribute is one of these: "", "-text", "text", "text=auto", "eol=lf", "eol=crlf" git ls-files --eol gives an output like this: i/text-no-eol w/text-no-eol attr/text=auto t/t5100/empty i/binaryw/binaryattr/-text t/test-binary-2.png i/text-lf w/text-lf attr/eol=lft/t5100/rfc2047-info-0007 i/text-lf w/text-crlf attr/eol=crlf doit.bat i/text-crlf-lf w/text-crlf-lf attr/ locale/XX.po Note that the output is meant to be human-readable and may change. Add test cases in t0027, thanks to Junio C Hamano for the optimized grep-less sed expression. Helped-By: Eric SunshineSigned-off-by: Torsten Bögershausen --- Changes against v6 on pu: - convert.c: fixed possible mem leak in get_wt_convert_stats_ascii() - builtin/ls-files.c: removed not needed () - t0027: Re-added empty line Don't use grep/sed, but sed with an address /(Thanks Junio) More test_when_finished, other small things from the review Add comment on the last TC, which used ls-files -d The last TC may still be classified as fragile, but I couln't motivate myself to use a separated creation/commit for this TC and decided to safe some CPU cycles and re-use what we have in the repo. Documentation/git-ls-files.txt | 22 builtin/ls-files.c | 19 +++ convert.c | 85 +++ convert.h | 3 ++ t/t0027-auto-crlf.sh | 112 - 5 files changed, 229 insertions(+), 12 deletions(-) diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt index e26f01f..8f29c99 100644 --- a/Documentation/git-ls-files.txt +++ b/Documentation/git-ls-files.txt @@ -12,6 +12,7 @@ SYNOPSIS 'git ls-files' [-z] [-t] [-v] (--[cached|deleted|others|ignored|stage|unmerged|killed|modified])* (-[c|d|o|i|s|u|k|m])* + [--eol] [-x |--exclude=] [-X |--exclude-from=] [--exclude-per-directory=] @@ -147,6 +148,18 @@ a space) at the start of each line: possible for manual inspection; the exact format may change at any time. +--eol:: + Show line endings ("eolinfo") and the text/eol attributes ("texteolattr") of files. + "eolinfo" is the file content identification used by Git when + the "text" attribute is "auto", or core.autocrlf != false. + + "eolinfo" is either "" (when the the info is not available"), or one of "binary", + "text-no-eol", "text-lf", "text-crlf" or "text-crlf-lf". + The "texteolattr" can be "", "-text", "text", "text=auto", "eol=lf", "eol=crlf". + + Both the content in the index ("i/") and the content in the working tree ("w/") + are shown for regular files, followed by the "texteolattr ("attr/"). + \--:: Do not interpret any more arguments as options. @@ -161,6 +174,15 @@ which case it outputs: [ ] +'git ls-files --eol' will show + i/ w/ attr/ + +'git ls-files --eol -o' will show + i/ w/ attr/ + +'git ls-files --eol -s' will show +[ ] i/ w/ attr/ + 'git ls-files --unmerged' and 'git ls-files --stage' can be used to examine detailed information on unmerged paths. diff --git a/builtin/ls-files.c b/builtin/ls-files.c index b6a7cb0..9eacc64 100644 --- a/builtin/ls-files.c +++ b/builtin/ls-files.c @@ -27,6 +27,7 @@ static int show_killed; static int show_valid_bit; static int line_terminator = '\n'; static int debug_mode; +static int show_eol; static const char *prefix; static int max_prefix_len; @@ -47,6 +48,21 @@ static const char *tag_modified = ""; static const char *tag_skip_worktree = ""; static const char *tag_resolve_undo = ""; +static void write_eolinfo(const struct cache_entry *ce, const char *path) +{ + struct stat st; + const char *i_txt = ""; + const char *w_txt = ""; + if (!show_eol) + return; + if (ce && S_ISREG(ce->ce_mode)) + i_txt = get_cached_convert_stats_ascii(ce->name); + if (!lstat(path, ) && S_ISREG(st.st_mode)) + w_txt = get_wt_convert_stats_ascii(path); + printf("i/%-13s w/%-13s attr/%-9s ", i_txt, w_txt, +get_convert_attr_ascii(path)); +} + static void write_name(const char *name) {
Re: `format:%>` padding and `git log --graph`
Duy Nguyenwrites: > On Sun, Dec 20, 2015 at 10:41:44AM -0600, Elliott Cable wrote: >> I'm not sure what version the `%>` / `<|` / etc padding showed up in, >> but they're truly excellent for building beautiful one-line `git log` >> output. > > Somebody found my code useful!! :-D Is this related to http://thread.gmane.org/gmane.comp.version-control.git/277710/focus=278326 in any way? My gut feeling is that, while the original patch itself breaks existing uses and is not acceptable as-is, its idea is good, and we are OK with a change like that if it added a new/different kind of %>|(N) that makes the new behaviour available to those who want to use it, without negatively affecting existing uses. -- 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: RefTree: Alternate ref backend
On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggertywrote: > On 12/17/2015 10:02 PM, Shawn Pearce wrote: >> I started playing around with the idea of storing references directly >> in Git. Exploiting the GITLINK tree entry, we can associate a name to >> any SHA-1. >> >> By storing all references in a single tree, atomic transactions are >> possible. Its a simple compare-and-swap of a single 40 byte SHA-1. >> This of course leads to a bootstrapping problem, where do we store the >> 40 byte SHA-1? For this example its just $GIT_DIR/refs/txn/committed >> as a classical loose reference. > > I like this general idea a lot, even while recognizing some practical > problems that other people have pointed out. I especially like the idea > of having truly atomic multi-reference updates. > > I'm curious why you decided to store all of the references in a single > list, similar to the packed-refs file. This design means that the whole > object has to be rewritten whenever any reference is updated [1]. > Certainly, storing the references in a single tree *object* is not a > requirement for having atomic transitions. > > I would have expected a design where the layout of the references in > trees mimics the layout of loose references in the filesystem; e.g., one > tree object for "refs/", one for "refs/heads/" one for "refs/remotes/" > etc. This design would reduce the amount of rewriting that is needed > when one or a few references are updated. I did use tree objects for each directory component. The ls-tree I showed was an ls-tree -r. "heads" is a different subtree from "tags". I just skipped over the "refs/" top level subtree because its useless here. The root tree would always have one child, "refs", which normally has two children, "heads" and "tags". Why bother with the root at that point? So we do get minimum rewriting, tags tree is unmodified and reuses its tree node when you update master. > Another reason that I find a hierarchical layout intriguing would be > that one could imagine using the SHA-1s of reference namespace subtrees > to speed up the negotiation phase of "git fetch". In the common case > that I use the local namespace "refs/remotes/origin" to track an > upstream repo, the SHA-1 of my "refs/remotes/origin" tree would usually > represent a complete description of the state of the upstream references > at the time that I last fetched. My client could tell the server > > have-tree $SHA1 > > , where $SHA1 is the hash of the tree representing > "refs/remotes/origin/". If the server keeps a reflog as you have > described (but hierarchically), then the server could look up $SHA1 and > immediately know the full set of references, and therefore of objects, > that I fetched last time. More generally, the negotiation could proceed > down the reference namespace tree and stop whenever commonality is found. Yes. Martin Fick and I were discussing a strategy like this at the Gerrit User Summit in November. I totally forgot about it when I started this thread, but I'm glad you independently proposed it. Maybe its not a horrible idea! :) One problem is clients don't mirror the heads tree exactly; they add in HEAD as a symbolic reference in a way that the remote peer doesn't have. Minor detail. Martin and I were really thinking about server-server negotiation more than client-server. Consider a master Git server that Linus pushes too, and then a small farm of mirror servers that users actually clone from. If an update hook on the master does a git push to each mirror, the ls-remote advertisements is a non-trivial amount of data to exchange. If the mirror servers are supposed to exactly match the master, they can exchange all of their refs with a single SHA-1 instead of a big listing. This isn't so important for Linus' repository; its got a relatively small number of refs. We were thinking more about Gerrit Code Review where the refs/changes/ namespace is huge and may be causing a multi-megabyte advertisement. Its common in large companies to have many mirror slaves in remote offices mirroring the Gerrit server so that end-users can fetch from their office mirror more quickly. > There are a lot of "if"s in that last paragraph, and maybe it's not > workable. For example, if I'm not pruning on fetch, then my reference > tree won't be identical to one that was ever present on the server and > this technique wouldn't necessarily help. But if, for example, we change > the default to pruning, or perhaps record some extra reftree SHA-1's, > then in most cases I would expect that this trick could reduce the > effort of negotiation to negligible in most cases, and reduce the time > of the whole fetch to negligible in the case that the clone is already > up-to-date. Right, maybe the client just remember's the server's reftree SHA-1 and offers it back on reconnection. The server can then diff between the two reftrees and shows the client only refs that were modified that the client cares
Re: [PATCH 7/8] config: add core.untrackedCache
Duy Nguyenwrites: > In that case we can just check config once in read_index_from and > destroy UNTR extension. Or the middle ground, we check config once in > that place, make a note in struct index_state, and make invalidate_* > check that note instead of config file. The middle ground has an > advantage over destroying UNTR: (probably) many operations will touch > index but do not add or remove entries. Or we can even teach read_index_from() to skip reading the extension without even parsing when the configuration tells it that the feature is force-disabled. It can also add an empty one when the configuration tells it that the feature is force-enabled and there is no UNTR extension yet. -- 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] pretty: Pass graph width to pretty formatting for use in '%>|(N)'
(I'm joining the newer thread [1] back to this one, thanks for reminding me about this) [1] http://thread.gmane.org/gmane.comp.version-control.git/282771 On Tue, Sep 22, 2015 at 2:40 AM, Junio C Hamanowrote: > Josef Kufner writes: > >> Pass graph width to pretty formatting, so N in '%>|(N)' includes columns >> consumed by graph rendered when --graph option is in use. >> >> Example: >> git log --all --graph --pretty='format: [%>|(20)%h] %ar%d' >> >> All commit hashes should be aligned at 20th column from edge of the >> terminal, not from the edge of the graph. >> >> Signed-off-by: Josef Kufner >> --- > > [CC'ed Duy for ideas, as the "%>|(ALIGN)" thing is his invention] > > If you imagine an entry for a commit in the "git log" output as a > rectangle that has its commit log message, "--graph" draws a bunch > of lines on the left hand side and place these rectangles on the > right of these lines. Space allocated to each of these rectangles > may and do begin at a different column. For example, here is an > output from > > $ git log -12 --graph --oneline > > * 7d211c9 Merge branch 'jk/graph-format-padding' into pu > |\ > | * ead86db pretty: pass graph width to pretty formatting > * | 5be4874 Merge branch 'ld/p4-detached-head' into pu > |\ \ > | * | 4086903 git-p4: work with a detached head > | * | 6d2be82 git-p4: add failing test for submit from detached > head > * | | 7cec6a3 Merge branch 'ls/p4-lfs' into pu > |\ \ \ > | * | | 5fac7db git-p4: add Git LFS backend for large file system > | * | | 53b938f git-p4: add support for large file systems > | * | | 760e31c git-p4: return an empty list if a list config has > no values > | * | | c1e88b8 git-p4: add gitConfigInt reader > | * | | 465af7a git-p4: add optional type specifier to gitConfig > reader > * | | | 5197bd3 Merge branch 'nd/clone-linked-checkout' into pu > > I can understand why you would want to include the varying width of > the river on the left hand side in the "space allocated for the > commit", and under that mental model, the patch makes sense, but at > the same time, it is also a perfectly good specification to make > "%>|(20)%h" pad "%h" to 20 columns from the left edge of the space > given to the commit. > > I have a suspicion that 50% of the users would appreciate this > change, and the remainder of the users see this break their > expectation. To avoid such a regression, we may be better off if we > introduced a new alignment operator that is different from '%>|(N)' > so that this new behaviour is available to those who want to use it, > without negatively affecting existing uses. I tend to agree with Josef. >|(N) is about columns relative to the left edge of the screen. You can already use >(N) to be relative to the left edge of the space given to the commit. -- 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 2/2] Add a section to the users manual documenting shallow clones.
On Monday, December 21, 2015 10:47:16 PM Eric Sunshine wrote: > On Mon, Dec 21, 2015 at 9:09 PM, Stephen P. Smithwrote: > > [[repositories-and-branches]] > > Repositories and Branches > > = > > @@ -72,6 +71,25 @@ called the < >, together > > with a special > > top-level directory named `.git`, which contains all the information > > about the history of the project. > > > > +[[how-to-get-a-git-repository-with-minimal-history]] > > +How to get a Git repository with minimal history > > + > > Is this a good placement for this topic? Shallow repositories are not > heavily used, yet this placement amidst the very early and important > topics of cloning and checking out branches assigns potentially > significant (and perhaps unwarranted) weight to something used so > rarely. After some thought I think that the section should be moved near the bottom of "Sharing development with others" since 1) that would reduce the significance and 2) it seems that a shallow clone would normally be used for contributing to a large project when downloading the entire history is expensive. Should it be placed just above the Tony Luk example? sps -- 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
Pls Support Conservancy: https://sfconservancy.org/supporter/
[Jeff King, Shawn Pearce and myself represent the Git project to the Conservancy, and here is a request for help from us.] We apologize that we're interrupting the usual content on this mailing list with a fundraising message, but the non-profit home of the Git project, Software Freedom Conservancy, is in urgent need of your immediate support: https://sfconservancy.org/supporter/ Git receives a myriad of important services (see https://sfconservancy.org/members/services/ ) from Conservancy. We have relied on Conservancy since 2009 to provide them, and we ask that you support them. While Git gladly contributes 10% of our project's gross revenue to Conservancy's general fund, (while Conservancy maintains and administers the other 90% in collaboration with us to advance the Git project), that 10% of contributions from all Conservancy's member projects doesn't add up to enough to even employ one full time person, let alone the already overworked staff of three that Conservancy has. Conservancy's fundraiser, found at https://sfconservancy.org/supporter/ , is centered around asking individuals who care about the work that Conservancy does to donate $120/year, or just $10/month, to support the organization. Conservancy seeks about 2,500 Supporters to continue its current work, and 750 Supporters to continue a "bare minimum" of services to its projects. Here are some of the things that Conservancy does for Git that are in the "bare minimum" category: * Handle our Google Summer of Code payments and travel, including handling all financial transactions with Google to receive and then disperse the money. * Coordinating travel reimbursements for Git contributors to attend conferences. * Buying and shipping hardware to Git volunteer contributors who need it. * Keeping the non-profit status for us so that we don't have to form our own org and file our own paperwork. Here are some of the services Git has received in the wider category: * Dealing with questions from the community about the DCO and legal issues surrounding contributions to the Git project. * Discussing the issue of copyright governance and contributions with large corporations who want their employees to contribute to Git but need legal assurances or have questions relating to Git's license or contribution policies. * Helping us write the Git trademark policy: https://git-scm.com/trademark , registering the trademark, and enforcing the trademark when we need it. This assures Git users can know that when they see something called "Git", it relates to the Git project in some way. * And, in fact, we do very occasionally find companies violating the GPL on Git, and Conservancy has helped us out with that. As you can see, Git really relies on the important work of Conservancy, and thus the Git project leadership encourages you to choose Conservancy as one of your charitable gifts this holiday season. (Conservancy is a 501(c)(3) charity incorporated in New York, and donations are typically deductible on U.S. taxes.) Please visit: https://sfconservancy.org/supporter/ -- 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: RefTree: Alternate ref backend
On Tue, Dec 22, 2015 at 8:11 AM, Shawn Pearcewrote: > Yup, and Gerrit Code Review servers often have 100k+ refs per > repository. We can't rewrite the entire store every time either. So > its not a flat list. Its a directory structure using the / separators > in the ref namespace. I wonder if this might be insufficient in some cases, and additional sharding might be required (though I haven't thought about how to do that). Chromium, for example, has upwards of 10k tags: $ git ls-remote https://chromium.googlesource.com/chromium/src refs/tags/\* | wc -l 8733 And I doubt it's unique in this regard. -- 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 08/10] t/lib-httpd.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- t/lib-httpd.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/lib-httpd.sh b/t/lib-httpd.sh index e971446..f9f3e5f 100644 --- a/t/lib-httpd.sh +++ b/t/lib-httpd.sh @@ -98,8 +98,8 @@ then test_skip_or_die $GIT_TEST_HTTPD "no web server found at '$LIB_HTTPD_PATH'" fi -HTTPD_VERSION=`$LIB_HTTPD_PATH -v | \ - sed -n 's/^Server version: Apache\/\([0-9]*\)\..*$/\1/p; q'` +HTTPD_VERSION=$($LIB_HTTPD_PATH -v | \ + sed -n 's/^Server version: Apache\/\([0-9]*\)\..*$/\1/p; q') if test -n "$HTTPD_VERSION" then -- 2.3.3.GIT -- 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 03/10] contrib/examples/git-merge.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- contrib/examples/git-merge.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/examples/git-merge.sh b/contrib/examples/git-merge.sh index 52f2aaf..ee99f1a 100755 --- a/contrib/examples/git-merge.sh +++ b/contrib/examples/git-merge.sh @@ -523,10 +523,10 @@ do if test "$exit" -eq 1 then - cnt=`{ + cnt=$({ git diff-files --name-only git ls-files --unmerged - } | wc -l` + } | wc -l) if test $best_cnt -le 0 || test $cnt -le $best_cnt then best_strategy=$strategy -- 2.3.3.GIT -- 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 05/10] contrib/examples/git-revert.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- contrib/examples/git-revert.sh | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/contrib/examples/git-revert.sh b/contrib/examples/git-revert.sh index 7e2aad5..197838d 100755 --- a/contrib/examples/git-revert.sh +++ b/contrib/examples/git-revert.sh @@ -138,8 +138,8 @@ cherry-pick) }' logmsg=$(git show -s --pretty=raw --encoding="$encoding" "$commit") - set_author_env=`echo "$logmsg" | - LANG=C LC_ALL=C sed -ne "$pick_author_script"` + set_author_env=$(echo "$logmsg" | + LANG=C LC_ALL=C sed -ne "$pick_author_script") eval "$set_author_env" export GIT_AUTHOR_NAME export GIT_AUTHOR_EMAIL @@ -160,9 +160,9 @@ cherry-pick) esac >.msg eval GITHEAD_$head=HEAD -eval GITHEAD_$next='`git show -s \ +eval GITHEAD_$next='$(git show -s \ --pretty=oneline --encoding="$encoding" "$commit" | - sed -e "s/^[^ ]* //"`' + sed -e "s/^[^ ]* //")' export GITHEAD_$head GITHEAD_$next # This three way merge is an interesting one. We are at -- 2.3.3.GIT -- 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 06/10] contrib/thunderbird-patch-inline/appp.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- contrib/thunderbird-patch-inline/appp.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/thunderbird-patch-inline/appp.sh b/contrib/thunderbird-patch-inline/appp.sh index 8dc73ec..1053872 100755 --- a/contrib/thunderbird-patch-inline/appp.sh +++ b/contrib/thunderbird-patch-inline/appp.sh @@ -31,8 +31,8 @@ BODY=$(sed -e "1,/${SEP}/d" $1) CMT_MSG=$(sed -e '1,/^$/d' -e '/^---$/,$d' "${PATCH}") DIFF=$(sed -e '1,/^---$/d' "${PATCH}") -CCS=`echo -e "$CMT_MSG\n$HEADERS" | sed -n -e 's/^Cc: \(.*\)$/\1,/gp' \ - -e 's/^Signed-off-by: \(.*\)/\1,/gp'` +CCS=$(echo -e "$CMT_MSG\n$HEADERS" | sed -n -e 's/^Cc: \(.*\)$/\1,/gp' \ + -e 's/^Signed-off-by: \(.*\)/\1,/gp') echo "$SUBJECT" > $1 echo "Cc: $CCS" >> $1 -- 2.3.3.GIT -- 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 09/10] test-sha1.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- test-sha1.sh | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/test-sha1.sh b/test-sha1.sh index 0f0bc5d..cef4bcc 100755 --- a/test-sha1.sh +++ b/test-sha1.sh @@ -6,13 +6,13 @@ dd if=/dev/zero bs=1048576 count=100 2>/dev/null | while read expect cnt pfx do case "$expect" in '#'*) continue ;; esac - actual=` + actual=$( { test -z "$pfx" || echo "$pfx" dd if=/dev/zero bs=1048576 count=$cnt 2>/dev/null | perl -pe 'y/\000/g/' } | ./test-sha1 $cnt - ` + ) if test "$expect" = "$actual" then echo "OK: $expect $cnt $pfx" @@ -51,14 +51,14 @@ exit while read cnt pfx do - actual=` + actual=$( { test -z "$pfx" || echo "$pfx" dd if=/dev/zero bs=1048576 count=$cnt 2>/dev/null | perl -pe 'y/\000/g/' } | sha1sum | sed -e 's/ .*//' - ` + ) echo "$actual $cnt $pfx" done
[PATCH 02/10] contrib/examples/git-fetch.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- contrib/examples/git-fetch.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/examples/git-fetch.sh b/contrib/examples/git-fetch.sh index 5540709..57d2e56 100755 --- a/contrib/examples/git-fetch.sh +++ b/contrib/examples/git-fetch.sh @@ -146,13 +146,13 @@ esac reflist=$(get_remote_refs_for_fetch "$@") if test "$tags" then - taglist=`IFS=' ' && + taglist=$(IFS=' ' && echo "$ls_remote_result" | git show-ref --exclude-existing=refs/tags/ | while read sha1 name do echo ".${name}:${name}" - done` || exit + done) || exit if test "$#" -gt 1 then # remote URL plus explicit refspecs; we need to merge them. -- 2.3.3.GIT -- 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 04/10] contrib/examples/git-repack.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- contrib/examples/git-repack.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/examples/git-repack.sh b/contrib/examples/git-repack.sh index 96e3fed..672af93 100755 --- a/contrib/examples/git-repack.sh +++ b/contrib/examples/git-repack.sh @@ -67,8 +67,8 @@ case ",$all_into_one," in ,t,) args= existing= if [ -d "$PACKDIR" ]; then - for e in `cd "$PACKDIR" && find . -type f -name '*.pack' \ - | sed -e 's/^\.\///' -e 's/\.pack$//'` + for e in $(cd "$PACKDIR" && find . -type f -name '*.pack' \ + | sed -e 's/^\.\///' -e 's/\.pack$//') do if [ -e "$PACKDIR/$e.keep" ]; then : keep -- 2.3.3.GIT -- 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 07/10] git-gui/po/glossary/txt-to-pot.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- git-gui/po/glossary/txt-to-pot.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/git-gui/po/glossary/txt-to-pot.sh b/git-gui/po/glossary/txt-to-pot.sh index 49bf7c5..8249915 100755 --- a/git-gui/po/glossary/txt-to-pot.sh +++ b/git-gui/po/glossary/txt-to-pot.sh @@ -11,7 +11,7 @@ if [ $# -eq 0 ] then cat < git-gui-glossary.pot +Usage: $(basename $0) git-gui-glossary.txt > git-gui-glossary.pot ! exit 1; fi @@ -33,7 +33,7 @@ cat <\n" "Language-Team: LANGUAGE \n" -- 2.3.3.GIT -- 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 10/10] unimplemented.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- unimplemented.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/unimplemented.sh b/unimplemented.sh index 5252de4..fee21d2 100644 --- a/unimplemented.sh +++ b/unimplemented.sh @@ -1,4 +1,4 @@ #!/bin/sh -echo >&2 "fatal: git was built without support for `basename $0` (@@REASON@@)." +echo >&2 "fatal: git was built without support for $(basename $0) (@@REASON@@)." exit 128 -- 2.3.3.GIT -- 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 01/10] contrib/examples/git-commit.sh: use the $( ... ) construct for command substitution
The Git CodingGuidelines prefer the $(...) construct for command substitution instead of using the backquotes `...`. The backquoted form is the traditional method for command substitution, and is supported by POSIX. However, all but the simplest uses become complicated quickly. In particular, embedded command substitutions and/or the use of double quotes require careful escaping with the backslash character. The patch was generated by: for _f in $(find . -name "*.sh") do perl -i -pe 'BEGIN{undef $/;} s/`(.+?)`/\$(\1)/smg' "${_f}" done and then carefully proof-read. Signed-off-by: Elia Pinto--- contrib/examples/git-commit.sh | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/contrib/examples/git-commit.sh b/contrib/examples/git-commit.sh index 934505b..86c9cfa 100755 --- a/contrib/examples/git-commit.sh +++ b/contrib/examples/git-commit.sh @@ -574,10 +574,10 @@ then if test "$templatefile" != "" then # Test whether this is just the unaltered template. - if cnt=`sed -e '/^#/d' < "$templatefile" | + if cnt=$(sed -e '/^#/d' < "$templatefile" | git stripspace | diff "$GIT_DIR"/COMMIT_BAREMSG - | - wc -l` && + wc -l) && test 0 -lt $cnt then have_commitmsg=t @@ -630,8 +630,8 @@ then fi if test -z "$quiet" then - commit=`git diff-tree --always --shortstat --pretty="format:%h: %s"\ - --abbrev --summary --root HEAD --` + commit=$(git diff-tree --always --shortstat --pretty="format:%h: %s"\ + --abbrev --summary --root HEAD --) echo "Created${initial_commit:+ initial} commit $commit" fi fi -- 2.3.3.GIT -- 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 00/10] use the $( ... ) construct for command substitution
This patch series continues the changes introduced with the merge 6753d8a85d543253d95184ec2faad6dc197f248: Merge branch 'ep/shell-command-substitution' Adjust shell scripts to use $(cmd) instead of `cmd`. This is the first series, the other will be sent separately. Elia Pinto (10): contrib/examples/git-commit.sh: use the $( ... ) construct for command substitution contrib/examples/git-fetch.sh: use the $( ... ) construct for command substitution contrib/examples/git-merge.sh: use the $( ... ) construct for command substitution contrib/examples/git-repack.sh: use the $( ... ) construct for command substitution contrib/examples/git-revert.sh: use the $( ... ) construct for command substitution contrib/thunderbird-patch-inline/appp.sh: use the $( ... ) construct for command substitution git-gui/po/glossary/txt-to-pot.sh: use the $( ... ) construct for command substitution t/lib-httpd.sh: use the $( ... ) construct for command substitution test-sha1.sh: use the $( ... ) construct for command substitution unimplemented.sh: use the $( ... ) construct for command substitution contrib/examples/git-commit.sh | 8 contrib/examples/git-fetch.sh| 4 ++-- contrib/examples/git-merge.sh| 4 ++-- contrib/examples/git-repack.sh | 4 ++-- contrib/examples/git-revert.sh | 8 contrib/thunderbird-patch-inline/appp.sh | 4 ++-- git-gui/po/glossary/txt-to-pot.sh| 4 ++-- t/lib-httpd.sh | 4 ++-- test-sha1.sh | 8 unimplemented.sh | 2 +- 10 files changed, 25 insertions(+), 25 deletions(-) -- 2.3.3.GIT -- 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: Building Git with HTTPS support: avoiding libcurl?
On Tue, Dec 22, 2015 at 7:39 AM, Paul Smithwrote: > I'm trying to build Git (2.6.4) on GNU/Linux, but without any > requirements (other than basic libc etc.) on the local system. This > works fine except for one thing: git-remote-https. > > In order to build this I need to have libcurl, but libcurl is a MONSTER > library with an enormous number of prerequisites (see below). Well, IIUC one of the reasons for Git's fork-everything strategy is to avoid having to dynamically link the core git binary against large libraries like libcurl, so the dependency size has been taken into account at least in that sense. > Just wondering if anyone has considered an alternative to libcurl; maybe > I'm wrong but it seems to me that HTTPS support for Git would require > only a tiny fraction of the libcurl features and maybe there's an > alternative available which would be more targeted? > > I realize this is not a short-term thing in that there won't be an API > compatible library that can just be dropped in. This is more a forward > -looking question. For now I'm looking to see if I can rebuild libcurl > myself without most of these dependencies such as Kerberos, LDAP, etc. > > > $ ldd /usr/lib/x86_64-linux-gnu/libcurl.so.4 > linux-vdso.so.1 => (0x7fff37d81000) > libidn.so.11 => /usr/lib/x86_64-linux-gnu/libidn.so.11 > (0x7f682b921000) > librtmp.so.1 => /usr/lib/x86_64-linux-gnu/librtmp.so.1 > (0x7f682b704000) > libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 > (0x7f682b49a000) > libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 > (0x7f682b058000) > libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2 > (0x7f682ae0e000) > liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 > (0x7f682abfe000) > libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 > (0x7f682a9ac000) > libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f682a792000) > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 > (0x7f682a573000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f682a1a9000) > libgnutls-deb0.so.28 => > /usr/lib/x86_64-linux-gnu/libgnutls-deb0.so.28 (0x7f6829e8d000) > libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4 > (0x7f6829c59000) > libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6 > (0x7f6829a23000) > libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 > (0x7f68297a3000) > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f682959e000) > libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3 > (0x7f68292cc000) > libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3 > (0x7f682909d000) > libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 > (0x7f6828e98000) > libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0 > (0x7f6828c8d000) > libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 > (0x7f6828a71000) > libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 > (0x7f6828855000) > libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3 > (0x7f6828615000) > /lib64/ld-linux-x86-64.so.2 (0x559b03259000) > libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0 > (0x7f68283b) > libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6 > (0x7f682819c000) > libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 > (0x7f6827f98000) > libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0 > (0x7f6827d8e000) > libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26 > (0x7f6827b04000) > libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8 > (0x7f6827861000) > libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4 > (0x7f682762d000) > libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18 > (0x7f6827418000) > libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 > (0x7f682721) > libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0 > (0x7f6826fe6000) > libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1 > (0x7f6826dd7000) > libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5 > (0x7f6826b8c000) > libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 > (0x7f68268be000) > libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 > (0x7f6826686000) Maybe half of those dependencies are crypto libraries, so even if you managed to eliminate libcurl, you'd have a hard time supporting HTTPS without them. Or maybe use something like boringssl instead? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to
Re: RefTree: Alternate ref backend
On 12/22/2015 05:11 PM, Shawn Pearce wrote: > On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggerty> wrote: >> On 12/17/2015 10:02 PM, Shawn Pearce wrote: >>> I started playing around with the idea of storing references directly >>> in Git. Exploiting the GITLINK tree entry, we can associate a name to >>> any SHA-1. >> [...] >> I'm curious why you decided to store all of the references in a single >> list, similar to the packed-refs file. [...] > > I did use tree objects for each directory component. The ls-tree I > showed was an ls-tree -r. Silly me. Of course that was clear from your post, and I just overlooked it. >> Another reason that I find a hierarchical layout intriguing would be >> that one could imagine using the SHA-1s of reference namespace subtrees >> to speed up the negotiation phase of "git fetch". [...] > > Yes. Martin Fick and I were discussing a strategy like this at the > Gerrit User Summit in November. I totally forgot about it when I > started this thread, but I'm glad you independently proposed it. Maybe > its not a horrible idea! :) > > One problem is clients don't mirror the heads tree exactly; they add > in HEAD as a symbolic reference in a way that the remote peer doesn't > have. Minor detail. Yes, and this is a side effect of leaving out a layer of the remote reference namespace in the local refs/remotes layout. Naively one would expect refs/remotes/origin/HEAD refs/remotes/origin/refs/heads/master etc. But we store branches into the main "refs/remotes/origin/" namespace, leaving no reserved space for the remote "HEAD" (not to mention other namespaces that might appear on the remote, such as "refs/changes/*", "refs/pull/*", a separate record of the remote's "refs/tags/*", etc). Maybe that is why my gut reaction to your proposal to elide the "refs" part of the reference hierarchy and store "HEAD" as (effectively) "refs/..HEAD" was negative, even though I can't think of any practical objections. At a deeper level, the "refs/" part of reference names is actually pretty useless in general. I suppose it originated in the practice of storing loose references under "refs/" to keep them separate from other metadata in $GIT_DIR. But really, aside from slightly helping disambiguate references from paths in the command line, what is it good for? Would we really be worse off if references' full names were HEAD heads/master tags/v1.0.0 remotes/origin/master (or remotes/origin/heads/master) etc? This notation is already recognized in most places (though not in "update-ref"). I think your decision to elide "refs/" in the reftree hierarchy is a reflection of its uselessness. In any case, your decision is much less questionable than the decision to mash "refs/heads/*" all the way up to the top level like we do in "refs/remotes/". > Martin and I were really thinking about server-server negotiation more > than client-server. [...] Yes, that's also an interesting application. >> There are a lot of "if"s in that last paragraph, and maybe it's not >> workable. For example, if I'm not pruning on fetch, then my reference >> tree won't be identical to one that was ever present on the server and >> this technique wouldn't necessarily help. But if, for example, we change >> the default to pruning, or perhaps record some extra reftree SHA-1's, >> then in most cases I would expect that this trick could reduce the >> effort of negotiation to negligible in most cases, and reduce the time >> of the whole fetch to negligible in the case that the clone is already >> up-to-date. > > Right, maybe the client just remember's the server's reftree SHA-1 and > offers it back on reconnection. The server can then diff between the > two reftrees and shows the client only refs that were modified that > the client cares about. The client not only has to remember the server's reftree, but also must verify that it still has all of the objects implied by that reftree, in case a reference somehow got deleted under "refs/remotes/origin/*". At that point, there is no special reason to use a SHA-1 in the negotiation; any unique token generated by the server would suffice if the server can connect it back to a set of references that was sent to the client in the past. The advantage of using hierarchical reftree SHA-1s in the negotiation is that they can be used to name part of the reftree. For example, if I fetch "refs/heads/*" from a remote but not "refs/changes/*", then what do I report as my "have-tree"? I can't claim to have *all* of the references that the remote had at the time. But with SHA-1s I can say that I have the reftree that corresponds to my "refs/remotes/origin/heads/", which the remote can notice is identical to an old reftree that it happened to have for "refs/heads/" (without even caring what path it represented). Bingo, we've just agreed about a big part of the reference namespace without having to agree about the whole namespace. In practice, in
Re: Building Git with HTTPS support: avoiding libcurl?
On Tue, 2015-12-22 at 09:08 -0800, Dave Borowitz wrote: > Well, IIUC one of the reasons for Git's fork-everything strategy is to > avoid having to dynamically link the core git binary against large > libraries like libcurl, so the dependency size has been taken into > account at least in that sense. Sure, and it's great that I still get most Git even if I don't have libcurl. But without support for cloning https remotes there's a significant hole in Git functionality... I grok that Git doesn't want to re-invent the wheel and that libcurl is convenient. I just wonder if anyone knows of another wheel, that doesn't come attached to an entire tractor-trailer, that could be used instead :). -- 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] l10n: de.po: translate 68 new messages
Translate 68 new messages came from git.pot update in f4f2c8f (l10n: git.pot: v2.7.0 round 1 (66 new, 29 removed)) and 2c0ca05 (l10n: git.pot: v2.7.0 round 2 (2 new, 2 removed)). Signed-off-by: Ralf Thielow--- po/de.po | 190 --- 1 file changed, 84 insertions(+), 106 deletions(-) diff --git a/po/de.po b/po/de.po index 1ce4193..4a1fecf 100644 --- a/po/de.po +++ b/po/de.po @@ -32,17 +32,16 @@ msgstr "" "und zu committen." #: advice.c:101 builtin/merge.c:1225 msgid "You have not concluded your merge (MERGE_HEAD exists)." msgstr "Sie haben Ihren Merge nicht abgeschlossen (MERGE_HEAD existiert)." #: advice.c:103 -#, fuzzy msgid "Please, commit your changes before merging." -msgstr "Bitte committen Sie Ihre Änderungen, bevor Sie den Merge ausführen." +msgstr "Bitte committen Sie Ihre Änderungen, bevor Sie mergen." #: advice.c:104 msgid "Exiting because of unfinished merge." msgstr "Beende wegen nicht abgeschlossenem Merge." #: archive.c:12 msgid "git archive [] [...]" @@ -1110,54 +1109,54 @@ msgstr "Konnte Referenzen nicht entfernen: %s" #, c-format msgid "could not remove reference %s" msgstr "Konnte Referenz %s nicht löschen" #: ref-filter.c:245 #, c-format msgid "format: %%(end) atom used without corresponding atom" -msgstr "" +msgstr "format: %%(end) Atom ohne zugehöriges Atom verwendet" #: ref-filter.c:704 #, c-format msgid "positive value expected contents:lines=%s" -msgstr "" +msgstr "Positiver Wert erwartet contents:lines=%s" #: ref-filter.c:833 #, c-format msgid "expected format: %%(color:)" -msgstr "" +msgstr "Erwartetes Format: %%(color:)" #: ref-filter.c:835 msgid "unable to parse format" msgstr "Konnte Format nicht parsen." #: ref-filter.c:870 #, c-format msgid "expected format: %%(align:,)" -msgstr "" +msgstr "Erwartetes Format: %%(align:,)" #: ref-filter.c:893 #, c-format msgid "improper format entered align:%s" -msgstr "" +msgstr "Ungültiges Format eingegeben align:%s" #: ref-filter.c:898 #, c-format msgid "positive width expected with the %%(align) atom" -msgstr "" +msgstr "Positive Breitenangabe für %%(align) erwartet" #: ref-filter.c:1219 #, c-format msgid "malformed object at '%s'" msgstr "fehlerhaftes Objekt bei '%s'" #: ref-filter.c:1561 #, c-format msgid "format: %%(end) atom missing" -msgstr "" +msgstr "format: %%(end) Atom fehlt" #: ref-filter.c:1615 #, c-format msgid "malformed object name %s" msgstr "Missgebildeter Objektname %s" #: remote.c:756 @@ -2632,22 +2631,20 @@ msgstr "" #: builtin/am.c:2220 #, c-format msgid "Invalid value for --patch-format: %s" msgstr "Ungültiger Wert für --patch-format: %s" #: builtin/am.c:2253 -#, fuzzy msgid "git am [] [(|)...]" -msgstr "git am [Optionen] [(|)...]" +msgstr "git am [] [(|)...]" #: builtin/am.c:2254 -#, fuzzy msgid "git am [] (--continue | --skip | --abort)" -msgstr "git am [Optionen] (--continue | --skip | --abort)" +msgstr "git am [] (--continue | --skip | --abort)" #: builtin/am.c:2260 msgid "run interactively" msgstr "interaktiv ausführen" #: builtin/am.c:2262 msgid "historical option -- no-op" @@ -3476,17 +3473,16 @@ msgid "git branch [] [-r] (-d | -D) ..." msgstr "git branch [] [-r] (-d | -D) ..." #: builtin/branch.c:28 msgid "git branch [] (-m | -M) [] " msgstr "git branch [] (-m | -M) [] " #: builtin/branch.c:29 -#, fuzzy msgid "git branch [] [-r | -a] [--points-at]" -msgstr "git branch [] [-r | -a] [--merged | --no-merged]" +msgstr "git branch [] [-r | -a] [--points-at]" #: builtin/branch.c:142 #, c-format msgid "" "deleting branch '%s' that has been merged to\n" " '%s', but not yet merged to HEAD." msgstr "" @@ -3738,22 +3734,20 @@ msgid "edit the description for the branch" msgstr "die Beschreibung für den Branch bearbeiten" #: builtin/branch.c:644 msgid "force creation, move/rename, deletion" msgstr "Erstellung, Verschiebung/Umbenennung oder Löschung erzwingen" #: builtin/branch.c:645 -#, fuzzy msgid "print only branches that are merged" -msgstr "nur Branches ausgeben, welche diesen Commit beinhalten" +msgstr "nur zusammengeführte Branches ausgeben" #: builtin/branch.c:646 -#, fuzzy msgid "print only branches that are not merged" -msgstr "nur Branches ausgeben, welche diesen Commit beinhalten" +msgstr "nur nicht zusammengeführte Branches ausgeben" #: builtin/branch.c:647 msgid "list branches in columns" msgstr "Branches in Spalten auflisten" #: builtin/branch.c:648 builtin/for-each-ref.c:38 builtin/tag.c:366 msgid "key" @@ -3766,17 +3760,16 @@ msgstr "sortiere nach diesem Feld" #: builtin/branch.c:651 builtin/for-each-ref.c:41 builtin/notes.c:398 #: builtin/notes.c:401 builtin/notes.c:561 builtin/notes.c:564 #: builtin/tag.c:369 msgid "object" msgstr "Objekt" #: builtin/branch.c:652 -#, fuzzy msgid "print only branches of the object" -msgstr "nur Tags von dem Objekt ausgeben" +msgstr
[PATCH V3 1/2] glossary: define the term shallow clone
There are several places in the documentation that the term shallow clone is used. Defining the term enables its use elsewhere with a known definition. Signed-off-by: Stephen P. Smith--- Documentation/glossary-content.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt index e225974..cecc83d 100644 --- a/Documentation/glossary-content.txt +++ b/Documentation/glossary-content.txt @@ -531,6 +531,10 @@ The most notable example is `HEAD`. "Secure Hash Algorithm 1"; a cryptographic hash function. In the context of Git used as a synonym for < >. +[[def_shallow_clone]]shallow clone:: + A clone of a < > which creates a + < >. + [[def_shallow_repository]]shallow repository:: A shallow < > has an incomplete history some of whose < > have < > cauterized away (in other -- 2.6.3.368.gf34be46 -- 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 00/10] use the $( ... ) construct for command substitution
Elia Pinto wrote: > This is the first series, the other will be sent separately. FWIW, Reviewed-by: Jonathan Nieder-- 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: RefTree: Alternate ref backend
On Tuesday, December 22, 2015 06:17:28 PM you wrote: > On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggertywrote: > > At a deeper level, the "refs/" part of reference names is > actually pretty useless in general. I suppose it > originated in the practice of storing loose references > under "refs/" to keep them separate from other metadata > in $GIT_DIR. But really, aside from slightly helping > disambiguate references from paths in the command line, > what is it good for? Would we really be worse off if > references' full names were > > HEAD > heads/master > tags/v1.0.0 > remotes/origin/master (or remotes/origin/heads/master) I think this is a bit off, because HEAD != refs/HEAD so not quite useless. But, I agree that the whole refs notation has always bugged me, it is quirky. It makes it hard to disambiguate when something is meant to be absolute or not. What if we added a leading slash for absolute references? Then I could do something like: /HEAD /refs/heads/master /refs/tags/v1.0.0 /refs/remotes/origin/master I don't like that plumbing has to do a dance to guess at expansions, how many tools get it wrong (do it in different orders, miss some expansions...). With an absolute notation, plumbing could be built to require absolute notations, giving more predictable interpretations when called from tools. This is a long term idea, but it might make sense to consider it now just for the sake of storing refs, it would eliminate the need for the ".." notation for "refs/..HEAD". Now if we could only figure out a way to tell plumbing that something is a SHA, not a ref? :) -Martin -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/2] user-manual: add section documenting shallow clones
On Tue, Dec 22, 2015 at 10:53 PM, Stephen P. Smithwrote: > Rather than merely pointing readers at the 1.5 release notes to > learn about shallow clones, document them formally. Thanks, this version looks better. A few comment below... > Signed-off-by: Stephen P. Smith > --- Right here, below the "---" line is a good place to describe what changed since the previous version. It's also reviewer-friendly to include a link to the last attempt, like this [1]. [1]: http://thread.gmane.org/gmane.comp.version-control.git/282828 > Documentation/user-manual.txt | 21 ++--- > 1 file changed, 18 insertions(+), 3 deletions(-) > > diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt > @@ -2128,6 +2128,24 @@ The gitweb cgi script provides users an easy way to > browse your > project's files and history without having to install Git; see the file > gitweb/INSTALL in the Git source tree for instructions on setting it up. > > +[[how-to-get-a-git-repository-with-minimal-history]] > +How to get a Git repository with minimal history > + > + > +A < > is useful when the recent > +history of a project is needed and getting real history recorded in Saying "full history" rather than "real history" might read better and be more meaningful. Also, perhaps say "from the upstream" rather than "recorded in the upstream". > +the upstream is expensive. The resultant cloned < > > +has truncated history. This clone could be used to look at history > +near the tip of a branch and contribute email patches to the project. The final sentence pretty much just repeats what the first sentence said, thus doesn't really add any value, thus perhaps ought to be dropped. A possible rewrite of the above paragraph: A < >, with its truncated history, is useful when one is interested only in recent history of a project and getting full history from the upstream is expensive. > +A < > is created by specifying the > +depth when creating a clone of a repository using the > +linkgit:git-clone[1] `--depth` switch. The depth can later be changed > +by using the linkgit:git-fetch[1] `--depth` switch. If there is later > +a need to fetch the entire history and if the source repository is > +complete, the linkgit:git-fetch[1] `--unshallow` switch can be used to > +convert a shallow repository to a complete one. Taken together, the last two sentences are a bit wordy. I wonder if combining them and being somewhat more laconic would help: A < > is created by specifying the linkgit:git-clone[1] `--depth` switch. The depth can later be changed with the linkgit:git-fetch[1] `--depth` switch, or full history restored with `--unshallow`. > [[sharing-development-examples]] > Examples > > @@ -4645,9 +4663,6 @@ standard end-of-chapter section? > > Include cross-references to the glossary, where appropriate. > > -Document shallow clones? See draft 1.5.0 release notes for some > -documentation. > - > Add a section on working with other version control systems, including > CVS, Subversion, and just imports of series of release tarballs. > > -- > 2.6.3.368.gf34be46 -- 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