[PATCH 07/10] t/t2025-worktree-add.sh: use the $( ... ) construct for command substitution

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Jiang Xin]

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 Xin 

You 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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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?

[Paul Smith]

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

[Junio C Hamano]

Shawn Pearce  writes:

> 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

[Christian Couder]

Hi,

On Tue, Dec 22, 2015 at 6:53 PM, Pierre-Luc Loyer
 wrote:
> 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

[Stephen P. Smith]

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

[Shawn Pearce]

On Tue, Dec 22, 2015 at 9:17 AM, Michael Haggerty  wrote:
>
> 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

[Junio C Hamano]

David Turner  writes:

> 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

[Ralf Thielow]

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

[Junio C Hamano]

Martin Fick  writes:

> ...  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

[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*

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

[Shawn Pearce]

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/

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

[Junio C Hamano]

Pierre-Luc Loyer  writes:

> 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

[Johannes Sixt]

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)'

[Junio C Hamano]

Duy Nguyen  writes:

> (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

[Junio C Hamano]

Torsten Bögershausen  writes:

> 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

[Junio C Hamano]

Lars Schneider  writes:

> 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"

[Junio C Hamano]

Duy Nguyen  writes:

> 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

[Stephen P. Smith]

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

[Junio C Hamano]

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?

--
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

[Jonathan Nieder]

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

[David Turner]

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

[Ralf Thielow]

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

[Pierre-Luc Loyer]

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

[Junio C Hamano]

Duy Nguyen  writes:

> 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

[Alexander 'z33ky' Hirsch]

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

[Junio C Hamano]

Ralf Thielow  writes:

> 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

[Junio C Hamano]

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

[Stephen P. Smith]

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

[Michael Haggerty]

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

[Michael Haggerty]

On 12/22/2015 08:34 PM, Junio C Hamano wrote:
> Shawn Pearce  writes:
> 
>> 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

[Michael Haggerty]

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

[Stephen & Linda Smith]

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

[David Turner]

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

[Michael Haggerty]

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

[Duy Nguyen]

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.
-- 
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

[Duy Nguyen]

On Tue, Dec 22, 2015 at 1:30 AM, Junio C Hamano  wrote:
> 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.

[Dennis Kaarsemaker]

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

[Lars Schneider]

On 21 Dec 2015, at 21:31, Junio C Hamano  wrote:

> 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.

[Jeff King]

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

[Lars Schneider]

On 21 Dec 2015, at 21:38, Junio C Hamano  wrote:

> 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

[Lars Schneider]

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`

[Duy Nguyen]

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

[Duy Nguyen]

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". 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

[Torsten Bögershausen]

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 Sunshine 
Signed-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`

[Junio C Hamano]

Duy Nguyen  writes:

> 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

[Shawn Pearce]

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.
>>
>> 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

[Junio C Hamano]

Duy Nguyen  writes:

> 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)'

[Duy Nguyen]

(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]
>
> 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.

[Stephen & Linda Smith]

On Monday, December 21, 2015 10:47:16 PM Eric Sunshine wrote:
> On Mon, Dec 21, 2015 at 9:09 PM, Stephen P. Smith  wrote:
> >  [[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/

[Junio C Hamano]

[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

[Dave Borowitz]

On Tue, Dec 22, 2015 at 8:11 AM, Shawn Pearce  wrote:
> 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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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

[Elia Pinto]

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?

[Dave Borowitz]

On Tue, Dec 22, 2015 at 7:39 AM, Paul Smith  wrote:
> 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

[Michael Haggerty]

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?

[Paul Smith]

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

[Ralf Thielow]

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

[Stephen P. Smith]

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

[Jonathan Nieder]

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

[Martin Fick]

On Tuesday, December 22, 2015 06:17:28 PM you wrote:
> On Tue, Dec 22, 2015 at 7:41 AM, Michael Haggerty
 wrote:
>
> 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

[Eric Sunshine]

On Tue, Dec 22, 2015 at 10:53 PM, Stephen P. Smith  wrote:
> 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