* [PATCH 1/5] gitk: Remove forced use of sans-serif font
From: Mark Hills @ 2009-12-28 20:03 UTC (permalink / raw)
To: git
The X resources set using uifont cover this case.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
---
gitk-git/gitk | 12 ------------
1 files changed, 0 insertions(+), 12 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 364c7a8..c58fd58 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -10513,7 +10513,6 @@ proc mkfontdisp {font top which} {
set fontpref($font) [set $font]
${NS}::button $top.${font}but -text $which \
-command [list choosefont $font $which]
- if {!$use_ttk} {$top.${font}but configure -font optionfont}
${NS}::label $top.$font -relief flat -font $font \
-text $fontattr($font,family) -justify left
grid x $top.${font}but $top.$font -sticky w
@@ -10776,15 +10775,6 @@ proc doprefs {} {
mkfontdisp textfont $top [mc "Diff display font"]
mkfontdisp uifont $top [mc "User interface font"]
- if {!$use_ttk} {
- foreach w {maxpctl maxwidthl showlocal autoselect tabstopl ntag
- ldiff lattr extdifff.l extdifff.b bgbut fgbut
- diffoldbut diffnewbut hunksepbut markbgbut selbgbut
- want_ttk ttk_note} {
- $top.$w configure -font optionfont
- }
- }
-
${NS}::frame $top.buts
${NS}::button $top.buts.ok -text [mc "OK"] -command prefsok -default active
${NS}::button $top.buts.can -text [mc "Cancel"] -command prefscan -default normal
@@ -11396,8 +11386,6 @@ namespace import ::msgcat::mc
catch {source ~/.gitk}
-font create optionfont -family sans-serif -size -12
-
parsefont mainfont $mainfont
eval font create mainfont [fontflags mainfont]
eval font create mainfontbold [fontflags mainfont 1]
--
1.6.6
^ permalink raw reply related
* [PATCH 2/5] gitk: Set the font for all spinbox widgets
From: Mark Hills @ 2009-12-28 20:04 UTC (permalink / raw)
To: git
In-Reply-To: <1262030643-12952-1-git-send-email-mark@pogo.org.uk>
Use the X resources to set the font, removing the need to set the font
for specific widgets.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
---
gitk-git/gitk | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index c58fd58..299a2ae 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -1876,6 +1876,7 @@ proc setoptions {} {
option add *Message.font uifont startupFile
option add *Entry.font uifont startupFile
option add *Labelframe.font uifont startupFile
+ option add *Spinbox.font textfont startupFile
}
# Make a menu and submenus.
@@ -2226,7 +2227,7 @@ proc makewindow {} {
-command changediffdisp -variable diffelide -value {1 0}
${NS}::label .bleft.mid.labeldiffcontext -text " [mc "Lines of context"]: "
pack .bleft.mid.diff .bleft.mid.old .bleft.mid.new -side left
- spinbox .bleft.mid.diffcontext -width 5 -font textfont \
+ spinbox .bleft.mid.diffcontext -width 5 \
-from 0 -increment 1 -to 10000000 \
-validate all -validatecommand "diffcontextvalidate %P" \
-textvariable diffcontextstring
--
1.6.6
^ permalink raw reply related
* [PATCH 4/5] gitk: Disable option when themed widgets are not available
From: Mark Hills @ 2009-12-28 20:04 UTC (permalink / raw)
To: git
In-Reply-To: <1262030643-12952-3-git-send-email-mark@pogo.org.uk>
Disable the widget instead of using the label to indicate that themed
widgets are not available.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
---
gitk-git/gitk | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 5cbc885..5008753 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -10721,14 +10721,14 @@ proc doprefs {} {
${NS}::label $top.lgen -text [mc "General options"]
grid $top.lgen - -sticky w -pady 10
- ${NS}::checkbutton $top.want_ttk -variable want_ttk \
- -text [mc "Use themed widgets"]
if {$have_ttk} {
- ${NS}::label $top.ttk_note -text [mc "(change requires restart)"]
+ ${NS}::checkbutton $top.want_ttk -variable want_ttk \
+ -text [mc "Use themed widgets (change requires restart)"]
} else {
- ${NS}::label $top.ttk_note -text [mc "(currently unavailable)"]
+ ${NS}::checkbutton $top.want_ttk \
+ -text [mc "Use themed widgets"] -state disabled
}
- grid x $top.want_ttk $top.ttk_note -sticky w
+ grid x $top.want_ttk - -sticky w
${NS}::label $top.cdisp -text [mc "Colors: press to choose"]
grid $top.cdisp - -sticky w -pady 10
--
1.6.6
^ permalink raw reply related
* [PATCH 3/5] gitk: Set the font for all listbox widgets
From: Mark Hills @ 2009-12-28 20:04 UTC (permalink / raw)
To: git
In-Reply-To: <1262030643-12952-2-git-send-email-mark@pogo.org.uk>
This affects the font chooser.
Signed-off-by: Mark Hills <mark@pogo.org.uk>
---
gitk-git/gitk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 299a2ae..5cbc885 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -1877,6 +1877,7 @@ proc setoptions {} {
option add *Entry.font uifont startupFile
option add *Labelframe.font uifont startupFile
option add *Spinbox.font textfont startupFile
+ option add *Listbox.font mainfont startupFile
}
# Make a menu and submenus.
--
1.6.6
^ permalink raw reply related
* Re: immutable tags?
From: Carlos Santana @ 2009-12-28 20:39 UTC (permalink / raw)
To: david; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0912281223440.24130@asgard.lang.hm>
Thanks for the reply David.
I think 'tagged directory' wasn't the appropriate phrase here.
In Subversion like systems branches and tags are same, i.e., both are
created using 'svn copy'. Branches are generally created for separate
line of development and tags for releasing software. So developers
follow convention of not checking in anything into tags. Otherwise
they are same.
I know that creating branches/tags doesn't involve copying files into
new directory in case of git. It will act as a pointer and make note
of changes thereafter. What I am not sure is difference between
branches and tags. Is it left to developer to follow subversion like
convention or git provides some mechanism to 'lock' tags?
-
CS.
On Mon, Dec 28, 2009 at 2:25 PM, <david@lang.hm> wrote:
> On Mon, 28 Dec 2009, Carlos Santana wrote:
>
>> I would like to know if there is any difference between branches and
>> tags. Is it only conceptual - convention to be followed by a developer
>> or some technical difference? e.g. : Is it possible to create
>> immutable tags so that nothing can be checked in to that 'tagged
>> directory'?
>
> tags are pointers into the tree. tags do not change.
>
> in git directories are not tagged, so I'm not sure what you are working
> towards here.
>
> David Lang
>
>
^ permalink raw reply
* Re: immutable tags?
From: Matthieu Moy @ 2009-12-28 20:58 UTC (permalink / raw)
To: Carlos Santana; +Cc: git
In-Reply-To: <92c9564e0912281204h13c6a566w95069023e6909eda@mail.gmail.com>
Carlos Santana <neubyr@gmail.com> writes:
> I would like to know if there is any difference between branches and
> tags. Is it only conceptual - convention to be followed by a developer
> or some technical difference? e.g. : Is it possible to create
> immutable tags so that nothing can be checked in to that 'tagged
> directory'?
A tag is just a named reference to a particular commit (or other
object indeed). Once you set a tag, it doesn't move (unless you
override it explicitely).
You can't prevent people from commiting something. It won't move the
tag, but it will create a new commit whose parent is the tagged
commit.
A branch is also a named reference to a commit, but the difference is
that when you commit, the current branch is updated (i.e. the
reference points to the new commit).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: immutable tags?
From: david @ 2009-12-28 21:15 UTC (permalink / raw)
To: Carlos Santana; +Cc: git
In-Reply-To: <92c9564e0912281239h49f9138ena8bbb3a63a337a55@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2296 bytes --]
On Mon, 28 Dec 2009, Carlos Santana wrote:
> Thanks for the reply David.
> I think 'tagged directory' wasn't the appropriate phrase here.
>
> In Subversion like systems branches and tags are same, i.e., both are
> created using 'svn copy'. Branches are generally created for separate
> line of development and tags for releasing software. So developers
> follow convention of not checking in anything into tags. Otherwise
> they are same.
>
> I know that creating branches/tags doesn't involve copying files into
> new directory in case of git. It will act as a pointer and make note
> of changes thereafter. What I am not sure is difference between
> branches and tags. Is it left to developer to follow subversion like
> convention or git provides some mechanism to 'lock' tags?
git works very differently than subversion. All of git history is a
branching tree of commits, all that a tag is is a pointer to a particular
commit somewhere in this tree. it does not have the be the most recent
commit on the branch.
all branches are (pretty much) equal, you can commit and do development on
any branch.
as you say above, branches are seperate lines of development and tags can
point at releases, but when you have a branch that you are doing
development on, you don't have to stop doing development there when you do
a release, anyone who checks out the tag will get the same thing no matter
what additional development you do on that branch in the future.
does this help?
David Lang
> -
> CS.
>
>
>
> On Mon, Dec 28, 2009 at 2:25 PM, <david@lang.hm> wrote:
>> On Mon, 28 Dec 2009, Carlos Santana wrote:
>>
>>> I would like to know if there is any difference between branches and
>>> tags. Is it only conceptual - convention to be followed by a developer
>>> or some technical difference? e.g. : Is it possible to create
>>> immutable tags so that nothing can be checked in to that 'tagged
>>> directory'?
>>
>> tags are pointers into the tree. tags do not change.
>>
>> in git directories are not tagged, so I'm not sure what you are working
>> towards here.
>>
>> David Lang
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: immutable tags?
From: David Kågedal @ 2009-12-28 21:21 UTC (permalink / raw)
To: git
In-Reply-To: <92c9564e0912281204h13c6a566w95069023e6909eda@mail.gmail.com>
Carlos Santana <neubyr@gmail.com> writes:
> I would like to know if there is any difference between branches and
> tags. Is it only conceptual - convention to be followed by a developer
> or some technical difference? e.g. : Is it possible to create
> immutable tags so that nothing can be checked in to that 'tagged
> directory'?
You are always in full control of your own repository, and have no
control over what other people do with their's. So you can't prevent
other people from changing the tags in their private repos, but you can
prevent them from propagating these changes back to you, or to a central
repository you control.
But perhaps there is nothing to worry about. I think the git commands
won't modify a tag unless you force it.
Also, if you use signed tags, you can be sure that they are not silently
replaced while still claiming to be tagged by you.
--
David Kågedal
^ permalink raw reply
* [PATCH] Smart-http: check if repository is OK to export before serving it
From: Tarmigan Casebolt @ 2009-12-28 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce, Tarmigan Casebolt
In-Reply-To: <20091228170811.GE2252@spearce.org>
Similar to how git-daemon checks whether a repository is OK to be
exported, smart-http should also check. This check can be satisfied
in two different ways: the environmental variable GIT_HTTP_EXPORT_ALL
may be set to export all repositories, or the individual repository
may have the file git-daemon-export-ok.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
OK, I see what you're saying Shawn. I've changed it back to "404
Not Found" again.
I've also reordered the new tests since the last time I sent it out.
The new tests use the same test as in
"static file is ok"
so put the new tests after that test in case that test breaks.
Documentation/git-http-backend.txt | 10 +++++++++
http-backend.c | 3 ++
t/lib-httpd/apache.conf | 5 ++++
t/t5560-http-backend.sh | 39 ++++++++++++++++++++++++++++++++++-
4 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-http-backend.txt b/Documentation/git-http-backend.txt
index 67aec06..c8fe08a 100644
--- a/Documentation/git-http-backend.txt
+++ b/Documentation/git-http-backend.txt
@@ -18,6 +18,11 @@ The program supports clients fetching using both the smart HTTP protcol
and the backwards-compatible dumb HTTP protocol, as well as clients
pushing using the smart HTTP protocol.
+It verifies that the directory has the magic file
+"git-daemon-export-ok", and it will refuse to export any git directory
+that hasn't explicitly been marked for export this way (unless the
+GIT_HTTP_EXPORT_ALL environmental variable is set).
+
By default, only the `upload-pack` service is enabled, which serves
'git-fetch-pack' and 'git-ls-remote' clients, which are invoked from
'git-fetch', 'git-pull', and 'git-clone'. If the client is authenticated,
@@ -70,6 +75,7 @@ Apache 2.x::
+
----------------------------------------------------------------
SetEnv GIT_PROJECT_ROOT /var/www/git
+SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
----------------------------------------------------------------
+
@@ -157,6 +163,10 @@ by the invoking web server, including:
* QUERY_STRING
* REQUEST_METHOD
+The GIT_HTTP_EXPORT_ALL environmental variable may be passed to
+'git-http-backend' to bypass the check for the "git-daemon-export-ok"
+file in each repository before allowing export of that repository.
+
The backend process sets GIT_COMMITTER_NAME to '$REMOTE_USER' and
GIT_COMMITTER_EMAIL to '$\{REMOTE_USER}@http.$\{REMOTE_ADDR\}',
ensuring that any reflogs created by 'git-receive-pack' contain some
diff --git a/http-backend.c b/http-backend.c
index f729488..345c12b 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -648,6 +648,9 @@ int main(int argc, char **argv)
setup_path();
if (!enter_repo(dir, 0))
not_found("Not a git repository: '%s'", dir);
+ if (!getenv("GIT_HTTP_EXPORT_ALL") &&
+ access("git-daemon-export-ok", F_OK) )
+ not_found("Repository not exported: '%s'", dir);
git_config(http_config, NULL);
cmd->imp(cmd_arg);
diff --git a/t/lib-httpd/apache.conf b/t/lib-httpd/apache.conf
index 0fe3fd0..4961505 100644
--- a/t/lib-httpd/apache.conf
+++ b/t/lib-httpd/apache.conf
@@ -22,8 +22,13 @@ Alias /dumb/ www/
<Location /smart/>
SetEnv GIT_EXEC_PATH ${GIT_EXEC_PATH}
+ SetEnv GIT_HTTP_EXPORT_ALL
+</Location>
+<Location /smart_noexport/>
+ SetEnv GIT_EXEC_PATH ${GIT_EXEC_PATH}
</Location>
ScriptAlias /smart/ ${GIT_EXEC_PATH}/git-http-backend/
+ScriptAlias /smart_noexport/ ${GIT_EXEC_PATH}/git-http-backend/
<Directory ${GIT_EXEC_PATH}>
Options None
</Directory>
diff --git a/t/t5560-http-backend.sh b/t/t5560-http-backend.sh
index ed034bc..04a9896 100755
--- a/t/t5560-http-backend.sh
+++ b/t/t5560-http-backend.sh
@@ -23,7 +23,7 @@ config() {
}
GET() {
- curl --include "$HTTPD_URL/smart/repo.git/$1" >out 2>/dev/null &&
+ curl --include "$HTTPD_URL/$SMART/repo.git/$1" >out 2>/dev/null &&
tr '\015' Q <out |
sed '
s/Q$//
@@ -91,6 +91,7 @@ get_static_files() {
GET $IDX_URL "$1"
}
+SMART=smart
test_expect_success 'direct refs/heads/master not found' '
log_div "refs/heads/master"
GET refs/heads/master "404 Not Found"
@@ -99,6 +100,19 @@ test_expect_success 'static file is ok' '
log_div "getanyfile default"
get_static_files "200 OK"
'
+SMART=smart_noexport
+test_expect_success 'no export by default' '
+ log_div "no git-daemon-export-ok"
+ get_static_files "404 Not Found"
+'
+test_expect_success 'export if git-daemon-export-ok' '
+ log_div "git-daemon-export-ok"
+ (cd "$HTTPD_DOCUMENT_ROOT_PATH/repo.git" &&
+ touch git-daemon-export-ok
+ ) &&
+ get_static_files "200 OK"
+'
+SMART=smart
test_expect_success 'static file if http.getanyfile true is ok' '
log_div "getanyfile true"
config http.getanyfile true &&
@@ -145,7 +159,6 @@ test_expect_success 'http.receivepack false' '
GET info/refs?service=git-receive-pack "403 Forbidden" &&
POST git-receive-pack 0000 "403 Forbidden"
'
-
run_backend() {
REQUEST_METHOD=GET \
GIT_PROJECT_ROOT="$HTTPD_DOCUMENT_ROOT_PATH" \
@@ -194,6 +207,28 @@ 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
+### no git-daemon-export-ok
+###
+GET /smart_noexport/repo.git/HEAD HTTP/1.1 404 -
+GET /smart_noexport/repo.git/info/refs HTTP/1.1 404 -
+GET /smart_noexport/repo.git/objects/info/packs HTTP/1.1 404 -
+GET /smart_noexport/repo.git/objects/info/alternates HTTP/1.1 404 -
+GET /smart_noexport/repo.git/objects/info/http-alternates HTTP/1.1 404 -
+GET /smart_noexport/repo.git/$LOOSE_URL HTTP/1.1 404 -
+GET /smart_noexport/repo.git/$PACK_URL HTTP/1.1 404 -
+GET /smart_noexport/repo.git/$IDX_URL HTTP/1.1 404 -
+
+### git-daemon-export-ok
+###
+GET /smart_noexport/repo.git/HEAD HTTP/1.1 200
+GET /smart_noexport/repo.git/info/refs HTTP/1.1 200
+GET /smart_noexport/repo.git/objects/info/packs HTTP/1.1 200
+GET /smart_noexport/repo.git/objects/info/alternates HTTP/1.1 200 -
+GET /smart_noexport/repo.git/objects/info/http-alternates HTTP/1.1 200 -
+GET /smart_noexport/repo.git/$LOOSE_URL HTTP/1.1 200
+GET /smart_noexport/repo.git/$PACK_URL HTTP/1.1 200
+GET /smart_noexport/repo.git/$IDX_URL HTTP/1.1 200
+
### getanyfile true
###
GET /smart/repo.git/HEAD HTTP/1.1 200
--
1.6.6.1.g8d7b9
^ permalink raw reply related
* [PATCH RFC 1/2] Smart-http tests: Break test t5560-http-backend into pieces
From: Tarmigan Casebolt @ 2009-12-28 22:04 UTC (permalink / raw)
To: Shawn O . Pearce; +Cc: git, Tarmigan Casebolt
This should introduce no functional change in the tests or the amount
of test coverage.
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
t/t5560-http-backend.sh | 135 +-------------------------------------
t/t5561-http-backend-noserver.sh | 52 +++++++++++++++
t/t556x_common | 105 +++++++++++++++++++++++++++++
3 files changed, 158 insertions(+), 134 deletions(-)
create mode 100755 t/t5561-http-backend-noserver.sh
create mode 100755 t/t556x_common
diff --git a/t/t5560-http-backend.sh b/t/t5560-http-backend.sh
index ed034bc..b0d08e2 100755
--- a/t/t5560-http-backend.sh
+++ b/t/t5560-http-backend.sh
@@ -12,16 +12,6 @@ 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 |
@@ -52,130 +42,7 @@ log_div() {
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"
-'
-
-run_backend() {
- REQUEST_METHOD=GET \
- GIT_PROJECT_ROOT="$HTTPD_DOCUMENT_ROOT_PATH" \
- PATH_INFO="$2" \
- git http-backend >act.out 2>act.err
-}
-
-path_info() {
- if test $1 = 0; then
- run_backend "$2"
- else
- test_must_fail run_backend "$2" &&
- echo "fatal: '$2': aliased" >exp.err &&
- test_cmp exp.err act.err
- fi
-}
-
-test_expect_success 'http-backend blocks bad PATH_INFO' '
- config http.getanyfile true &&
-
- run_backend 0 /repo.git/HEAD &&
-
- run_backend 1 /repo.git/../HEAD &&
- run_backend 1 /../etc/passwd &&
- run_backend 1 ../etc/passwd &&
- run_backend 1 /etc//passwd &&
- run_backend 1 /etc/./passwd &&
- run_backend 1 /etc/.../passwd &&
- run_backend 1 //domain/data.txt
-'
+. "$TEST_DIRECTORY"/t556x_common
cat >exp <<EOF
diff --git a/t/t5561-http-backend-noserver.sh b/t/t5561-http-backend-noserver.sh
new file mode 100755
index 0000000..501b328
--- /dev/null
+++ b/t/t5561-http-backend-noserver.sh
@@ -0,0 +1,52 @@
+#!/bin/sh
+
+test_description='test git-http-backend-noserver'
+. ./test-lib.sh
+
+HTTPD_DOCUMENT_ROOT_PATH="$TRASH_DIRECTORY"
+
+GET() {
+ return 0
+}
+
+POST() {
+ return 0
+}
+
+logdiv() {
+ return 0
+}
+
+. "$TEST_DIRECTORY"/t556x_common
+
+run_backend() {
+ REQUEST_METHOD=GET \
+ GIT_PROJECT_ROOT="$HTTPD_DOCUMENT_ROOT_PATH" \
+ PATH_INFO="$2" \
+ git http-backend >act.out 2>act.err
+}
+
+path_info() {
+ if test $1 = 0; then
+ run_backend "$2"
+ else
+ test_must_fail run_backend "$2" &&
+ echo "fatal: '$2': aliased" >exp.err &&
+ test_cmp exp.err act.err
+ fi
+}
+
+test_expect_success 'http-backend blocks bad PATH_INFO' '
+ config http.getanyfile true &&
+
+ run_backend 0 /repo.git/HEAD &&
+
+ run_backend 1 /repo.git/../HEAD &&
+ run_backend 1 /../etc/passwd &&
+ run_backend 1 ../etc/passwd &&
+ run_backend 1 /etc//passwd &&
+ run_backend 1 /etc/./passwd &&
+ run_backend 1 /etc/.../passwd &&
+ run_backend 1 //domain/data.txt
+'
+test_done
diff --git a/t/t556x_common b/t/t556x_common
new file mode 100755
index 0000000..1845072
--- /dev/null
+++ b/t/t556x_common
@@ -0,0 +1,105 @@
+#!/bin/sh
+
+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
+}
+
+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"
+'
--
1.6.6.62.g67314
^ permalink raw reply related
* [PATCH RFC 2/2] Smart-http tests: Test http-backend without curl or a webserver
From: Tarmigan Casebolt @ 2009-12-28 22:04 UTC (permalink / raw)
To: Shawn O . Pearce; +Cc: git, Tarmigan Casebolt
In-Reply-To: <1262037899-16786-1-git-send-email-tarmigan+git@gmail.com>
This reuses many of the tests from t5560 but runs those tests without curl
or a webserver. This will hopefully increase the testing coverage for
http-backend because it does not require users to set GIT_TEST_HTTPD.
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
---
t/t5561-http-backend-noserver.sh | 45 ++++++++++++++++++++++----------------
1 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/t/t5561-http-backend-noserver.sh b/t/t5561-http-backend-noserver.sh
index 501b328..6371e97 100755
--- a/t/t5561-http-backend-noserver.sh
+++ b/t/t5561-http-backend-noserver.sh
@@ -5,12 +5,35 @@ test_description='test git-http-backend-noserver'
HTTPD_DOCUMENT_ROOT_PATH="$TRASH_DIRECTORY"
+run_backend() {
+ echo "$3"| \
+ QUERY_STRING="${2#*\?}" \
+ GIT_PROJECT_ROOT="$HTTPD_DOCUMENT_ROOT_PATH" \
+ PATH_INFO="${2%%\?*}" \
+ git http-backend >act.out 2>act.err
+}
+
GET() {
- return 0
+ REQUEST_METHOD="GET" \
+ run_backend 0 "/repo.git/$1" &&
+ grep "Status" act.out >act
+ if [ $? -ne 1 ];
+ then
+ printf "Status: $2\r\n" > exp &&
+ test_cmp exp act
+ fi
}
POST() {
- return 0
+ REQUEST_METHOD="POST" \
+ CONTENT_TYPE="application/x-$1-request" \
+ run_backend 0 "/repo.git/$1" "$2" &&
+ grep "Status" act.out >act
+ if [ $? -ne 1 ];
+ then
+ printf "Status: $3\r\n" > exp &&
+ test_cmp exp act
+ fi
}
logdiv() {
@@ -19,26 +42,10 @@ logdiv() {
. "$TEST_DIRECTORY"/t556x_common
-run_backend() {
- REQUEST_METHOD=GET \
- GIT_PROJECT_ROOT="$HTTPD_DOCUMENT_ROOT_PATH" \
- PATH_INFO="$2" \
- git http-backend >act.out 2>act.err
-}
-
-path_info() {
- if test $1 = 0; then
- run_backend "$2"
- else
- test_must_fail run_backend "$2" &&
- echo "fatal: '$2': aliased" >exp.err &&
- test_cmp exp.err act.err
- fi
-}
-
test_expect_success 'http-backend blocks bad PATH_INFO' '
config http.getanyfile true &&
+ REQUEST_METHOD="GET" &&
run_backend 0 /repo.git/HEAD &&
run_backend 1 /repo.git/../HEAD &&
--
1.6.6.62.g67314
^ permalink raw reply related
* Re: immutable tags?
From: Jakub Narebski @ 2009-12-28 22:22 UTC (permalink / raw)
To: Carlos Santana; +Cc: git
In-Reply-To: <92c9564e0912281204h13c6a566w95069023e6909eda@mail.gmail.com>
Carlos Santana <neubyr@gmail.com> writes:
> I would like to know if there is any difference between branches and
> tags. Is it only conceptual - convention to be followed by a developer
> or some technical difference? e.g. : Is it possible to create
> immutable tags so that nothing can be checked in to that 'tagged
> directory'?
There is difference. You can commit only on top of local branches, in
the refs/heads/* namespace (or on top of detached HEAD).
For branches:
$ git checkout A # switches current branch, HEAD points to A
$ git commit # creates new commit on branch A, A advances (changes)
* by default fetch gets all branches
* by default push transfers matching branches
* default refspec is refs/heads/*:refs/remotes/origin/*
For tags:
$ git checkout B # detaches HEAD, HEAD points directly to B^{} commit
# you are on 'no branch'
$ git commit # advances HEAD, tag B does not change
* by default fetch autofollows tags (gets tags that point to commits
you have)
* you need to push tags explicitely
* default refspec is refs/tags/*:refs/tags/* (mirror 1:1)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: immutable tags?
From: Carlos Santana @ 2009-12-28 22:22 UTC (permalink / raw)
To: git; +Cc: davidk
In-Reply-To: <87d41yvlpm.fsf@krank.kagedal.org>
Got it now.
Thank you all for explanation...
-
CS.
On Mon, Dec 28, 2009 at 3:21 PM, David Kågedal <davidk@lysator.liu.se> wrote:
> The following message is a courtesy copy of an article
> that has been posted to gmane.comp.version-control.git as well.
>
> Carlos Santana <neubyr@gmail.com> writes:
>
>> I would like to know if there is any difference between branches and
>> tags. Is it only conceptual - convention to be followed by a developer
>> or some technical difference? e.g. : Is it possible to create
>> immutable tags so that nothing can be checked in to that 'tagged
>> directory'?
>
> You are always in full control of your own repository, and have no
> control over what other people do with their's. So you can't prevent
> other people from changing the tags in their private repos, but you can
> prevent them from propagating these changes back to you, or to a central
> repository you control.
>
> But perhaps there is nothing to worry about. I think the git commands
> won't modify a tag unless you force it.
>
> Also, if you use signed tags, you can be sure that they are not silently
> replaced while still claiming to be tagged by you.
>
> --
> David Kågedal
>
^ permalink raw reply
* Re: Newbie to git
From: Jorge Bastos @ 2009-12-28 22:23 UTC (permalink / raw)
To: Eugene Sajine; +Cc: Junio C Hamano, git
In-Reply-To: <76c5b8580912280851k141bc6cev36df72b1993b8359@mail.gmail.com>
> Your /home/apache/gitprojects is a folder where your git repositories
> are supposed to be placed.
> Your Git repository = your project.
>
> By running a git daemon the way you do - you say that you are going to
> serve all repositories from /home/apache/gitprojects.
>
> Bare repo = repo without working copy - the one which contains only
> history and git objects (imagine it to be only .git folder from normal
> repo) Therefore for bare repos there is a naming convention so they
> have .git extension, while normal repo doesn't. So, myProject.git is
> server based bare repo, while myProject is a local repo.
>
> Finally you have /home/apache/gitprojects/myProject.git
>
> The URL to clone from there will be - should be shown to you by CGIT
> if you have everything correctly set up
> git://192.168.1.206/myProject.git
Lets see if i understood:
my steps:
git init --bare /home/apache/gitbare
cd /home/apache/gitprojects
mkdir project
cd project
git init myproject.git
on gitweb, i see the project names in this format:
"myproject.git/.git"
for example, for the git repo on git.kernel.org, it is shown as:
"git/git.git"
shouldn't it appear in the same way here?
i have:
$projectroot = "/home/apache/gitprojects/project/";
for CGIT, i have:
repo.path=/home/apache/gitprojects/project/myproject.git
but it doesn't show nothing after i click it.
on the other hand, i cannot push changes via remote, after cloned the
repository with:
git clone git://192.168.1.206/project/myproject.git
add some files
git add .
git commit -m "aaaa"
git push --tags "origin" master:master
and get:
error: unpack failed: unpack-objects abnormal exit
To git://192.168.1.206/project/myproject.git
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to
'git://192.168.1.206/project/myproject.git'
Failed
i feel i'm almost there but something is missing here... sorry my
newbienest!
^ permalink raw reply
* file in new branch also shown in master branch?
From: Carlos Santana @ 2009-12-28 22:37 UTC (permalink / raw)
To: git
Hi,
I tried following commands to test branching:
git branch test
git checkout test
echo "Test branch" >> testfile
git status
git checkout master
git add .
git commit
git push
The 'testfile' file shows up in 'master' as well as 'test'. I thought
it would be seen only in test branch, but it is not so. Is it normal
or am I missing something? I was unable to repeat same behavior again,
so I am confused now. Any clues?
-
CS.
^ permalink raw reply
* Re: file in new branch also shown in master branch?
From: David Aguilar @ 2009-12-28 23:25 UTC (permalink / raw)
To: Carlos Santana; +Cc: git
In-Reply-To: <92c9564e0912281437g20fe51f9ta33383791ef20385@mail.gmail.com>
On Mon, Dec 28, 2009 at 04:37:08PM -0600, Carlos Santana wrote:
> Hi,
>
> I tried following commands to test branching:
>
> git branch test
> git checkout test
1. You are now on branch "test"
> echo "Test branch" >> testfile
> git status
2. This does nothing as far as git is concerned.
"testfile" is still unknown to git.
> git checkout master
3. You are now on branch "master"
> git add .
> git commit
4. You just committed "testfile" to branch "master".
Recall #3. This may be where your confusion began.
> The 'testfile' file shows up in 'master' as well as 'test'. I thought
Nope, it only shows up in master.
try:
git checkout test
It is gone.
> or am I missing something? I was unable to repeat same behavior again,
> so I am confused now. Any clues?
These are great references:
http://book.git-scm.com/3_basic_branching_and_merging.html
http://progit.org/book/ch3-0.html
Have fun,
--
David
^ permalink raw reply
* config for merging master to test branch
From: Daniel Convissor @ 2009-12-28 23:38 UTC (permalink / raw)
To: Git Mailing List
Hello:
Here's my workflow...
testing directory (test branch)
[set origin to server repository]
git pull
git branch test
git checkout test
[edit settings files]
git commit ...
working directory (master branch)
[set origin to server repository]
[make changes]
git commit ...
git push origin master
Now, here's the question. I want to go back into the testing directory
and do a "git pull" and have the changes from master automatically merged
into my test branch in one step, without having to do an explicit set of
checkouts and merges. I get the impression there are configuration
settings that allow such to be done. Is my impression correct? If so,
what are the explicit configuration commands, please? Or is there some
command other than "pull" I should be using to do this?
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409
^ permalink raw reply
* RE: Newbie to git
From: Shantanu Pavgi @ 2009-12-28 23:51 UTC (permalink / raw)
To: mysql.jorge@decimal.pt; +Cc: git@vger.kernel.org
In-Reply-To: <4e972734347b7ad47786807a7abe1c0e@192.168.1.222>
Jorge,
I remember having similar problem. I think it is with the user permissions. Check if the 'push-user' has read-write permissions on public repo. Check out '--shared' option while initializing bare repo (git-init --bare) or set appropriate permissions using chown/chmod. Hope this helps..
Thanks,
Shantanu Pavgi.
________________________________________
From: git-owner@vger.kernel.org [git-owner@vger.kernel.org] On Behalf Of Jorge Bastos [mysql.jorge@decimal.pt]
Sent: Monday, December 28, 2009 4:23 PM
To: Eugene Sajine
Cc: Junio C Hamano; git@vger.kernel.org
Subject: Re: Newbie to git
> Your /home/apache/gitprojects is a folder where your git repositories
> are supposed to be placed.
> Your Git repository = your project.
>
> By running a git daemon the way you do - you say that you are going to
> serve all repositories from /home/apache/gitprojects.
>
> Bare repo = repo without working copy - the one which contains only
> history and git objects (imagine it to be only .git folder from normal
> repo) Therefore for bare repos there is a naming convention so they
> have .git extension, while normal repo doesn't. So, myProject.git is
> server based bare repo, while myProject is a local repo.
>
> Finally you have /home/apache/gitprojects/myProject.git
>
> The URL to clone from there will be - should be shown to you by CGIT
> if you have everything correctly set up
> git://192.168.1.206/myProject.git
Lets see if i understood:
my steps:
git init --bare /home/apache/gitbare
cd /home/apache/gitprojects
mkdir project
cd project
git init myproject.git
on gitweb, i see the project names in this format:
"myproject.git/.git"
for example, for the git repo on git.kernel.org, it is shown as:
"git/git.git"
shouldn't it appear in the same way here?
i have:
$projectroot = "/home/apache/gitprojects/project/";
for CGIT, i have:
repo.path=/home/apache/gitprojects/project/myproject.git
but it doesn't show nothing after i click it.
on the other hand, i cannot push changes via remote, after cloned the
repository with:
git clone git://192.168.1.206/project/myproject.git
add some files
git add .
git commit -m "aaaa"
git push --tags "origin" master:master
and get:
error: unpack failed: unpack-objects abnormal exit
To git://192.168.1.206/project/myproject.git
! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to
'git://192.168.1.206/project/myproject.git'
Failed
i feel i'm almost there but something is missing here... sorry my
newbienest!
^ permalink raw reply
* [PATCH 1/2] MinGW: Use pid_t more consequently, introduce uid_t for greater compatibility
From: Sebastian Schuberth @ 2009-12-29 1:18 UTC (permalink / raw)
To: git
MinGW: Use pid_t more consequently, introduce uid_t for greater compatibility
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
---
compat/mingw.h | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index b3d299f..af2f810 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -6,6 +6,7 @@
*/
typedef int pid_t;
+typedef int uid_t;
#define hstrerror strerror
#define S_IFLNK 0120000 /* Symbolic link */
@@ -75,17 +76,17 @@ static inline int symlink(const char *oldpath, const char *newpath)
{ errno = ENOSYS; return -1; }
static inline int fchmod(int fildes, mode_t mode)
{ errno = ENOSYS; return -1; }
-static inline int fork(void)
+static inline pid_t fork(void)
{ errno = ENOSYS; return -1; }
static inline unsigned int alarm(unsigned int seconds)
{ return 0; }
static inline int fsync(int fd)
{ return 0; }
-static inline int getppid(void)
+static inline pid_t getppid(void)
{ return 1; }
static inline void sync(void)
{}
-static inline int getuid()
+static inline uid_t getuid()
{ return 1; }
static inline struct passwd *getpwnam(const char *name)
{ return NULL; }
@@ -117,7 +118,7 @@ static inline int mingw_unlink(const char *pathname)
}
#define unlink mingw_unlink
-static inline int waitpid(pid_t pid, int *status, unsigned options)
+static inline pid_t waitpid(pid_t pid, int *status, unsigned options)
{
if (options == 0)
return _cwait(status, pid, 0);
@@ -158,7 +159,7 @@ int poll(struct pollfd *ufds, unsigned int nfds, int timeout);
struct tm *gmtime_r(const time_t *timep, struct tm *result);
struct tm *localtime_r(const time_t *timep, struct tm *result);
int getpagesize(void); /* defined in MinGW's libgcc.a */
-struct passwd *getpwuid(int uid);
+struct passwd *getpwuid(uid_t uid);
int setitimer(int type, struct itimerval *in, struct itimerval *out);
int sigaction(int sig, struct sigaction *in, struct sigaction *out);
int link(const char *oldpath, const char *newpath);
--
1.6.5.rc2.13.g1be2
^ permalink raw reply related
* [PATCH 2/2] MinGW: Add missing file mode bit defines
From: Sebastian Schuberth @ 2009-12-29 1:19 UTC (permalink / raw)
To: git
MinGW: Add missing file mode bit defines
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
---
compat/mingw.h | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/compat/mingw.h b/compat/mingw.h
index af2f810..885be51 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -12,12 +12,24 @@ typedef int uid_t;
#define S_IFLNK 0120000 /* Symbolic link */
#define S_ISLNK(x) (((x) & S_IFMT) == S_IFLNK)
#define S_ISSOCK(x) 0
+
+#ifndef _STAT_H_
+#define S_IRUSR 0
+#define S_IWUSR 0
+#define S_IXUSR 0
+#define S_IRWXU (S_IRUSR | S_IWUSR | S_IXUSR)
+#endif
#define S_IRGRP 0
#define S_IWGRP 0
#define S_IXGRP 0
-#define S_ISGID 0
+#define S_IRWXG (S_IRGRP | S_IWGRP | S_IXGRP)
#define S_IROTH 0
+#define S_IWOTH 0
#define S_IXOTH 0
+#define S_IRWXO (S_IROTH | S_IWOTH | S_IXOTH)
+#define S_ISUID 0
+#define S_ISGID 0
+#define S_ISVTX 0
#define WIFEXITED(x) 1
#define WIFSIGNALED(x) 0
--
1.6.5.rc2.13.g1be2
^ permalink raw reply related
* Re: [PATCH 0/4] clone: use --progress to mean -v
From: Junio C Hamano @ 2009-12-29 1:30 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: Johannes Schindelin, git, Miklos Vajna, Nicolas Pitre,
Junio C Hamano
In-Reply-To: <be6fef0d0912261927p4aff3ecet5cc26bd6dfc7e1c2@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> On Sat, Dec 26, 2009 at 4:53 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>> On Sat, 26 Dec 2009, Tay Ray Chuan wrote:
>>
>>> This series makes git-clone follow the "argument convention" of
>>> git-pack-objects, where the option --progress is used to force reporting
>>> of reporting. This was previously done with -v/--verbose.
>>
>> No objections from my side, although you might want to advertise more that
>> this is a change in behavior. (Meaning in the release notes)
>
> Indeed, -v/--verbose to force reporting of progress was done sometime
> last year (Thu Oct 9 2008) so there may be scripts/applications
> dependent on this option.
>
> Junio, do you have any advice on this front?
[1/4] sounds like a sane thing to do regardless of the remainder of the
series, as stderr is where we write the progress output anyway. [2/4]
looks trivially correct.
It is unclear what impact [3/4] has. I can read "With this patch,
transport can pay attention to the verbose option given from the end user
and act more verbosely, which was not something they couldn't do before",
but what is the practical difference our existing users would see? IOW,
which transports are silent without this patch even when the user gives -v
from the command line?
And continuing the theme to separate the "verbosity" and the "progress"
into two separate switches, and push them down to the transport layer by
[3/4], [4/4] sounds like a logical conclusion.
I however wonder if it is of lessor impact if we only added --progress
but without removing the progress from -v. Is there a downside?
^ permalink raw reply
* Re: [PATCH 0/4] clone: use --progress to mean -v
From: Tay Ray Chuan @ 2009-12-29 3:06 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Johannes Schindelin, git, Miklos Vajna, Nicolas Pitre
In-Reply-To: <7vljgmpnxj.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, Dec 29, 2009 at 9:30 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tay Ray Chuan <rctay89@gmail.com> writes:
>
>> On Sat, Dec 26, 2009 at 4:53 PM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>> On Sat, 26 Dec 2009, Tay Ray Chuan wrote:
>>>
>>>> This series makes git-clone follow the "argument convention" of
>>>> git-pack-objects, where the option --progress is used to force reporting
>>>> of reporting. This was previously done with -v/--verbose.
>>>
>>> No objections from my side, although you might want to advertise more that
>>> this is a change in behavior. (Meaning in the release notes)
>>
>> Indeed, -v/--verbose to force reporting of progress was done sometime
>> last year (Thu Oct 9 2008) so there may be scripts/applications
>> dependent on this option.
>>
>> Junio, do you have any advice on this front?
>
> [1/4] sounds like a sane thing to do regardless of the remainder of the
> series, as stderr is where we write the progress output anyway. [2/4]
> looks trivially correct.
>
> It is unclear what impact [3/4] has. I can read "With this patch,
> transport can pay attention to the verbose option given from the end user
> and act more verbosely, which was not something they couldn't do before",
> but what is the practical difference our existing users would see? IOW,
> which transports are silent without this patch even when the user gives -v
> from the command line?
I know at least one transport which behaves in this manner (ie. silent
even when -v is supplied to git-clone), and that is the http (via
curl) transport.
> I however wonder if it is of lessor impact if we only added --progress
> but without removing the progress from -v. Is there a downside?
(Just to clarify: progress reporting will be done if stderr is a
terminal - it will be done even if -v or --progress isn't present.
What -v/--progress does is force progress reporting even if stderr is
not a terminal.)
Leaving -v as it is (ie. forcing progress reporting) while adding
--progress would be a "safe" option, as it won't break people's
existing setups (ie. those that depend on -v to force progress
reporting), which the patch series does. I have in mind IDEs/editors
that use this behaviour to monitor progress.
On the other hand, if we decide -v shouldn't imply forcing progress
reporting, then I think this breakable change should be made soon,
when only a small minority of git commands are affected (only one,
git-clone). That way, we don't give users/integrators the impression
that -v forces progress reporting with git commands. They won't get
annoyed when try -v to force progress reporting and find that it isn't
the case.
By the way, I got this "-v doesn't imply forced progress reporting"
rule from Jeff (added to Cc list), who mentioned it some time ago:
Date: Mon, 8 Jun 2009 07:54:31 -0400
From: Jeff King <peff@peff.net>
Subject: Re: [Patch] Prevent cloning over http from spewing
Message-ID: <20090608115431.GC13775@coredump.intra.peff.net>
I was imagining:
- without "-q", show progress if isatty(1).
- with "-q", never show progress
- with "-v", show the "getting pack" and "walk" output we show now;
without "-v", don't show it. "-v" has no impact on the progress
indicator.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Possible bug in 1.6.6 with reset --hard and $GIT_WORK_TREE
From: Fyn Fynn @ 2009-12-29 6:47 UTC (permalink / raw)
To: git
The exact same git reset command that works in 1.6.4, fails to work
under 1.6.6:
$ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
/usr/local/git-1.6.6/bin/git reset --hard
fatal: hard reset requires a work tree
$ GIT_WORK_TREE=$HOME/rawdata/ GIT_DIR=$HOME/rawdata/.git
/usr/local/git-1.6.4/bin/git reset --hard
HEAD is now at 77ec73f...
What gives?
^ permalink raw reply
* [PATCH] Documentation: always respect core.worktree if set
From: Nguyễn Thái Ngọc Duy @ 2009-12-29 7:48 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin, Robin Rosenberg
Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <7viqbrv4pa.fsf@alter.siamese.dyndns.org>
The value of core.worktree in a ".git/config" is honored even when it
differs from the directory that has the ".git" directory as its
subdirectory. This is likely to be a misconfiguration, so warn users
about it. Also, drop the part of the documentation that incorrectly
claimed that we ignore such a misconfigured value.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Documentation/config.txt | 23 +++++++++++++++--------
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 7d10a21..2eb9758 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -297,17 +297,24 @@ false), while all other repositories are assumed to be bare (bare
= true).
core.worktree::
- Set the path to the working tree. The value will not be
- used in combination with repositories found automatically in
- a .git directory (i.e. $GIT_DIR is not set).
+ Set the path to the root of the work tree.
This can be overridden by the GIT_WORK_TREE environment
variable and the '--work-tree' command line option. It can be
- a absolute path or relative path to the directory specified by
- --git-dir or GIT_DIR.
- Note: If --git-dir or GIT_DIR are specified but none of
+ an absolute path or a relative path to the .git directory,
+ either specified by --git-dir or GIT_DIR, or automatically
+ discovered.
+ If --git-dir or GIT_DIR are specified but none of
--work-tree, GIT_WORK_TREE and core.worktree is specified,
- the current working directory is regarded as the top directory
- of your working tree.
+ the current working directory is regarded as the root of the
+ work tree.
++
+Note that this variable is honored even when set in a configuration
+file in a ".git" subdirectory of a directory, and its value differs
+from the latter directory (e.g. "/path/to/.git/config" has
+core.worktree set to "/different/path"), which is most likely a
+misconfiguration. Running git commands in "/path/to" directory will
+still use "/different/path" as the root of the work tree and can cause
+great confusion to the users.
core.logAllRefUpdates::
Enable the reflog. Updates to a ref <ref> is logged to the file
--
1.6.5.2.216.g9c1ec
^ permalink raw reply related
* Re: [PATCH] Documentation: commit: explain the non-meaning of S-o-b
From: Junio C Hamano @ 2009-12-29 7:54 UTC (permalink / raw)
To: Jan Krüger; +Cc: Git ML
In-Reply-To: <20091228194001.7b4c68f4@perceptron>
Jan Krüger <jk@jk.gs> writes:
> In the manpage for git commit, the option --signoff is mentioned but
> there is no explanation of what it actually means. Add a brief hint that
> S-o-b doesn't have a pre-defined meaning.
The commands am, cherry-pick, commit, format-patch, and revert all share
the "sign-off" and they more or less deliberately refused to define what
it means to sign-off a patch; as your patch says, it is up to the project
policy.
config.txt gives a description for format.signoff option that is too
specific to git and the kernel, which I think is a mistake given the much
wider audience we have these days.
How similar should the document for the "sign-off" options to these
commands be? I am wondering if we should have the same description copied
and pasted to all of them, or avoid repeating ourselves and instead have
them refer to a central place, perhaps somewhere in the Tutorial or the
Workflow document.
> Signed-off-by: Jan Krüger <jk@jk.gs>
> ---
> Semi-resend. Nobody commented on this when I first sent it in early
> December, so here it is again, with a slightly more verbose
> explanation. The repetition is intentional.
>
> Documentation/git-commit.txt | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
> index d227cec..cae510b 100644
> --- a/Documentation/git-commit.txt
> +++ b/Documentation/git-commit.txt
> @@ -114,7 +114,10 @@ OPTIONS
> -s::
> --signoff::
> Add Signed-off-by line by the committer at the end of the commit
> - log message.
> + log message. This line has no inherent meaning; it is up to the
> + potential recipient of the commit to decide what it stands for.
> + It is typically understood as an assurance by the committer that
> + the commit conforms to the receiving project's commit guidelines.
>
> -n::
> --no-verify::
> --
> 1.6.5.3.171.ge36e
^ 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