* [PATCHv2 2/2] t1200: Make documentation and test agree
From: Stephen Boyd @ 2009-11-05 6:33 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1257402833-4741-1-git-send-email-bebarino@gmail.com>
There were some differences between t1200 and the gitcore-tutorial. Add
missing tests for manually merging two branches, and use the same
commands in both files.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
This is all new since v1
Documentation/gitcore-tutorial.txt | 20 ++++----
t/t1200-tutorial.sh | 97 ++++++++++++++++++++++++++++++++---
2 files changed, 98 insertions(+), 19 deletions(-)
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index b3640c4..7bdf090 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -185,7 +185,7 @@ object is. git will tell you that you have a "blob" object (i.e., just a
regular file), and you can see the contents with
----------------
-$ git cat-file "blob" 557db03
+$ git cat-file blob 557db03
----------------
which will print out "Hello World". The object `557db03` is nothing
@@ -1188,7 +1188,7 @@ $ git show-branch
--
+ [mybranch] Some work.
* [master] Some fun.
-*+ [mybranch^] New day.
+*+ [mybranch^] Initial commit
------------
Now we are ready to experiment with the merge by hand.
@@ -1204,11 +1204,11 @@ $ mb=$(git merge-base HEAD mybranch)
The command writes the commit object name of the common ancestor
to the standard output, so we captured its output to a variable,
because we will be using it in the next step. By the way, the common
-ancestor commit is the "New day." commit in this case. You can
+ancestor commit is the "Initial commit" commit in this case. You can
tell it by:
------------
-$ git name-rev $mb
+$ git name-rev --name-only --tags $mb
my-first-tag
------------
@@ -1237,8 +1237,8 @@ inspect the index file with this command:
------------
$ git ls-files --stage
100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
-100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
-100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
+100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello
+100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
------------
@@ -1253,8 +1253,8 @@ To look at only non-zero stages, use `\--unmerged` flag:
------------
$ git ls-files --unmerged
-100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
-100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
+100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello
+100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
------------
@@ -1283,8 +1283,8 @@ the working tree.. This can be seen if you run `ls-files
------------
$ git ls-files --stage
100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
-100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello
-100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello
+100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello
+100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
------------
diff --git a/t/t1200-tutorial.sh b/t/t1200-tutorial.sh
index c57c9d5..299e724 100755
--- a/t/t1200-tutorial.sh
+++ b/t/t1200-tutorial.sh
@@ -47,8 +47,9 @@ test_expect_success 'tree' '
'
test_expect_success 'git diff-index -p HEAD' '
- echo "Initial commit" | \
- git commit-tree $(git write-tree) 2>&1 > .git/refs/heads/master &&
+ tree=$(git write-tree)
+ commit=$(echo "Initial commit" | git commit-tree $tree) &&
+ git update-ref HEAD $commit &&
git diff-index -p HEAD > diff.output &&
cmp diff.expect diff.output
'
@@ -131,16 +132,18 @@ Work, work, work
EOF
cat > show-branch.expect << EOF
-* [master] Merged "mybranch" changes.
+* [master] Merge work in mybranch
! [mybranch] Some work.
--
-- [master] Merged "mybranch" changes.
+- [master] Merge work in mybranch
*+ [mybranch] Some work.
+* [master^] Some fun.
EOF
test_expect_success 'git show-branch' '
- git commit -m "Merged \"mybranch\" changes." -i hello &&
- git show-branch --topo-order master mybranch > show-branch.output &&
+ git commit -m "Merge work in mybranch" -i hello &&
+ git show-branch --topo-order --more=1 master mybranch \
+ > show-branch.output &&
cmp show-branch.expect show-branch.output
'
@@ -160,10 +163,10 @@ test_expect_success 'git resolve' '
'
cat > show-branch2.expect << EOF
-! [master] Merged "mybranch" changes.
- * [mybranch] Merged "mybranch" changes.
+! [master] Merge work in mybranch
+ * [mybranch] Merge work in mybranch
--
--- [master] Merged "mybranch" changes.
+-- [master] Merge work in mybranch
EOF
test_expect_success 'git show-branch (part 2)' '
@@ -171,6 +174,82 @@ test_expect_success 'git show-branch (part 2)' '
cmp show-branch2.expect show-branch2.output
'
+cat > show-branch3.expect << EOF
+! [master] Merge work in mybranch
+ * [mybranch] Merge work in mybranch
+--
+-- [master] Merge work in mybranch
++* [master^2] Some work.
++* [master^] Some fun.
+EOF
+
+test_expect_success 'git show-branch (part 3)' '
+ git show-branch --topo-order --more=2 master mybranch \
+ > show-branch3.output &&
+ cmp show-branch3.expect show-branch3.output
+'
+
+test_expect_success 'rewind to "Some fun." and "Some work."' '
+ git checkout mybranch &&
+ git reset --hard master^2 &&
+ git checkout master &&
+ git reset --hard master^
+'
+
+cat > show-branch4.expect << EOF
+* [master] Some fun.
+ ! [mybranch] Some work.
+--
+ + [mybranch] Some work.
+* [master] Some fun.
+*+ [mybranch^] Initial commit
+EOF
+
+test_expect_success 'git show-branch (part 4)' '
+ git show-branch --topo-order > show-branch4.output &&
+ cmp show-branch4.expect show-branch4.output
+'
+
+test_expect_success 'manual merge' '
+ mb=$(git merge-base HEAD mybranch) &&
+ git name-rev --name-only --tags $mb > name-rev.output &&
+ test "my-first-tag" = $(cat name-rev.output) &&
+
+ git read-tree -m -u $mb HEAD mybranch
+'
+
+cat > ls-files.expect << EOF
+100644 7f8b141b65fdcee47321e399a2598a235a032422 0 example
+100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello
+100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello
+100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
+EOF
+
+test_expect_success 'git ls-files --stage' '
+ git ls-files --stage > ls-files.output &&
+ cmp ls-files.expect ls-files.output
+'
+
+cat > ls-files-unmerged.expect << EOF
+100644 557db03de997c86a4a028e1ebd3a1ceb225be238 1 hello
+100644 ba42a2a96e3027f3333e13ede4ccf4498c3ae942 2 hello
+100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello
+EOF
+
+test_expect_success 'git ls-files --unmerged' '
+ git ls-files --unmerged > ls-files-unmerged.output &&
+ cmp ls-files-unmerged.expect ls-files-unmerged.output
+'
+
+test_expect_success 'git-merge-index' '
+ test_must_fail git merge-index git-merge-one-file hello
+'
+
+test_expect_success 'git ls-files --stage (part 2)' '
+ git ls-files --stage > ls-files.output2 &&
+ cmp ls-files.expect ls-files.output2
+'
+
test_expect_success 'git repack' 'git repack'
test_expect_success 'git prune-packed' 'git prune-packed'
test_expect_success '-> only packed objects' '
--
1.6.5.2.143.g8cc62
^ permalink raw reply related
* [PATCHv2 1/2] t1200: cleanup and modernize test style
From: Stephen Boyd @ 2009-11-05 6:33 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <1257282328-6491-1-git-send-email-bebarino@gmail.com>
Many parts of the tests in t1200 are run outside the test harness,
circumventing the usefulness of -v and spewing messages to stdout when
-v isn't used. Fix these problems by modernizing the test a bit.
An extra test_done has existed since commit 6a74642 (git-commit --amend:
two fixes., 2006-04-20) leading to the last 6 tests never being run.
Remove it and teach the resolve merge test about fast-forward merges.
Also fix the last test's incorrect find command and prune before
checking for unpacked objects so we remove the unreachable conflict-marked
blob.
Finally, we remove the TODO notes, because fetch, push, and clone have
their own tests since t1200 was introduced and we're not going to add
them here 4 years later.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
Since v1:
* Fixed the last test
t/t1200-tutorial.sh | 134 +++++++++++++++++++++++++++++----------------------
1 files changed, 76 insertions(+), 58 deletions(-)
diff --git a/t/t1200-tutorial.sh b/t/t1200-tutorial.sh
index 67e637b..c57c9d5 100755
--- a/t/t1200-tutorial.sh
+++ b/t/t1200-tutorial.sh
@@ -7,14 +7,18 @@ test_description='A simple turial in the form of a test case'
. ./test-lib.sh
-echo "Hello World" > hello
-echo "Silly example" > example
+test_expect_success 'blob' '
+ echo "Hello World" > hello &&
+ echo "Silly example" > example &&
-git update-index --add hello example
+ git update-index --add hello example &&
-test_expect_success 'blob' "test blob = \"$(git cat-file -t 557db03)\""
+ test blob = "$(git cat-file -t 557db03)"
+'
-test_expect_success 'blob 557db03' "test \"Hello World\" = \"$(git cat-file blob 557db03)\""
+test_expect_success 'blob 557db03' '
+ test "Hello World" = "$(git cat-file blob 557db03)"
+'
echo "It's a new day for git" >>hello
cat > diff.expect << EOF
@@ -26,25 +30,33 @@ index 557db03..263414f 100644
Hello World
+It's a new day for git
EOF
-git diff-files -p > diff.output
-test_expect_success 'git diff-files -p' 'cmp diff.expect diff.output'
-git diff > diff.output
-test_expect_success 'git diff' 'cmp diff.expect diff.output'
-
-tree=$(git write-tree 2>/dev/null)
-test_expect_success 'tree' "test 8988da15d077d4829fc51d8544c097def6644dbb = $tree"
+test_expect_success 'git diff-files -p' '
+ git diff-files -p > diff.output &&
+ cmp diff.expect diff.output
+'
-output="$(echo "Initial commit" | git commit-tree $(git write-tree) 2>&1 > .git/refs/heads/master)"
+test_expect_success 'git diff' '
+ git diff > diff.output &&
+ cmp diff.expect diff.output
+'
-git diff-index -p HEAD > diff.output
-test_expect_success 'git diff-index -p HEAD' 'cmp diff.expect diff.output'
+test_expect_success 'tree' '
+ tree=$(git write-tree 2>/dev/null)
+ test 8988da15d077d4829fc51d8544c097def6644dbb = $tree
+'
-git diff HEAD > diff.output
-test_expect_success 'git diff HEAD' 'cmp diff.expect diff.output'
+test_expect_success 'git diff-index -p HEAD' '
+ echo "Initial commit" | \
+ git commit-tree $(git write-tree) 2>&1 > .git/refs/heads/master &&
+ git diff-index -p HEAD > diff.output &&
+ cmp diff.expect diff.output
+'
-#rm hello
-#test_expect_success 'git read-tree --reset HEAD' "git read-tree --reset HEAD ; test \"hello: needs update\" = \"$(git update-index --refresh)\""
+test_expect_success 'git diff HEAD' '
+ git diff HEAD > diff.output &&
+ cmp diff.expect diff.output
+'
cat > whatchanged.expect << EOF
commit VARIABLE
@@ -69,39 +81,45 @@ index 0000000..557db03
+Hello World
EOF
-git whatchanged -p --root | \
- sed -e "1s/^\(.\{7\}\).\{40\}/\1VARIABLE/" \
+test_expect_success 'git whatchanged -p --root' '
+ git whatchanged -p --root | \
+ sed -e "1s/^\(.\{7\}\).\{40\}/\1VARIABLE/" \
-e "2,3s/^\(.\{8\}\).*$/\1VARIABLE/" \
-> whatchanged.output
-test_expect_success 'git whatchanged -p --root' 'cmp whatchanged.expect whatchanged.output'
-
-git tag my-first-tag
-test_expect_success 'git tag my-first-tag' 'cmp .git/refs/heads/master .git/refs/tags/my-first-tag'
+ > whatchanged.output &&
+ cmp whatchanged.expect whatchanged.output
+'
-# TODO: test git clone
+test_expect_success 'git tag my-first-tag' '
+ git tag my-first-tag &&
+ cmp .git/refs/heads/master .git/refs/tags/my-first-tag
+'
-git checkout -b mybranch
-test_expect_success 'git checkout -b mybranch' 'cmp .git/refs/heads/master .git/refs/heads/mybranch'
+test_expect_success 'git checkout -b mybranch' '
+ git checkout -b mybranch &&
+ cmp .git/refs/heads/master .git/refs/heads/mybranch
+'
cat > branch.expect <<EOF
master
* mybranch
EOF
-git branch > branch.output
-test_expect_success 'git branch' 'cmp branch.expect branch.output'
+test_expect_success 'git branch' '
+ git branch > branch.output &&
+ cmp branch.expect branch.output
+'
-git checkout mybranch
-echo "Work, work, work" >>hello
-git commit -m 'Some work.' -i hello
+test_expect_success 'git resolve now fails' '
+ git checkout mybranch &&
+ echo "Work, work, work" >>hello &&
+ git commit -m "Some work." -i hello &&
-git checkout master
+ git checkout master &&
-echo "Play, play, play" >>hello
-echo "Lots of fun" >>example
-git commit -m 'Some fun.' -i hello example
+ echo "Play, play, play" >>hello &&
+ echo "Lots of fun" >>example &&
+ git commit -m "Some fun." -i hello example &&
-test_expect_success 'git resolve now fails' '
test_must_fail git merge -m "Merge work in mybranch" mybranch
'
@@ -112,10 +130,6 @@ Play, play, play
Work, work, work
EOF
-git commit -m 'Merged "mybranch" changes.' -i hello
-
-test_done
-
cat > show-branch.expect << EOF
* [master] Merged "mybranch" changes.
! [mybranch] Some work.
@@ -124,21 +138,26 @@ cat > show-branch.expect << EOF
*+ [mybranch] Some work.
EOF
-git show-branch --topo-order master mybranch > show-branch.output
-test_expect_success 'git show-branch' 'cmp show-branch.expect show-branch.output'
-
-git checkout mybranch
+test_expect_success 'git show-branch' '
+ git commit -m "Merged \"mybranch\" changes." -i hello &&
+ git show-branch --topo-order master mybranch > show-branch.output &&
+ cmp show-branch.expect show-branch.output
+'
cat > resolve.expect << EOF
-Updating from VARIABLE to VARIABLE
+Updating VARIABLE..VARIABLE
+Fast forward (no commit created; -m option ignored)
example | 1 +
hello | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
EOF
-git merge -s "Merge upstream changes." master | \
- sed -e "1s/[0-9a-f]\{40\}/VARIABLE/g" >resolve.output
-test_expect_success 'git resolve' 'cmp resolve.expect resolve.output'
+test_expect_success 'git resolve' '
+ git checkout mybranch &&
+ git merge -m "Merge upstream changes." master | \
+ sed -e "1s/[0-9a-f]\{7\}/VARIABLE/g" >resolve.output &&
+ cmp resolve.expect resolve.output
+'
cat > show-branch2.expect << EOF
! [master] Merged "mybranch" changes.
@@ -147,17 +166,16 @@ cat > show-branch2.expect << EOF
-- [master] Merged "mybranch" changes.
EOF
-git show-branch --topo-order master mybranch > show-branch2.output
-test_expect_success 'git show-branch' 'cmp show-branch2.expect show-branch2.output'
-
-# TODO: test git fetch
-
-# TODO: test git push
+test_expect_success 'git show-branch (part 2)' '
+ git show-branch --topo-order master mybranch > show-branch2.output &&
+ cmp show-branch2.expect show-branch2.output
+'
test_expect_success 'git repack' 'git repack'
test_expect_success 'git prune-packed' 'git prune-packed'
test_expect_success '-> only packed objects' '
- ! find -type f .git/objects/[0-9a-f][0-9a-f]
+ git prune && # Remove conflict marked blobs
+ ! find .git/objects/[0-9a-f][0-9a-f] -type f
'
test_done
--
1.6.5.2.143.g8cc62
^ permalink raw reply related
* What's cooking in git.git (Nov 2009, #01; Wed, 04)
From: Junio C Hamano @ 2009-11-05 5:41 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
In 1.7.0, we plan to correct handful of warts in the interfaces everybody
agrees that they were mistakes. The resulting system may not be strictly
backward compatible. Currently planeed changes are:
* refuse push to update the checked out branch in a non-bare repo by
default
Make "git push" into a repository to update the branch that is checked
out fail by default. You can countermand this default by setting a
configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
* refuse push to delete the current branch by default
Make "git push $there :$killed" to delete the branch that is pointed at
by its HEAD fail by default. You can countermand this default by
setting a configuration variable in the receiving repository.
http://thread.gmane.org/gmane.comp.version-control.git/108862/focus=108936
* git-send-email won't make deep threads by default
Many people said that by default when sending more than 2 patches the
threading git-send-email makes by default is hard to read, and they
prefer the default be one cover letter and each patch as a direct
follow-up to the cover letter. You can countermand this by setting a
configuration variable.
http://article.gmane.org/gmane.comp.version-control.git/109790
* git-status won't be "git-commit --dry-run" anymore
http://thread.gmane.org/gmane.comp.version-control.git/125989/focus=125993
* "git-diff -w --exit-code" will exit success if only differences it
found are whitespace changes that are stripped away from the output.
http://thread.gmane.org/gmane.comp.version-control.git/119731/focus=119751
--------------------------------------------------
[New Topics]
* bw/autoconf-more (2009-11-04) 2 commits
- configure: add settings for gitconfig, editor and pager
- configure: add macro to set arbitrary make variables
* em/commit-claim (2009-11-04) 1 commit
- commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author
I just picked better bits from both versions.
* jk/maint-format-patch-p-suppress-stat (2009-11-04) 2 commits.
- format-patch: make "-p" suppress diffstat
- Revert "format-patch -p is now a no-op" series
(this branch uses bg/format-patch-p-noop.)
This corrects a mistake made soon after 1.6.0.
* rj/maint-simplify-cygwin-makefile (2009-10-27) 1 commit.
- Makefile: merge two Cygwin configuration sections into one
This is one of the most obviously correct bit from "Compiling on Cygwin
using MSVC fails" topic I didn't really look at. If J6t is Ok with the
series, I don't mind queueing the whole thing myself.
* vl/maint-openssl-signature-change (2009-10-31) 1 commit.
(merged to 'next' on 2009-10-31 at 0e1ce6b)
+ imap-send.c: fix compiler warnings for OpenSSL 1.0
Prepare ourselves before newer versions of OpenSSL hits more platforms.
--------------------------------------------------
[Stalled]
* tr/filter-branch (2009-10-28) 2 commits.
- filter-branch: nearest-ancestor rewriting outside subdir filter
- filter-branch: stop special-casing $filter_subdir argument
J6t had some comments on this.
* ne/rev-cache (2009-10-19) 7 commits.
- support for commit grafts, slight change to general mechanism
- support for path name caching in rev-cache
- full integration of rev-cache into git, completed test suite
- administrative functions for rev-cache, start of integration into git
- support for non-commit object caching in rev-cache
- basic revision cache system, no integration or features
- man page and technical discussion for rev-cache
The author indicated that there is another round coming. Does not seem to
pass the tests when merged to 'pu'.
* jl/submodule-add-noname (2009-09-22) 1 commit.
- git submodule add: make the <path> parameter optional
Dscho started an interesting discussion regarding the larger workflow in
which the "submodule add" is used. I think the patch itself makes sense
but at the same time it probably makes sense to also take the <path> and
infer the <repository> as Dscho suggested, probably in "git submodule
add", not in "git add" proper, at least initially.
* sr/gfi-options (2009-09-06) 6 commits.
- fast-import: test the new option command
- fast-import: add option command
- fast-import: test the new feature command
- fast-import: add feature command
- fast-import: put marks reading in it's own function
- fast-import: put option parsing code in separate functions
Seems to be moving again soon.
* je/send-email-no-subject (2009-08-05) 1 commit.
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
The existing tests cover the positive case (i.e. as long as the user says
"yes" to the "do you really want to send this message that lacks subject",
the message is sent) of this feature, but the feature itself needs its own
test to verify the negative case (i.e. does it correctly stop if the user
says "no"?)
--------------------------------------------------
[Cooking]
* bg/merge-ff-only (2009-10-29) 1 commit
(merged to 'next' on 2009-10-31 at b6b49aa)
+ Teach 'git merge' and 'git pull' the option --ff-only
* jk/maint-1.6.3-ls-files-i (2009-10-30) 1 commit.
(merged to 'next' on 2009-10-31 at 3a31fcc)
+ ls-files: unbreak "ls-files -i"
* jn/editor-pager (2009-10-30) 8 commits
- Provide a build time default-pager setting
- Provide a build time default-editor setting
- am -i, git-svn: use "git var GIT_PAGER"
- add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
- Teach git var about GIT_PAGER
- Teach git var about GIT_EDITOR
- Do not use VISUAL editor on dumb terminals
- Handle more shell metacharacters in editor names
* js/maint-diff-color-words (2009-10-30) 3 commits.
- diff --color-words: bit of clean-up
- diff --color-words -U0: fix the location of hunk headers
- t4034-diff-words: add a test for word diff without context
Fixes a corner case of running --color-words with -U0.
* sc/difftool-p4merge (2009-10-28) 1 commit
(merged to 'next' on 2009-10-31 at 194b5c5)
+ mergetool--lib: add p4merge as a pre-configured mergetool option
* sc/protocol-doc (2009-10-29) 1 commit
- Update packfile transfer protocol documentation
There is the final draft posted, but I haven't picked it up yet.
* sr/vcs-helper (2009-11-04) 13 commits
- Add Python support library for remote helpers
- Basic build infrastructure for Python scripts
- Allow helpers to request the path to the .git directory
- Allow helpers to report in "list" command that the ref is unchanged
- Honour the refspec when updating refs after import
- Write local refs written by the "import" helper command only once
- Add support for "import" helper command
- Allow specifying the remote helper in the url
- Add a config option for remotes to specify a foreign vcs
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
- Allow programs to not depend on remotes having urls
- Fix memory leak in helper method for disconnect
Supposed to replace db/vcs-helper-rest. Still does not pass tests in
'pu'.
* tr/describe-advice (2009-10-28) 1 commit
(merged to 'next' on 2009-10-31 at 8084850)
+ describe: when failing, tell the user about options that work
* mr/gitweb-snapshot (2009-10-29) 3 commits.
- gitweb: Smarter snapshot names
- t/gitweb-lib.sh: Split gitweb output into headers and body
(merged to 'next' on 2009-10-11 at 22ba047)
+ gitweb: check given hash before trying to create snapshot
Replaced the tip with Jakub's updates.
* jp/dirty-describe (2009-10-21) 1 commit.
(merged to 'next' on 2009-10-30 at 19c7fc7)
+ Teach "git describe" --dirty option
* jp/fetch-cull-many-refs (2009-10-25) 2 commits
(merged to 'next' on 2009-11-01 at 1f09ce9)
+ fetch: Speed up fetch of large numbers of refs
+ remote: Make ref_remove_duplicates faster for large numbers of refs
* bg/format-patch-p-noop (2009-10-25) 3 commits.
(merged to 'next' on 2009-10-30 at e34a3db)
+ format-patch documentation: Fix formatting
+ format-patch documentation: Remove diff options that are not useful
+ format-patch: Make implementation and documentation agree
(this branch is used by jk/maint-format-patch-p-suppress-stat.)
Will revert from 'next' by merging Peff's fix.
* jk/gitignore-anchored (2009-10-26) 1 commit
(merged to 'next' on 2009-10-30 at 9391a93)
+ gitignore: root most patterns at the top-level directory
* jk/maint-add-p-empty (2009-10-27) 1 commit.
(merged to 'next' on 2009-10-30 at 2bd302f)
+ add-interactive: handle deletion of empty files
* jk/maint-push-config (2009-10-25) 1 commit.
(merged to 'next' on 2009-10-30 at 934e3c5)
+ push: always load default config
* lt/revision-bisect (2009-10-27) 1 commit.
(merged to 'next' on 2009-10-30 at 81ee52b)
+ Add '--bisect' revision machinery argument
* jc/pretty-lf (2009-10-04) 1 commit.
- Pretty-format: %[+-]x to tweak inter-item newlines
* rs/pretty-wrap (2009-10-17) 1 commit
(merged to 'next' on 2009-10-30 at 403bbfe)
+ Implement wrap format %w() as if it is a mode switch
(this branch uses js/log-rewrap.)
* js/log-rewrap (2009-10-18) 3 commits
(merged to 'next' on 2009-10-30 at 403bbfe)
+ Teach --wrap to only indent without wrapping
+ Add strbuf_add_wrapped_text() to utf8.[ch]
+ print_wrapped_text(): allow hard newlines
(this branch is used by rs/pretty-wrap.)
* sr/blame-incomplete (2009-10-19) 1 commit.
(merged to 'next' on 2009-10-22 at 133e0ce)
+ blame: make sure that the last line ends in an LF
I think this is _good enough_ as-is; although it would be better if we
added some hint to the output for Porcelain implementations, that can be
done as a follow-up fix.
* fc/doc-fast-forward (2009-10-24) 1 commit.
(merged to 'next' on 2009-11-01 at faaad90)
+ Use 'fast-forward' all over the place
* ks/precompute-completion (2009-10-26) 3 commits.
(merged to 'next' on 2009-10-28 at cd5177f)
+ completion: ignore custom merge strategies when pre-generating
(merged to 'next' on 2009-10-22 at f46a28a)
+ bug: precomputed completion includes scripts sources
(merged to 'next' on 2009-10-14 at adf722a)
+ Speedup bash completion loading
* sp/smart-http (2009-11-04) 30 commits
- http-backend: Test configuration options
- http-backend: Use http.getanyfile to disable dumb HTTP serving
- test smart http fetch and push
- http tests: use /dumb/ URL prefix
- set httpd port before sourcing lib-httpd
- t5540-http-push: remove redundant fetches
- Smart HTTP fetch: gzip requests
- Smart fetch over HTTP: client side
- Smart push over HTTP: client side
- Discover refs via smart HTTP server when available
- http-backend: more explict LocationMatch
- http-backend: add example for gitweb on same URL
- http-backend: use mod_alias instead of mod_rewrite
- http-backend: reword some documentation
- http-backend: add GIT_PROJECT_ROOT environment var
- Smart fetch and push over HTTP: server side
- Add stateless RPC options to upload-pack, receive-pack
- Git-aware CGI to provide dumb HTTP transport
- remote-helpers: return successfully if everything up-to-date
- Move WebDAV HTTP push under remote-curl
- remote-helpers: Support custom transport options
- remote-helpers: Fetch more than one ref in a batch
- fetch: Allow transport -v -v -v to set verbosity to 3
- remote-curl: Refactor walker initialization
- Add multi_ack_detailed capability to fetch-pack/upload-pack
- Move "get_ack()" back to fetch-pack
- fetch-pack: Use a strbuf to compose the want list
- pkt-line: Make packet_read_line easier to debug
- pkt-line: Add strbuf based functions
- http-push: fix check condition on http.c::finish_http_pack_request()
v5 plus 3 more fix-up patches from today.
* ef/msys-imap (2009-10-22) 9 commits.
(merged to 'next' on 2009-10-31 at 8630603)
+ Windows: use BLK_SHA1 again
+ MSVC: Enable OpenSSL, and translate -lcrypto
+ mingw: enable OpenSSL
+ mingw: wrap SSL_set_(w|r)fd to call _get_osfhandle
+ imap-send: build imap-send on Windows
+ imap-send: fix compilation-error on Windows
+ imap-send: use run-command API for tunneling
+ imap-send: use separate read and write fds
+ imap-send: remove useless uid code
* jc/fix-tree-walk (2009-10-22) 11 commits.
(merged to 'next' on 2009-10-22 at 10c0c8f)
+ Revert failed attempt since 353c5ee
+ read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
+ unpack_callback(): use unpack_failed() consistently
+ unpack-trees: typofix
+ diff-lib.c: fix misleading comments on oneway_diff()
This has some stupid bugs and temporarily reverted from 'next' until I can
fix it, but the "temporarily" turned out to be very loooong. Sigh...
* jh/notes (2009-10-09) 22 commits.
- fast-import: Proper notes tree manipulation using the notes API
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
(merged to 'next' on 2009-11-01 at 948327a)
+ Add selftests verifying concatenation of multiple notes for the same commit
+ Refactor notes code to concatenate multiple notes annotating the same object
+ Add selftests verifying that we can parse notes trees with various fanouts
+ Teach the notes lookup code to parse notes trees with various fanout schemes
+ Teach notes code to free its internal data structures on request
+ Add '%N'-format for pretty-printing commit notes
+ Add flags to get_commit_notes() to control the format of the note string
+ t3302-notes-index-expensive: Speed up create_repo()
+ fast-import: Add support for importing commit notes
+ Teach "-m <msg>" and "-F <file>" to "git notes edit"
+ Add an expensive test for git-notes
+ Speed up git notes lookup
+ Add a script to edit/inspect notes
+ Introduce commit notes
* jn/gitweb-blame (2009-09-01) 5 commits.
- gitweb: Minify gitweb.js if JSMIN is defined
- gitweb: Create links leading to 'blame_incremental' using JavaScript
(merged to 'next' on 2009-10-11 at 73c4a83)
+ gitweb: Colorize 'blame_incremental' view during processing
+ gitweb: Incremental blame (using JavaScript)
+ gitweb: Add optional "time to generate page" info in footer
Ajax-y blame.
* nd/sparse (2009-08-20) 19 commits.
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[For 1.7.0]
* jc/1.7.0-no-commit-no-ff-2 (2009-10-22) 1 commit.
- git-merge: forbid fast-forward and up-to-date when --no-commit is given
This makes "git merge --no-commit" fail when it results in fast-forward or
up-to-date. I haven't described this at the beginning of this message
yet, as it is not clear if this change is even necessary. Opinions?
* jk/1.7.0-status (2009-09-05) 5 commits.
- docs: note that status configuration affects only long format
(merged to 'next' on 2009-10-11 at 65c8513)
+ commit: support alternate status formats
+ status: add --porcelain output format
+ status: refactor format option parsing
+ status: refactor short-mode printing to its own function
(this branch uses jc/1.7.0-status.)
Gives the --short output format to post 1.7.0 "git commit --dry-run" that
is similar to that of post 1.7.0 "git status".
The tip one is not in 'next' as I have been hoping that somebody may want
to change the code to make it unnecessary, but it does not seem to be
happening, so probably it should also go to 'next'.
* jc/1.7.0-status (2009-09-05) 4 commits.
(merged to 'next' on 2009-10-11 at 9558627)
+ status: typo fix in usage
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch is used by jk/1.7.0-status.)
With this, "git status" is no longer "git commit --dry-run".
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit.
(merged to 'next' on 2009-10-11 at 043acdf)
+ send-email: make --no-chain-reply-to the default
* jc/1.7.0-diff-whitespace-only-status (2009-08-30) 4 commits.
(merged to 'next' on 2009-10-11 at 546c74d)
+ diff.c: fix typoes in comments
+ Make test case number unique
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
This changes exit code from "git diff --ignore-whitespace" and friends
when there is no actual output. It is a backward incompatible change, but
we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits.
(merged to 'next' on 2009-10-11 at 81b8128)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
--------------------------------------------------
[I have been too busy to purge these]
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
Maybe some people care about this. I dunno.
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
Maybe some people care about this. I dunno.
* jg/log-format-body-indent (2009-09-19) 1 commit.
. git-log --format: Add %B tag with %B(x) option
^ permalink raw reply
* Re: [PATCH v2] commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author
From: Junio C Hamano @ 2009-11-05 5:40 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Erick Mattos, git
In-Reply-To: <20091105123456.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> It may be wise to forbid a combination of options if it
> encourages mistakes or a wrong workflow, but I don't think
> using --author and --reset-author with 'git commit --amend'
> is such a case.
>
> Imagine somebody other than you (eg. me) were the maintainer,
> and a message by Szeder was sent with a good commit log message.
>
> http://article.gmane.org/gmane.comp.version-control.git/132029
>
> Then you sent a replacement patch that solves the same problem
> in a more elegant way, but without anything that is usable as the
> commit log message.
>
> http://article.gmane.org/gmane.comp.version-control.git/132041
>
> If I were the maintainer, I would find it very convenient if I can
> work like this:
>
> % git am -s 132029 --- first I apply Szeder's version
>
> Then I see your message. Replace the code change but use Szeder's
> log message.
>
> % git reset --hard HEAD^
> % git am 132041 --- your version with no usable log message
> % git commit --amend -s -c @{2} --author='Junio C Hamano <...>'
Thanks.
So you commit Szeder's and then commit mine (make them independent), and
amend the log message of the latter using the message from the former, and
assign the authorship of the latter to the resulting commit?
That is a much more understandable argument than just claiming "--author
should be usable with --reset-author" without clearly stating why that
would help. I think you forgot to add --reset-author to the last command
line, though.
But I think it is showing that --reset-author is actually suboptimal way
to solve your scenario. In the last command in your sequence, you don't
want to add "--reset-author --author=X" but want "--reuse-only-message"
option.
And I think it makes much more sense than the alternative semantics we
came up with during this discussion. --mine (or --reset-author) to
declare that "I am the author" was not what we wanted after all(yes, I am
guilty for suggesting it). What we want is "I am using -C/-c/--amend and
I want to borrow only the message part from the named commit (obviously
"amend" names the HEAD commit implicitly). Determine the authorship
information (including author timestamp) as if I didn't use that option."
^ permalink raw reply
* Re: [PATCH v2 09/13] Honour the refspec when updating refs after import
From: Daniel Barkalow @ 2009-11-05 5:34 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0911041745x577f7e4rc678da4d7d559193@mail.gmail.com>
On Thu, 5 Nov 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Wed, Nov 4, 2009 at 22:30, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > On Wed, 4 Nov 2009, Sverre Rabbelier wrote:
> >> On Wed, Nov 4, 2009 at 22:20, Daniel Barkalow <barkalow@iabervon.org> wrote:
> >> > That's not true for "git pull <url> <branch>"; we do want the remote ref,
> >> > but it doesn't have a local peer.
>
> No, I don't think that's right, when doing a fetch we want to store
> the refs somewhere, sure, but not under 'refs/heads/<branch>', perhaps
> 'refs/hg/fetch/<branch>', either way, the current code does not work.
I think you've still got things backwards. From the point of view of
transport.c, refs/<vcs> is entirely opaque, and we never look at it. Those
aren't local peers. They're a way for the helper to communicate to
transport-helper.c. The user says: pull refs/heads/master of this hg
repo. Transport.c tries to fetch refs/heads/master and get the sha1 to
write into FETCH_HEAD or wherever. Transport-helper.c says "import
refs/heads/master", and git-fast-import reads the resulting script and
writes some ref that the helper tells it to write. Then transport-helper.c
figures out where the ref was written, reads it, and updates the struct
ref representing the remote info. Then builtin-fetch looks at the struct
ref and writes it to the local repositories ref namespace or FETCH_HEAD.
> >> >I think going straight to the refspec
> >> > command is the right answer.
> >>
> >> Can you clarity what you mean with "the refspec command"?
> >
> > Whatever it is that lets the helper tell the transport code where in the
> > helper's private namespace to look for refs. I'd been thinking the helper
> > would advertize the "refspec" capability, and the transport code would
> > call the "refspec" command in order to get the helper to report that; but
> > then I actually only said that the helper reports refspec, and not
> > proposed a name for the command.
>
> Currently I'm implementing so that it would work like this for the svn helper:
>
> $ echo capabilities | git remote-svn origin /path/to/hg/repo
> import
> refspec +refs/trunk:refs/svn/origin/trunk
> refspec +refs/branches/*:refs/svn/origin/*
>
> That way we can put the refspec in the config file at clone time.
>
> Now I've been browsing through the builtin-fetch code, and it looks
> like the main problem is going to be to apply this refspec at all.
> I'll have a more extensive look tomorrow.
This is entirely not what I think we should have. The config file should
say refs/heads/*:refs/remotes/origin/* like it always does, because the
transport will list the refs like refs/heads/* and refs/tags/* and return
them like that.
I'll see if I can write up an untested patch that does what I'm thinking
of.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] Update packfile transfer protocol documentation
From: Junio C Hamano @ 2009-11-05 5:24 UTC (permalink / raw)
To: Scott Chacon; +Cc: git list, Junio C Hamano, Shawn O. Pearce
In-Reply-To: <d411cc4a0911032158j2a4664e5w2601c4af59ba0837@mail.gmail.com>
Scott Chacon <schacon@gmail.com> writes:
> The technical documentation for the packfile protocol is both sparse and
> incorrect. This documents the fetch-pack/upload-pack and send-pack/
> receive-pack protocols much more fully.
Thanks.
In this round, my comments ended up being mostly "nit-picky", although I
spotted a few logic errors.
> +Git Transport
> +-------------
> +
> +The Git protocol starts off by sending the command and repository
"transport"
> +on the wire using the pkt-line format, followed by a null byte and a
> +hostname paramater, terminated by a null byte.
The name of the byte whose value is 0 is "NUL", not "NULL" (as you
correctly did in the "Reference Discovery" section).
> +Basically what the Git client is doing to connect to an 'upload-pack'
> ...
> +SSH Transport
> ...
> +It is basically equivalent to running this:
> +Reference Discovery
> +-------------------
> +
> +When the client initially connects the server will immediately respond
> +with a listing of each reference it has (all branches and tags) along
> +with the object name that each reference currently points to.
> +
> + $ echo -e -n "0039git-upload-pack
> /schacon/gitbook.git\0host=example.com\0" |
Oops...
> + nc -v example.com 9418
> + 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack
> thin-pack side-band side-band-64k ofs-delta shallow no-progress
> include-tag
Oops...
It is perfectly fine to fold a long line in the document. What I
earlier suggested was to state the fact that the document _did_ fold
a long line for typographical reasons and in the actual protocol it
is a single long line to the reader.
> +The returned response is a pkt-line stream describing each ref and
> +its known value. The stream MUST be sorted by name according to
> +the C locale ordering.
Do we need to say "known"?
> ...
> + advertised-refs = (no-refs / list-of-refs)
> + flush-pkt
> +
> + no-refs = PKT-LINE(zero-id SP "capabilities^{}"
> + NUL capability-list LF)
> +
> + list-of-refs = first-ref *other-ref
> + first-ref = PKT-LINE(obj-id SP refname
> + NUL capability-list LF)
> +
> + other-ref = PKT-LINE(other-tip / other-peeled)
> + other-tip = obj-id SP refname LF
> + other-peeled = obj-id SP refname "^{}" LF
> +
> + capability-list = capability *(SP capability)
> + capability = 1*(LC_ALPHA / DIGIT / "-" / "_")
> + LC_ALPHA = %x61-7A
> +----
> +
> +Server and client SHOULD use lowercase for SHA1, both MUST treat SHA1
> +as case-insensitive.
I hate to sound like a broken parrot, but ...
- You do not have SHA1 in the above list; say "obj-id".
- Why is this SHOULD and not MUST? It's not like you or somebody else
have already written such a broken server or client and you have to
grandfather it by defining what goes over the wire looser than the
current practice. I think this is taking the "be liberal in what you
accept" mantra too literally without real reason for doing so.
> +Packfile Negotiation
> +--------------------
> +After reference and capabilities discovery, the client can decide
> +to terminate the connection by sending a flush-pkt, telling the
> +server it can now gracefully terminate (as happens with the ls-remote
> +command) or it can enter the negotiation phase, where the client and
> +server determine what the minimal packfile necessary for transport is.
> +
> +Once the client has the initial list of references that the server
> +has, as well as the list of capabilities, it will begin telling the
> +server what objects it wants and what objects it has, so the server
> +can make a packfile that only has the objects that the client needs.
"only has" -> "only contains", perhaps, as the above has too many has
already?
> +The client will also send a list of the capabilities it supports out
> +of what the server said it could do with the first 'want' line.
It is not _wrong_ per-se, but it is not about client "supporting". It is
asking these particular protocol extensions enabled. How about...
.. will also send a list of the capabilities it wants to be in
effect, out of ...
> +If the server reads 'have' lines, it then will respond by ACKing any
> +of the obj-ids the client said it had that the server also has. The
> +server will ACK obj-ids differently depending on which ack mode is
> +signaled by the client.
Perhaps "signaled" -> "chosen"?
> +In multi_ack mode:
> ...
> +In multi_ack_detailed mode:
> ...
> +Without multi_ack:
> ...
The last one is "without multi_ack or multi_ack_detailed", isn't it?
I think the order you described these three is sensible (from the most
commonly deployed to merely describing a historical practice).
> +Packfile Data
> +-------------
> +
> +Now that the client and server have done some negotiation about what
> +the minimal amount of data that can be sent to the client is, the server
> +will construct and send the required data in packfile format.
Perhaps "done some" -> "finished"?
Is it "can be sent" or "needs to be sent"?
> +Pushing Data To a Server
> ...
> +references to be complete. Once all the data is received and validated,
> +the server will then update it's references to what the client specified.
"it's" -> "its".
> +Reference Discovery
> +-------------------
> +
> +The reference discovery phase is done nearly the same way as it is in the
> +fetching protocol. Each reference obj-id and name on the server is sent
> +in packet-line format to the client, followed by a flush packet. The only
I slightly prefer "a flush packet" spelled out like this, but please be
consistent either way. You have only two instances of spelled-out "flush
packet" around this section, and everywhere else in this patch you used
"flush-pkt" (I am talking about explanation prose, not ABNF, in which you
consistently used "flush-pkt" everywhere), so changing these "flush
packet" to "flush-pkt" may be easier to change and less error prone.
> +A pack-file MUST be sent if either create or update command is used,
> +even if the server already has all the necessary objects. In this
> +case the client MUST send an empty pack-file. The only time this
> +is likely to happen is if the client is doing something like creating
> +a new branch that points to an existing obj-id.
"doing something like" is redundant.
> +The server will receive the packfile, unpack it, then validate each
> +reference that is being updated that it hasn't changed while the request
> +was being processed (the obj-id is still the same as the old-id), and
> +it will run any update hooks to make sure that the update is acceptable.
> +If all of that is fine, the server will then update the references.
Strictly speaking, "unpack it" is a wrong thing to say in a protocol
specification document. The only requirement is for the server to make
objects in it accessible before the ref update takes place. The objects
need to be accessible when hooks run.
I was about to suggest "store objects in it in the repository" instead,
but in the status report we do use a successful "unpack" to mean "made
objects accessible successfully", so it probably is Ok as-is. At least I
cannot think of a better way to rephrase this part.
> +Report Status
> +-------------
> +
> +After receiving the pack data from the sender, the client sends a
"the client sends" -> "the server sends".
Even though it makes me a bit uneasy to describe these entities "server vs
client" (I'd prefer "sender" vs "receiver"), the entire document is
written based on the assumption that "clients" fetch from or push to "the
server", so let's be consistent.
> +report if 'report-status' capability was sent to the server.
> +It is a short listing of what happened in that update. It will first
> +list the status of the packfile unpacking as either 'unpack ok' or
> +'unpack [error]'. Then it will list the status for each of the references
> +that it tried to update. Each line be either 'ok [refname]' if the
Sorry for asking a language question but "be"?
> +An example client/server communication might look like this:
> +
> +----
> + S: 007c74730d410fcb6603ace96f1dc55ea6196122532d
> refs/heads/local\0report-status delete-refs ofs-delta\n
> + S: 003e7d1665144a3a975c05f1f43902ddaf084e784dbe refs/heads/debug\n
> + S: 003f74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/master\n
> + S: 003f74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/team\n
> + S: 0000
> +
> + C: 003e7d1665144a3a975c05f1f43902ddaf084e784dbe
> 74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/debug\n
> + C: 003e74730d410fcb6603ace96f1dc55ea6196122532d
> 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a refs/heads/master\n
Oops.
> diff --git a/Documentation/technical/protocol-capabilities.txt
> b/Documentation/technical/protocol-capabilities.txt
> new file mode 100644
> index 0000000..f4bf986
> --- /dev/null
> +++ b/Documentation/technical/protocol-capabilities.txt
> @@ -0,0 +1,186 @@
> +Git Protocol Capabilities
> +=========================
> +
> +Servers SHOULD support all capabilities defined in this document.
> +
> +On the very first line of the initial server response of either
> +receive-pack and upload-pack the first reference is followed by
> +a null byte and then a list of space delimited server capabilities.
"null" -> "NUL"
> +Client will then send a space separated list of capabilities it
> +can support. The client SHOULD NOT ask for capabilities the server
> +did not say it supports.
> +
> +Server MUST ignore capabilities it does not understand. Server MUST
> +NOT ignore capabilities that client requested and server advertised.
> +
I hate to sound like a broken parrot, but ...
- It is more like "Client will ... it wants enabled", not "it can
support".
- Is this really "SHOULD NOT", as opposed to "MUST NOT"? What are
examples of plausible justifications for client implementations to
violate this requirement and ask for a capability that it knows the
server does not support?
- Shouldn't server "MUST diagnose and abort" connection when client
requests a protocol feature (i.e. capability) that it does not
understand?
When the server advertises a capability it itself does not understand
and the client asked for it, then the client can legitimately ask for
it, and the server is not allowed to ignore it, but it must ignore it, so
it cannot satisfy this requirement. We should spell out that the server
MUST NOT advertise capabilities it does not understand.
> +thin-pack
> +---------
> +
> +This capability implies that the server can send 'thin' packs, packs
Does it imply or explicitly state? I think it is the latter.
> +which do not contain base objects; if those base objects are available
> +on client side. Client requests 'thin-pack' capability when it
> +understands how to "thicken" them adding required delta bases making
> +them self contained.
A single pack is sent over the wire and thicking it will create a single
pack self contained, hence "making it self contained".
> +Client MUST NOT request 'thin-pack' capability if it cannot turn thin
> +packs into proper independent packs.
"a think pack into a self contained pack"
> +side-band, side-band-64k
> +------------------------
> +
> +This means that server can send, and client understand multiplexed
> +progress reports and error info interleaved with the packfile itself.
Either "This" -> "This capability", or just begin the sentence with
"Server can send..." like your description of "ofs-delta".
> +delete-refs
> +-----------
> +
> +If the server sends back the 'delete-refs' capability, it means that
> +it is capable of accepting an all-zeroed SHA-1 value as the target
> +value of a reference update. It is not sent back by the client, it
> +simply informs the client that it can be sent zeroed SHA-1 values
> +to delete references.
You earlier called these "all-zeroed SHA-1 value"s "zero-id"s. Be
consistent.
> diff --git a/Documentation/technical/protocol-common.txt
> b/Documentation/technical/protocol-common.txt
> new file mode 100644
> index 0000000..2dca642
> --- /dev/null
> +++ b/Documentation/technical/protocol-common.txt
> @@ -0,0 +1,96 @@
> ...
> +A refname is a hierarichal octet string beginning with "refs/" and
"hierarchical"
^ permalink raw reply
* Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option
From: Christian Couder @ 2009-11-05 5:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vtyxaez4f.fsf@alter.siamese.dyndns.org>
On Wednesday 04 November 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > So to do that you would use "git bisect start ..." and then you could
> > use:
> >
> > $ git rev-list --bisect HEAD --not $GOOD_COMMITS
> >
> > to get the commit that you would have to test if the current commit is
> > bad and:
> >
> > $ git rev-list --bisect $BAD --not $GOOD_COMMITS HEAD
> >
> > to get the commit that you would have to test if the current commit is
> > good.
>
> Even in that case, the problem is still about narrowing the set of the
> current bisection graph. If --bisect option implicitly grabs good and
> bad defined in the refspace like Linus's patch does, it will give you the
> same behaviour of the above two commands, no?
I think it will probably work when you add a good rev, but in the case where
you give a different bad (the first command above) it does not work the
same.
The test case in patch 1/3 shows that. It does:
git bisect start $HASH7 $HASH1 &&
...
rev_list2=$(git rev-list --bisect $HASH3 --not $HASH1) &&
test "$rev_list2" = "$HASH2"
and that last command fails.
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH v2] commit -c/-C/--amend: reset timestamp and authorship to committer with --reset-author
From: Nanako Shiraishi @ 2009-11-05 3:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Erick Mattos, git
In-Reply-To: <7vpr7ykbh8.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> I had an impression that we have already established that setting the
> author with --author="Somebody Else <s@b.e>" and committing with the
> current time does not make much sense from the workflow point of view long
> time ago in this thread.
> <snip>
> But allowing this combination, even though it might not make much sense,
> is just giving extra length to the rope, so it may not be such a big deal.
It may be wise to forbid a combination of options if it
encourages mistakes or a wrong workflow, but I don't think
using --author and --reset-author with 'git commit --amend'
is such a case.
Imagine somebody other than you (eg. me) were the maintainer,
and a message by Szeder was sent with a good commit log message.
http://article.gmane.org/gmane.comp.version-control.git/132029
Then you sent a replacement patch that solves the same problem
in a more elegant way, but without anything that is usable as the
commit log message.
http://article.gmane.org/gmane.comp.version-control.git/132041
If I were the maintainer, I would find it very convenient if I can
work like this:
% git am -s 132029 --- first I apply Szeder's version
Then I see your message. Replace the code change but use Szeder's
log message.
% git reset --hard HEAD^
% git am 132041 --- your version with no usable log message
% git commit --amend -s -c @{2} --author='Junio C Hamano <...>'
> Sorry, but I cannot help feeling a bit frustrated and mildly irritated.
Don't try to be perfect and feel stressed out, and please take
a good rest.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Automatically remote prune
From: Sitaram Chamarty @ 2009-11-05 3:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Tapsell, Git List
In-Reply-To: <7viqdpemki.fsf@alter.siamese.dyndns.org>
On Thu, Nov 5, 2009 at 7:53 AM, Junio C Hamano <gitster@pobox.com> wrote:
> (1) The user wants to keep the remotes/<origin>/* namespace clean (iow,
[snip]
> (2) The user does want to be careful not to lose commits that now only
This whole discussion is a conflict between those two. The current
system does the latter, safer, thing. John's users are getting
confused because they *think* this means the remote still has those
refs.
At best an alias that does a prune before (or after) a fetch should do.
And I notice 'git gui' has an option to "prune during fetch" -- maybe
that should be an option that is also made available to the CLI fetch.
^ permalink raw reply
* Re: [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Nicolas Pitre @ 2009-11-05 2:47 UTC (permalink / raw)
To: Andrzej K. Haczewski; +Cc: kusmabite, git, Johannes Sixt
In-Reply-To: <4AF20534.2030004@gmail.com>
On Wed, 4 Nov 2009, Andrzej K. Haczewski wrote:
> Erik Faye-Lund pisze:
> > Couldn't the windows version of pthread_create have a wrapper
> > function, that corrected the calling convention, much like the
> > function run_thread that start_async in run-command.c has?
>
> Can't be done without allocations. I'd have to pass to that wrapping
> thread function an address of original function *and* an original
> argument, and there's no way to pack that as one void*.
What about:
typedef struct {
HANDLE handle;
void *(*start_routine)(void *);
void *arg;
} pthread_t;
DWORD __stdcall windows_thread_start(LPVOID _self)
{
pthread_t *self = _self;
void *ret = self->start_routine(self->arg);
return (DWORD)ret;
}
static inline int pthread_create(pthread_t *thread, const void *unused,
void *(*start_routine)(void *), void *arg)
{
thread->handle = CreateThread(NULL, 0, windows_thread_start,
thread, 0, NULL);
[...]
}
?
Sure this will use 8 to 16 more bytes per thread, but we're dealing with
a rather small number of threads anyway (more threads than the number of
CPU cores is useless) making this extra memory usage rather
insignificant compared to the many megabytes of RAM the rest of the code
is using. The advantage is full compatibility with the native pthread
interface git is using at the source level while still being much
lighter than a full blown pthread implementation.
And thread creation is a relatively rare event compared to e.g. mutex
lock/unlock, so the indirection shouldn't be noticeable. For the same
reason, I also think that you could make pthread_create() and
pthread_join() into a C file instead of being inlined which would reduce
the code footprint at every call site, and allow for only one instance
of windows_thread_start() which could then be made static.
Nicolas
^ permalink raw reply
* Re: Automatically remote prune
From: Junio C Hamano @ 2009-11-05 2:23 UTC (permalink / raw)
To: John Tapsell; +Cc: Git List
In-Reply-To: <43d8ce650911041741w4b39d137ha2a1529a15256d27@mail.gmail.com>
John Tapsell <johnflux@gmail.com> writes:
> 2009/11/5 Junio C Hamano <gitster@pobox.com>:
>> John Tapsell <johnflux@gmail.com> writes:
>
>> You could store necessary information somewhere else when you contacted
>> the remote the last time, but we need to consider what the benefits are to
>> give this information in the first place.
>
> We already get all this information on a "git fetch", no?
"what the benefits are to give this information _in the 'branch' output_"
was what I meant. From the part you omitted from my message:
The [Deleted] mark in your suggestion tells the user:
This is already removed in the remote, and this tracking copy is the
only way for you to view it ever again. Do not run 'remote prune
origin' blindly otherwise you will lose it.
There are two reasons I could think of that the user might want to know
this.
(1) The user wants to keep the remotes/<origin>/* namespace clean (iow,
the user does not care to keep old commits that were deemed bad by
the remote side) by removing stale tracking refs. But in this case,
it is very unlikely that the user would use "git branch -d -r" to
remove stale ones one-by-one after seeing '[Deleted]' label in the
output from "git branch -r". Rather he would run "git remote prune
origin" to blindly remove them all.
(2) The user does want to be careful not to lose commits that now only
exists in his repository. Perhaps he saw something worthwhile to
base his topic later on. But these stale remote tracking refs are
not removed until the user runs "git remote prune origin". As long
as we give him a way to check what will be pruned before running "git
remote prune", there is not much point in showing that information in
output of "git branch -r". There is no need to keep extra info by
creating a new file in .git by "fetch". Nor showing that to the user
when he does "fetch" either, for that matter.
A better approach to please the first class of audience may be to
introduce an option that tells fetch to cull tracking refs that are stale.
Then "branch -r" output will not show stale refs and there is no place
(nor need) to show [Deleted] labels.
Such an option won't be very useful for the second class of audience,
though. For them we would need something else, and it would likely be an
enhancement to "git remote". It would ask the other side what refs are no
longer there, and then check our local refspace to see if there are local
topics based on them (which would mean the user is already in a trouble)
and which ones are not forked locally at all (which may mean "it wasn't
interesting to the user, and we can safely remove it" or "the user was
interested in it, but hasn't got around to forking from it yet, being busy
working on something else"). I am unsure what should be done in the
latter case (i.e. lost remote refs haven't been touched locally) but am
just thinking aloud.
^ permalink raw reply
* Re: [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Nicolas Pitre @ 2009-11-05 2:10 UTC (permalink / raw)
To: Andrzej K. Haczewski; +Cc: git, Johannes Sixt
In-Reply-To: <4AF214D5.6050202@gmail.com>
On Thu, 5 Nov 2009, Andrzej K. Haczewski wrote:
> +static inline int pthread_cond_init(pthread_cond_t *cond, const void *unused)
> +{
> + cond->waiters = 0;
> +
> + InitializeCriticalSection(&cond->waiters_lock);
> +
> + cond->sema = CreateSemaphore(NULL, 0, LONG_MAX, NULL);
> + if (!cond->sema)
> + return 0; /* POSIX do not allow pthread_cond_init to fail */
> + return 0;
> +}
Please use die("CreateSemaphore() failed") in the failure case instead
of returning success.
However, my pthread_cond_init man page says:
[[[
RETURN VALUE
If successful, the pthread_cond_destroy() and pthread_cond_init() func-
tions shall return zero; otherwise, an error number shall be returned
to indicate the error.
The [EBUSY] and [EINVAL] error checks, if implemented, shall act as if
they were performed immediately at the beginning of processing for the
function and caused an error return prior to modifying the state of the
condition variable specified by cond.
ERRORS
The pthread_cond_destroy() function may fail if:
EBUSY The implementation has detected an attempt to destroy the object
referenced by cond while it is referenced (for example, while
being used in a pthread_cond_wait() or pthread_cond_timedwait())
by another thread.
EINVAL The value specified by cond is invalid.
The pthread_cond_init() function shall fail if:
EAGAIN The system lacked the necessary resources (other than memory) to
initialize another condition variable.
ENOMEM Insufficient memory exists to initialize the condition variable.
The pthread_cond_init() function may fail if:
EBUSY The implementation has detected an attempt to reinitialize the
object referenced by cond, a previously initialized, but not yet
destroyed, condition variable.
EINVAL The value specified by attr is invalid.
]]]
I'm not advocating that you implement detailed error codes as we don't
really care about specific errors. This is just to disagree with the
"POSIX do not allow pthread_cond_init to fail" assertion. In any case,
using die() to keep it simple is certainly better than blindly returning
0 on failure. However you could simply return ENOMEM and use the die()
in init_threaded_search() instead.
Nicolas
^ permalink raw reply
* Re: Automatically remote prune
From: Shawn O. Pearce @ 2009-11-05 2:00 UTC (permalink / raw)
To: John Tapsell; +Cc: Junio C Hamano, Git List
In-Reply-To: <43d8ce650911041741w4b39d137ha2a1529a15256d27@mail.gmail.com>
John Tapsell <johnflux@gmail.com> wrote:
> 2009/11/5 Junio C Hamano <gitster@pobox.com>:
> > John Tapsell <johnflux@gmail.com> writes:
>
> > You could store necessary information somewhere else when you contacted
> > the remote the last time, but we need to consider what the benefits are to
> > give this information in the first place.
>
> We already get all this information on a "git fetch", no? And then
> promptly discard it. Surely when we do "git fetch" . So I'm talking
> about just not ignoring the information we get from git fetch, but
> present that information to the user.
Good point. We currently don't have a provision to store this
information, but we could store a list of dead remote tracking
branches for reference later during `git branch -r`.
Its not a lot of data, it just has little perceived value to most
Git hackers because a remote branch disappears very infrequently
(if ever) for most of us.
--
Shawn.
^ permalink raw reply
* Re: [PATCH v2 09/13] Honour the refspec when updating refs after import
From: Sverre Rabbelier @ 2009-11-05 1:45 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <alpine.LNX.2.00.0911041624401.14365@iabervon.org>
Heya,
On Wed, Nov 4, 2009 at 22:30, Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Wed, 4 Nov 2009, Sverre Rabbelier wrote:
>> On Wed, Nov 4, 2009 at 22:20, Daniel Barkalow <barkalow@iabervon.org> wrote:
>> > That's not true for "git pull <url> <branch>"; we do want the remote ref,
>> > but it doesn't have a local peer.
No, I don't think that's right, when doing a fetch we want to store
the refs somewhere, sure, but not under 'refs/heads/<branch>', perhaps
'refs/hg/fetch/<branch>', either way, the current code does not work.
>> >I think going straight to the refspec
>> > command is the right answer.
>>
>> Can you clarity what you mean with "the refspec command"?
>
> Whatever it is that lets the helper tell the transport code where in the
> helper's private namespace to look for refs. I'd been thinking the helper
> would advertize the "refspec" capability, and the transport code would
> call the "refspec" command in order to get the helper to report that; but
> then I actually only said that the helper reports refspec, and not
> proposed a name for the command.
Currently I'm implementing so that it would work like this for the svn helper:
$ echo capabilities | git remote-svn origin /path/to/hg/repo
import
refspec +refs/trunk:refs/svn/origin/trunk
refspec +refs/branches/*:refs/svn/origin/*
That way we can put the refspec in the config file at clone time.
Now I've been browsing through the builtin-fetch code, and it looks
like the main problem is going to be to apply this refspec at all.
I'll have a more extensive look tomorrow.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Automatically remote prune
From: John Tapsell @ 2009-11-05 1:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7v639qi2un.fsf@alter.siamese.dyndns.org>
2009/11/5 Junio C Hamano <gitster@pobox.com>:
> John Tapsell <johnflux@gmail.com> writes:
> You could store necessary information somewhere else when you contacted
> the remote the last time, but we need to consider what the benefits are to
> give this information in the first place.
We already get all this information on a "git fetch", no? And then
promptly discard it. Surely when we do "git fetch" . So I'm talking
about just not ignoring the information we get from git fetch, but
present that information to the user.
John
^ permalink raw reply
* Re: thoughts on setting core.logAllRefUpdates default true for bare repos
From: Sitaram Chamarty @ 2009-11-05 1:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, Johannes Schindelin, git
In-Reply-To: <7v3a4ugjea.fsf@alter.siamese.dyndns.org>
On Thu, Nov 5, 2009 at 1:19 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The single most common reason why a bare repository is bare is because
> nobody regularly logs in to the machine that hosts it and goes there to
> access its contents. As reflog is a local thing, and not exposed to
> outside world, enabling it alone would not help a lot to people who do not
> have such a direct access to the bare repository, which by definition is
> the majority because the reason why the repository is bare to begin with.
>
> Once we add ways to expose information kept in reflog of a bare repository
> more effectively and conveniently, the argument could become "should be
> enabled now it would be very useful to have one".
It doesn't have to be exposed nor we have to wait till such features
(like you mentioned gitweb, remote log, etc) are implemented.
We're talking "disaster recovery", not "daily use" -- after all,
*someone* has access to the machine, and can become "local" to it.
Regards,
Sitaram
^ permalink raw reply
* Re: thoughts on setting core.logAllRefUpdates default true for bare repos
From: Sitaram Chamarty @ 2009-11-05 1:24 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Johannes Schindelin, git
In-Reply-To: <20091104235241.GA12984@vidovic>
On Thu, Nov 5, 2009 at 5:22 AM, Nicolas Sebrecht <nicolas.s.dev@gmx.fr> wrote:
> The 04/11/09, Sitaram Chamarty wrote:
>
>> But if you are able to do "gc" manually on any repo you can also do
>> "reflog expire" before "gc" can you not? Please correct me if I'm
>> wrong.
>
> "If we are able to do 'gc' on any repo"... But a lot of users aren't
> able to it because they aren't the admin.
>
> Or did you mean if "non-admin users could" ?
dscho's original mail said: > With gitweb on a public site, there
might be a problem when you pushed
> some blob containing trade secrets accidentally, and try to scrub the
> repository using "git gc" after a forced push.
That's a manual gc. If you can do a manual gc, you can do a reflog
expire before the gc, is what I meant.
>
> --
> Nicolas Sebrecht
>
^ permalink raw reply
* [PATCH v5.1 1/3] http-backend: Remove pointless objects/info/* service entry
From: Shawn O. Pearce @ 2009-11-05 1:16 UTC (permalink / raw)
To: git
In earlier versions of this patch series this rule was used to
match and serve objects/info/alternates and http-alternates.
Later versions of the patch series explicitly called out match
rules for those files, making this wildcard rule unnecessary.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This probably should be squashed into the commit that introduces
this CGI script ("Git-aware CGI to provide dumb HTTP transport").
http-backend.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/http-backend.c b/http-backend.c
index 8e5c0a2..7900cda 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -558,7 +558,6 @@ static struct service_cmd {
{"GET", "/objects/info/alternates$", get_text_file},
{"GET", "/objects/info/http-alternates$", get_text_file},
{"GET", "/objects/info/packs$", get_info_packs},
- {"GET", "/objects/info/[^/]*$", get_text_file},
{"GET", "/objects/[0-9a-f]{2}/[0-9a-f]{38}$", get_loose_object},
{"GET", "/objects/pack/pack-[0-9a-f]{40}\\.pack$", get_pack_file},
{"GET", "/objects/pack/pack-[0-9a-f]{40}\\.idx$", get_idx_file},
--
1.6.5.2.295.g0d105
^ permalink raw reply related
* [PATCH v5.1 3/3] http-backend: Test configuration options
From: Shawn O. Pearce @ 2009-11-05 1:16 UTC (permalink / raw)
To: git
In-Reply-To: <1257383798-29826-1-git-send-email-spearce@spearce.org>
Test the major configuration settings which control access to
the repository:
http.getanyfile
http.uploadpack
http.receivepack
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
t/t5560-http-backend.sh | 229 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 229 insertions(+), 0 deletions(-)
create mode 100755 t/t5560-http-backend.sh
diff --git a/t/t5560-http-backend.sh b/t/t5560-http-backend.sh
new file mode 100755
index 0000000..908ba07
--- /dev/null
+++ b/t/t5560-http-backend.sh
@@ -0,0 +1,229 @@
+#!/bin/sh
+
+test_description='test git-http-backend'
+. ./test-lib.sh
+
+if test -n "$NO_CURL"; then
+ say 'skipping test, git built without http support'
+ test_done
+fi
+
+LIB_HTTPD_PORT=${LIB_HTTPD_PORT-'5560'}
+. "$TEST_DIRECTORY"/lib-httpd.sh
+start_httpd
+
+find_file() {
+ cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ find $1 -type f |
+ sed -e 1q
+}
+
+config() {
+ git --git-dir="$HTTPD_DOCUMENT_ROOT_PATH/repo.git" config $1 $2
+}
+
+GET() {
+ curl --include "$HTTPD_URL/smart/repo.git/$1" >out 2>/dev/null &&
+ tr '\015' Q <out |
+ sed '
+ s/Q$//
+ 1q
+ ' >act &&
+ echo "HTTP/1.1 $2" >exp &&
+ test_cmp exp act
+}
+
+POST() {
+ curl --include --data "$2" \
+ --header "Content-Type: application/x-$1-request" \
+ "$HTTPD_URL/smart/repo.git/$1" >out 2>/dev/null &&
+ tr '\015' Q <out |
+ sed '
+ s/Q$//
+ 1q
+ ' >act &&
+ echo "HTTP/1.1 $3" >exp &&
+ test_cmp exp act
+}
+
+log_div() {
+ echo >>"$HTTPD_ROOT_PATH"/access.log
+ echo "### $1" >>"$HTTPD_ROOT_PATH"/access.log
+ echo "###" >>"$HTTPD_ROOT_PATH"/access.log
+}
+
+test_expect_success 'setup repository' '
+ echo content >file &&
+ git add file &&
+ git commit -m one &&
+
+ mkdir "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ (cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ git --bare init &&
+ : >objects/info/alternates &&
+ : >objects/info/http-alternates
+ ) &&
+ git remote add public "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ git push public master:master &&
+
+ (cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ git repack -a -d
+ ) &&
+
+ echo other >file &&
+ git add file &&
+ git commit -m two &&
+ git push public master:master &&
+
+ LOOSE_URL=$(find_file objects/??) &&
+ PACK_URL=$(find_file objects/pack/*.pack) &&
+ IDX_URL=$(find_file objects/pack/*.idx)
+'
+
+get_static_files() {
+ GET HEAD "$1" &&
+ GET info/refs "$1" &&
+ GET objects/info/packs "$1" &&
+ GET objects/info/alternates "$1" &&
+ GET objects/info/http-alternates "$1" &&
+ GET $LOOSE_URL "$1" &&
+ GET $PACK_URL "$1" &&
+ GET $IDX_URL "$1"
+}
+
+test_expect_success 'direct refs/heads/master not found' '
+ log_div "refs/heads/master"
+ GET refs/heads/master "404 Not Found"
+'
+test_expect_success 'static file is ok' '
+ log_div "getanyfile default"
+ get_static_files "200 OK"
+'
+test_expect_success 'static file if http.getanyfile true is ok' '
+ log_div "getanyfile true"
+ config http.getanyfile true &&
+ get_static_files "200 OK"
+'
+test_expect_success 'static file if http.getanyfile false fails' '
+ log_div "getanyfile false"
+ config http.getanyfile false &&
+ get_static_files "403 Forbidden"
+'
+
+test_expect_success 'http.uploadpack default enabled' '
+ log_div "uploadpack default"
+ GET info/refs?service=git-upload-pack "200 OK" &&
+ POST git-upload-pack 0000 "200 OK"
+'
+test_expect_success 'http.uploadpack true' '
+ log_div "uploadpack true"
+ config http.uploadpack true &&
+ GET info/refs?service=git-upload-pack "200 OK" &&
+ POST git-upload-pack 0000 "200 OK"
+'
+test_expect_success 'http.uploadpack false' '
+ log_div "uploadpack false"
+ config http.uploadpack false &&
+ GET info/refs?service=git-upload-pack "403 Forbidden" &&
+ POST git-upload-pack 0000 "403 Forbidden"
+'
+
+test_expect_success 'http.receivepack default disabled' '
+ log_div "receivepack default"
+ GET info/refs?service=git-receive-pack "403 Forbidden" &&
+ POST git-receive-pack 0000 "403 Forbidden"
+'
+test_expect_success 'http.receivepack true' '
+ log_div "receivepack true"
+ config http.receivepack true &&
+ GET info/refs?service=git-receive-pack "200 OK" &&
+ POST git-receive-pack 0000 "200 OK"
+'
+test_expect_success 'http.receivepack false' '
+ log_div "receivepack false"
+ config http.receivepack false &&
+ GET info/refs?service=git-receive-pack "403 Forbidden" &&
+ POST git-receive-pack 0000 "403 Forbidden"
+'
+
+cat >exp <<EOF
+
+### refs/heads/master
+###
+GET /smart/repo.git/refs/heads/master HTTP/1.1 404 -
+
+### getanyfile default
+###
+GET /smart/repo.git/HEAD HTTP/1.1 200
+GET /smart/repo.git/info/refs HTTP/1.1 200
+GET /smart/repo.git/objects/info/packs HTTP/1.1 200
+GET /smart/repo.git/objects/info/alternates HTTP/1.1 200 -
+GET /smart/repo.git/objects/info/http-alternates HTTP/1.1 200 -
+GET /smart/repo.git/$LOOSE_URL HTTP/1.1 200
+GET /smart/repo.git/$PACK_URL HTTP/1.1 200
+GET /smart/repo.git/$IDX_URL HTTP/1.1 200
+
+### getanyfile true
+###
+GET /smart/repo.git/HEAD HTTP/1.1 200
+GET /smart/repo.git/info/refs HTTP/1.1 200
+GET /smart/repo.git/objects/info/packs HTTP/1.1 200
+GET /smart/repo.git/objects/info/alternates HTTP/1.1 200 -
+GET /smart/repo.git/objects/info/http-alternates HTTP/1.1 200 -
+GET /smart/repo.git/$LOOSE_URL HTTP/1.1 200
+GET /smart/repo.git/$PACK_URL HTTP/1.1 200
+GET /smart/repo.git/$IDX_URL HTTP/1.1 200
+
+### getanyfile false
+###
+GET /smart/repo.git/HEAD HTTP/1.1 403 -
+GET /smart/repo.git/info/refs HTTP/1.1 403 -
+GET /smart/repo.git/objects/info/packs HTTP/1.1 403 -
+GET /smart/repo.git/objects/info/alternates HTTP/1.1 403 -
+GET /smart/repo.git/objects/info/http-alternates HTTP/1.1 403 -
+GET /smart/repo.git/$LOOSE_URL HTTP/1.1 403 -
+GET /smart/repo.git/$PACK_URL HTTP/1.1 403 -
+GET /smart/repo.git/$IDX_URL HTTP/1.1 403 -
+
+### uploadpack default
+###
+GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/1.1 200
+POST /smart/repo.git/git-upload-pack HTTP/1.1 200 -
+
+### uploadpack true
+###
+GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/1.1 200
+POST /smart/repo.git/git-upload-pack HTTP/1.1 200 -
+
+### uploadpack false
+###
+GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/1.1 403 -
+POST /smart/repo.git/git-upload-pack HTTP/1.1 403 -
+
+### receivepack default
+###
+GET /smart/repo.git/info/refs?service=git-receive-pack HTTP/1.1 403 -
+POST /smart/repo.git/git-receive-pack HTTP/1.1 403 -
+
+### receivepack true
+###
+GET /smart/repo.git/info/refs?service=git-receive-pack HTTP/1.1 200
+POST /smart/repo.git/git-receive-pack HTTP/1.1 200 -
+
+### receivepack false
+###
+GET /smart/repo.git/info/refs?service=git-receive-pack HTTP/1.1 403 -
+POST /smart/repo.git/git-receive-pack HTTP/1.1 403 -
+EOF
+test_expect_success 'server request log matches test results' '
+ sed -e "
+ s/^.* \"//
+ s/\"//
+ s/ [1-9][0-9]*\$//
+ s/^GET /GET /
+ " >act <"$HTTPD_ROOT_PATH"/access.log &&
+ test_cmp exp act
+'
+
+stop_httpd
+test_done
--
1.6.5.2.295.g0d105
^ permalink raw reply related
* [PATCH v5.1 2/3] http-backend: Use http.getanyfile to disable dumb HTTP serving
From: Shawn O. Pearce @ 2009-11-05 1:16 UTC (permalink / raw)
To: git
In-Reply-To: <1257383798-29826-1-git-send-email-spearce@spearce.org>
Some repository owners may wish to enable smart HTTP, but disallow
dumb content serving. Disallowing dumb serving might be because
the owners want to rely upon reachability to control which objects
clients may access from the repository, or they just want to
encourage clients to use the more bandwidth efficient transport.
If http.getanyfile is set to false the backend CGI will return with
'403 Forbidden' when an object file is accessed by a dumb client.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/git-http-backend.txt | 8 ++++++++
http-backend.c | 34 ++++++++++++++++++++++++++++------
2 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index f17251a..67aec06 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -29,6 +29,14 @@ SERVICES
These services can be enabled/disabled using the per-repository
configuration file:
+http.getanyfile::
+ This serves older Git clients which are unable to use the
+ upload pack service. When enabled, clients are able to read
+ any file within the repository, including objects that are
+ no longer reachable from a branch but are still present.
+ It is enabled by default, but a repository can disable it
+ by setting this configuration item to `false`.
+
http.uploadpack::
This serves 'git-fetch-pack' and 'git-ls-remote' clients.
It is enabled by default, but a repository can disable it
diff --git a/http-backend.c b/http-backend.c
index 7900cda..9021266 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -10,6 +10,7 @@
static const char content_type[] = "Content-Type";
static const char content_length[] = "Content-Length";
static const char last_modified[] = "Last-Modified";
+static int getanyfile = 1;
static struct string_list *query_params;
@@ -194,6 +195,12 @@ static NORETURN void forbidden(const char *err, ...)
exit(0);
}
+static void select_getanyfile(void)
+{
+ if (!getanyfile)
+ forbidden("Unsupported service: getanyfile");
+}
+
static void send_strbuf(const char *type, struct strbuf *buf)
{
hdr_int(content_length, buf->len);
@@ -238,38 +245,51 @@ static void send_file(const char *the_type, const char *name)
static void get_text_file(char *name)
{
+ select_getanyfile();
hdr_nocache();
send_file("text/plain", name);
}
static void get_loose_object(char *name)
{
+ select_getanyfile();
hdr_cache_forever();
send_file("application/x-git-loose-object", name);
}
static void get_pack_file(char *name)
{
+ select_getanyfile();
hdr_cache_forever();
send_file("application/x-git-packed-objects", name);
}
static void get_idx_file(char *name)
{
+ select_getanyfile();
hdr_cache_forever();
send_file("application/x-git-packed-objects-toc", name);
}
static int http_config(const char *var, const char *value, void *cb)
{
- struct rpc_service *svc = cb;
-
- if (!prefixcmp(var, "http.") &&
- !strcmp(var + 5, svc->config_name)) {
- svc->enabled = git_config_bool(var, value);
+ if (!strcmp(var, "http.getanyfile")) {
+ getanyfile = git_config_bool(var, value);
return 0;
}
+ if (!prefixcmp(var, "http.")) {
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(rpc_service); i++) {
+ struct rpc_service *svc = &rpc_service[i];
+ if (!strcmp(var + 5, svc->config_name)) {
+ svc->enabled = git_config_bool(var, value);
+ return 0;
+ }
+ }
+ }
+
/* we are not interested in parsing any other configuration here */
return 0;
}
@@ -293,7 +313,6 @@ static struct rpc_service *select_service(const char *name)
if (!svc)
forbidden("Unsupported service: '%s'", name);
- git_config(http_config, svc);
if (svc->enabled < 0) {
const char *user = getenv("REMOTE_USER");
svc->enabled = (user && *user) ? 1 : 0;
@@ -442,6 +461,7 @@ static void get_info_refs(char *arg)
run_service(argv);
} else {
+ select_getanyfile();
for_each_ref(show_text_ref, &buf);
send_strbuf("text/plain", &buf);
}
@@ -455,6 +475,7 @@ static void get_info_packs(char *arg)
struct packed_git *p;
size_t cnt = 0;
+ select_getanyfile();
prepare_packed_git();
for (p = packed_git; p; p = p->next) {
if (p->pack_local)
@@ -621,6 +642,7 @@ int main(int argc, char **argv)
if (!enter_repo(dir, 0))
not_found("Not a git repository: '%s'", dir);
+ git_config(http_config, NULL);
cmd->imp(cmd_arg);
return 0;
}
--
1.6.5.2.295.g0d105
^ permalink raw reply related
* Re: [PATCH] MSVC: port pthread code to native Windows threads
From: Nicolas Pitre @ 2009-11-05 0:27 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Andrzej K. Haczewski, Johannes Sixt, git
In-Reply-To: <alpine.LNX.2.00.0911041640060.14365@iabervon.org>
On Wed, 4 Nov 2009, Daniel Barkalow wrote:
> On Wed, 4 Nov 2009, Nicolas Pitre wrote:
>
> > On Wed, 4 Nov 2009, Daniel Barkalow wrote:
> >
> > > On Wed, 4 Nov 2009, Andrzej K. Haczewski wrote:
> > >
> > > > 2009/11/4 Johannes Sixt <j.sixt@viscovery.net>:
> > > > >
> > > > > You are right. But #ifdef THREADED_DELTA_SEARCH is about a "generic"
> > > > > property of the code and is already used elsewhere in the file, whereas
> > > > > #ifdef WIN32 would be new and is is about platform differences.
> > > > >
> > > > > Anyway, we would have to see what Junio says about the new function calls,
> > > > > because he's usually quite anal when it comes to added code vs. static
> > > > > initialization. ;)
> > > >
> > > > I could do it with wrappers for pthread_mutex_lock and _unlock and
> > > > lazy init there plus lazy init cond var in cond_wait and _signal, that
> > > > way it could be done without any additional code in the first #ifdef.
> > > > But I don't see any simple solution for working around
> > > > deinitialization, that's why I'd leave non-static initialization. Let
> > > > me put some touchups and resubmit for another round.
> > >
> > > Is it actually necessary to deinitialize? Since the variables are static
> > > and therefore can't leak, and would presumably not need to be
> > > reinitialized differently if they were used again, I think they should be
> > > able to just stay. If Windows is unhappy about processes still having
> > > locks initialized at exit, I suppose we could go through and destroy all
> > > our mutexes and conds at cleanup time. Pthreads does have the appropriate
> > > functions, and it would be correct to use them, although unnecessary.
> >
> > Lazy initialization would probably turn up to be more expensive
> > (checking a flag on each usage) than unconditionally initializing them
> > once. Remember that those are used at least once per object meaning a
> > lot.
>
> Meh, checking a flag on the same cache line as the lock you're about to
> take can't be a big incremental cost, especially if it's actually checking
> whether some sort of cookie is non-zero before doing something with it.
This is still a bigger cost than not checking such flag at all.
Especially if the check will be false on every call but the first one
out of millions. I agree this is not significant, but neither is a
runtime initialization vs a static one.
> I don't think it matters terribly much either way which we use, so long as
> its consistent. It'd be nice if the static initializers worked, just
> because people seem to write code with them, but we could just not do that
> in the future.
Maybe the static initializer can be turned into a global constructor on
Windows?
Nicolas
^ permalink raw reply
* Re: [PATCH] MSVC: Windows-native implementation for subset of Pthreads API
From: Nicolas Pitre @ 2009-11-05 0:22 UTC (permalink / raw)
To: Andrzej K. Haczewski; +Cc: git, Johannes Sixt
In-Reply-To: <4AF214D5.6050202@gmail.com>
On Thu, 5 Nov 2009, Andrzej K. Haczewski wrote:
> @@ -1638,6 +1657,8 @@ static void ll_find_deltas(struct object_entry **list, unsigned list_size,
> delta_search_threads);
> p = xcalloc(delta_search_threads, sizeof(*p));
>
> + init_threaded_search();
Careful. At the beginning of the function you'll find:
if (delta_search_threads <= 1) {
find_deltas(list, &list_size, window, depth, processed);
return;
}
That is, if we have thread support compiled in but we're told to use
only one thread, then the bulk of the work splitting is bypassed
entirely. Inside find_deltas() there will still be pthread_mutex_lock()
and pthread_mutex_unlock() calls even if no threads are spawned.
Nicolas
^ permalink raw reply
* Re: [PATCH v2 11/13] Allow helpers to request the path to the .git directory
From: Sverre Rabbelier @ 2009-11-05 0:15 UTC (permalink / raw)
To: Junio C Hamano
Cc: Daniel Barkalow, Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <7vd43xg7lf.fsf@alter.siamese.dyndns.org>
Heya,
On Thu, Nov 5, 2009 at 01:04, Junio C Hamano <gitster@pobox.com> wrote:
> What do you mean by <alias> here? Is it the <alias> in
>
> [remote "alias"]
> url = hg::http://some.where/repo/sito/ry.hg
Yes, that one.
> IOW, can a user ever use the foreign interface directly from the command
> line, without ever defining such entries in .git/config, perhaps using
> "git remote"?
No, my primary use case for remote helpers is currently 'git clone
hg::https://soc.googlecode.com/hg/', and to have 'git fetch origin'
Just Work (tm) from that clone. My secondary use case though, is to
support 'git fetch hg:: https://soc.googlecode.com/hg/' just as well
and have 'git log FETCH_HEAD' Just Work (tm) too. In that light
.git/info/remote-<vcs>/ is probably a better idea, so that the helper
can use say '.git/info/remote-<vcs>/fetch/ for one-time fetches.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v2 11/13] Allow helpers to request the path to the .git directory
From: Junio C Hamano @ 2009-11-05 0:04 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Daniel Barkalow, Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0911041406tce0956ai2ad3fe6cfbdc546d@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
>> In any case, I think it would be good to have
>> something like that, but I think maybe we should tell it where it can put
>> its status files, rather than telling it where the .git dir is.
>
> Yes, that would probably be a good idea, .git/info/remote-<vcs>/<alias> perhaps?
What do you mean by <alias> here? Is it the <alias> in
[remote "alias"]
url = hg::http://some.where/repo/sito/ry.hg
IOW, can a user ever use the foreign interface directly from the command
line, without ever defining such entries in .git/config, perhaps using
"git remote"?
^ permalink raw reply
* Re: thoughts on setting core.logAllRefUpdates default true for bare repos
From: Sverre Rabbelier @ 2009-11-04 23:59 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Sitaram Chamarty, Johannes Schindelin, git
In-Reply-To: <20091104235241.GA12984@vidovic>
Heya,
On Thu, Nov 5, 2009 at 00:52, Nicolas Sebrecht <nicolas.s.dev@gmx.fr> wrote:
> Or did you mean if "non-admin users could" ?
We're talking about the case wherein a confidential object is pruned,
regardless of whether it is a non-admin or admin user doing the
pruning, they should be able to 'reflog expire' if they can 'git gc'.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox