* [PATCHv7 4/5] gitweb: parse parent..current syntax from PATH_INFO
From: Giuseppe Bilotta @ 2008-10-21 19:34 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224617694-29277-4-git-send-email-giuseppe.bilotta@gmail.com>
This patch makes it possible to use an URL such as
project/action/somebranch..otherbranch:/filename to get a diff between
different version of a file. Paths like
project/action/somebranch:/somefile..otherbranch:/otherfile are parsed
as well.
All '*diff' actions and in general actions that use $hash_parent[_base]
and $file_parent (e.g. 'shortlog') can now get all of their parameters
from PATH_INFO
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 36 ++++++++++++++++++++++++++++++++++--
1 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 9da547d..59449de 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -549,7 +549,12 @@ sub evaluate_path_info {
'history',
);
- my ($refname, $pathname) = split(/:/, $path_info, 2);
+ # we want to catch
+ # [$hash_parent_base[:$file_parent]..]$hash_parent[:$file_name]
+ my ($parentrefname, $parentpathname, $refname, $pathname) =
+ ($path_info =~ /^(?:(.+?)(?::(.+))?\.\.)?(.+?)(?::(.+))?$/);
+
+ # first, analyze the 'current' part
if (defined $pathname) {
# we got "branch:filename" or "branch:dir/"
# we could use git_get_type(branch:pathname), but:
@@ -564,7 +569,13 @@ sub evaluate_path_info {
$input_params{'action'} ||= "tree";
$pathname =~ s,/$,,;
} else {
- $input_params{'action'} ||= "blob_plain";
+ # the default action depends on whether we had parent info
+ # or not
+ if ($parentrefname) {
+ $input_params{'action'} ||= "blobdiff_plain";
+ } else {
+ $input_params{'action'} ||= "blob_plain";
+ }
}
$input_params{'hash_base'} ||= $refname;
$input_params{'file_name'} ||= $pathname;
@@ -584,6 +595,27 @@ sub evaluate_path_info {
$input_params{'hash'} ||= $refname;
}
}
+
+ # next, handle the 'parent' part, if present
+ if (defined $parentrefname) {
+ # a missing pathspec defaults to the 'current' filename, allowing e.g.
+ # someproject/blobdiff/oldrev..newrev:/filename
+ if ($parentpathname) {
+ $parentpathname =~ s,^/+,,;
+ $parentpathname =~ s,/$,,;
+ $input_params{'file_parent'} ||= $parentpathname;
+ } else {
+ $input_params{'file_parent'} ||= $input_params{'file_name'};
+ }
+ # we assume that hash_parent_base is wanted if a path was specified,
+ # or if the action wants hash_base instead of hash
+ if (defined $input_params{'file_parent'} ||
+ grep { $_ eq $input_params{'action'} } @wants_base) {
+ $input_params{'hash_parent_base'} ||= $parentrefname;
+ } else {
+ $input_params{'hash_parent'} ||= $parentrefname;
+ }
+ }
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATCHv7 3/5] gitweb: use_pathinfo filenames start with /
From: Giuseppe Bilotta @ 2008-10-21 19:34 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224617694-29277-3-git-send-email-giuseppe.bilotta@gmail.com>
Generate PATH_INFO URLs in the form project/action/hash_base:/filename
rather than project/action/hash_base:filename (the latter form is still
accepted in input).
This minimal change allows relative navigation to work properly when
viewing HTML files in raw ('blob_plain') mode.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 27587aa..9da547d 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -734,7 +734,7 @@ sub href (%) {
# try to put as many parameters as possible in PATH_INFO:
# - project name
# - action
- # - hash or hash_base:filename
+ # - hash or hash_base:/filename
# When the script is the root DirectoryIndex for the domain,
# $href here would be something like http://gitweb.example.com/
@@ -753,11 +753,11 @@ sub href (%) {
delete $params{'action'};
}
- # Finally, we put either hash_base:file_name or hash
+ # Finally, we put either hash_base:/file_name or hash
if (defined $params{'hash_base'}) {
$href .= "/".esc_url($params{'hash_base'});
if (defined $params{'file_name'}) {
- $href .= ":".esc_url($params{'file_name'});
+ $href .= ":/".esc_url($params{'file_name'});
delete $params{'file_name'};
}
delete $params{'hash'};
--
1.5.6.5
^ permalink raw reply related
* [PATCHv7 1/5] gitweb: parse project/action/hash_base:filename PATH_INFO
From: Giuseppe Bilotta @ 2008-10-21 19:34 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224617694-29277-1-git-send-email-giuseppe.bilotta@gmail.com>
This patch enables gitweb to parse URLs with more information embedded
in PATH_INFO, reducing the need for CGI parameters. The typical gitweb
path is now $project/$action/$hash_base:$file_name or
$project/$action/$hash
This is mostly backwards compatible with the old-style gitweb paths,
$project/$branch[:$filename], except when it was used to access a branch
whose name matches a gitweb action.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 46 +++++++++++++++++++++++++++++++++++++++-------
1 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 98f1bfa..1f847bb 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -534,23 +534,55 @@ sub evaluate_path_info {
return if $input_params{'action'};
$path_info =~ s,^\Q$project\E/*,,;
+ # next, check if we have an action
+ my $action = $path_info;
+ $action =~ s,/.*$,,;
+ if (exists $actions{$action}) {
+ $path_info =~ s,^$action/*,,;
+ $input_params{'action'} = $action;
+ }
+
+ # list of actions that want hash_base instead of hash, but can have no
+ # pathname (f) parameter
+ my @wants_base = (
+ 'tree',
+ 'history',
+ );
+
my ($refname, $pathname) = split(/:/, $path_info, 2);
if (defined $pathname) {
- # we got "project.git/branch:filename" or "project.git/branch:dir/"
- # we could use git_get_type(branch:pathname), but it needs $git_dir
+ # we got "branch:filename" or "branch:dir/"
+ # we could use git_get_type(branch:pathname), but:
+ # - it needs $git_dir
+ # - it does a git() call
+ # - the convention of terminating directories with a slash
+ # makes it superfluous
+ # - embedding the action in the PATH_INFO would make it even
+ # more superfluous
$pathname =~ s,^/+,,;
if (!$pathname || substr($pathname, -1) eq "/") {
- $input_params{'action'} = "tree";
+ $input_params{'action'} ||= "tree";
$pathname =~ s,/$,,;
} else {
- $input_params{'action'} = "blob_plain";
+ $input_params{'action'} ||= "blob_plain";
}
$input_params{'hash_base'} ||= $refname;
$input_params{'file_name'} ||= $pathname;
} elsif (defined $refname) {
- # we got "project.git/branch"
- $input_params{'action'} = "shortlog";
- $input_params{'hash'} ||= $refname;
+ # we got "branch". In this case we have to choose if we have to
+ # set hash or hash_base.
+ #
+ # Most of the actions without a pathname only want hash to be
+ # set, except for the ones specified in @wants_base that want
+ # hash_base instead. It should also be noted that hand-crafted
+ # links having 'history' as an action and no pathname or hash
+ # set will fail, but that happens regardless of PATH_INFO.
+ $input_params{'action'} ||= "shortlog";
+ if (grep { $_ eq $input_params{'action'} } @wants_base) {
+ $input_params{'hash_base'} ||= $refname;
+ } else {
+ $input_params{'hash'} ||= $refname;
+ }
}
}
evaluate_path_info();
--
1.5.6.5
^ permalink raw reply related
* [PATCHv7 2/5] gitweb: generate project/action/hash URLs
From: Giuseppe Bilotta @ 2008-10-21 19:34 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1224617694-29277-2-git-send-email-giuseppe.bilotta@gmail.com>
When generating path info URLs, reduce the number of CGI parameters by
embedding action and hash_parent:filename or hash in the path.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 33 ++++++++++++++++++++++++++++++---
1 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 1f847bb..27587aa 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -731,14 +731,41 @@ sub href (%) {
my ($use_pathinfo) = gitweb_check_feature('pathinfo');
if ($use_pathinfo) {
- # use PATH_INFO for project name
+ # try to put as many parameters as possible in PATH_INFO:
+ # - project name
+ # - action
+ # - hash or hash_base:filename
+
+ # When the script is the root DirectoryIndex for the domain,
+ # $href here would be something like http://gitweb.example.com/
+ # Thus, we strip any trailing / from $href, to spare us double
+ # slashes in the final URL
+ $href =~ s,/$,,;
+
+ # Then add the project name, if present
$href .= "/".esc_url($params{'project'}) if defined $params{'project'};
delete $params{'project'};
- # Summary just uses the project path URL
- if (defined $params{'action'} && $params{'action'} eq 'summary') {
+ # Summary just uses the project path URL, any other action is
+ # added to the URL
+ if (defined $params{'action'}) {
+ $href .= "/".esc_url($params{'action'}) unless $params{'action'} eq 'summary';
delete $params{'action'};
}
+
+ # Finally, we put either hash_base:file_name or hash
+ if (defined $params{'hash_base'}) {
+ $href .= "/".esc_url($params{'hash_base'});
+ if (defined $params{'file_name'}) {
+ $href .= ":".esc_url($params{'file_name'});
+ delete $params{'file_name'};
+ }
+ delete $params{'hash'};
+ delete $params{'hash_base'};
+ } elsif (defined $params{'hash'}) {
+ $href .= "/".esc_url($params{'hash'});
+ delete $params{'hash'};
+ }
}
# now encode the parameters explicitly
--
1.5.6.5
^ permalink raw reply related
* [PATCHv7 0/5] gitweb: PATH_INFO enhancement
From: Giuseppe Bilotta @ 2008-10-21 19:34 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
Sevent attempt for my gitweb PATH_INFO patchset, whose purpose is to
reduce the use of CGI parameters by embedding as many parameters as
possible in the URL path itself, provided the pathinfo feature is
enabled.
The new typical gitweb URL is therefore in the form
$project/$action/$parent:$file..$hash:$file
(with useless parts stripped). Backwards compatibility for old-style
$project/$hash[:$file] URLs is kept, as long as $hash is not a refname
whose name happens to match a git action.
The main implementation is provided by paired patches (#1#2, #4#5)
that implement parsing and generation of the new style URLs.
Patch #3 is a minor improvement to the URL syntax that allows web
sites to be properly browsable in raw mode.
The patchset depends on my previous input parameter handling patch
currently waiting in 'next'. This resend fixes some mainly aesthetical
issues spotted by Jakub
Giuseppe Bilotta (5):
gitweb: parse project/action/hash_base:filename PATH_INFO
gitweb: generate project/action/hash URLs
gitweb: use_pathinfo filenames start with /
gitweb: parse parent..current syntax from PATH_INFO
gitweb: generate parent..current URLs
gitweb/gitweb.perl | 133 +++++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 122 insertions(+), 11 deletions(-)
^ permalink raw reply
* git 1.6.0.2 make test fails at t1301 under mac os x 10.4.
From: Fergus McMenemie @ 2008-10-21 18:32 UTC (permalink / raw)
To: git
Hi,
Hoping for a quick pointer. I compiled git 1.6.0.2 on three
macs. Works fine on two fails on one. It only fails at test
t1301-shared-repo.sh all other tests pass.
Imac 2.16GHz Intel Core 2 Duo running MacOS X 10.4.11 - OK
MacMini 1.5Ghz PowerPC G4 running MacOS X 10.4.11 - Duff
Powerbook 1Ghz PowerPC G4 running MacOX X 10.5.5 - OK
All disks are formatted "Journaled HFS+". I have the same
version of gcc and the development environment on both the
tiger machines. Here is a trace from the machine and test
that fails:-
>fergus:bash -x t1301-shared-repo.sh -d -v -i
>+ test_description=Test shared repository initialization
>+ . ./test-lib.sh
>++ ORIGINAL_TERM=xterm-color
>++ LANG=C
>++ LC_ALL=C
>++ PAGER=cat
>++ TZ=UTC
>++ TERM=dumb
>++ export LANG LC_ALL PAGER TERM TZ
>++ EDITOR=:
>++ VISUAL=:
>++ unset GIT_EDITOR
>++ unset AUTHOR_DATE
>++ unset AUTHOR_EMAIL
>++ unset AUTHOR_NAME
>++ unset COMMIT_AUTHOR_EMAIL
>++ unset COMMIT_AUTHOR_NAME
>++ unset EMAIL
>++ unset GIT_ALTERNATE_OBJECT_DIRECTORIES
>++ unset GIT_AUTHOR_DATE
>++ GIT_AUTHOR_EMAIL=author@example.com
>++ GIT_AUTHOR_NAME=A U Thor
>++ unset GIT_COMMITTER_DATE
>++ GIT_COMMITTER_EMAIL=committer@example.com
>++ GIT_COMMITTER_NAME=C O Mitter
>++ unset GIT_DIFF_OPTS
>++ unset GIT_DIR
>++ unset GIT_WORK_TREE
>++ unset GIT_EXTERNAL_DIFF
>++ unset GIT_INDEX_FILE
>++ unset GIT_OBJECT_DIRECTORY
>++ unset GIT_CEILING_DIRECTORIES
>++ unset SHA1_FILE_DIRECTORIES
>++ unset SHA1_FILE_DIRECTORY
>++ GIT_MERGE_VERBOSITY=5
>++ export GIT_MERGE_VERBOSITY
>++ export GIT_AUTHOR_EMAIL GIT_AUTHOR_NAME
>++ export GIT_COMMITTER_EMAIL GIT_COMMITTER_NAME
>++ export EDITOR VISUAL
>++ GIT_TEST_CMP=diff -u
>++ unset CDPATH
>+++ echo
>+++ tr '[A-Z]' '[a-z]'
>++ '[' xxterm-color '!=' xdumb ']'
>++ TERM=xterm-color
>++ export TERM
>++ '[' -t 1 ']'
>++ tput bold
>++ tput setaf 1
>++ tput sgr0
>++ color=t
>++ test 3 -ne 0
>++ debug=t
>++ shift
>++ test 2 -ne 0
>++ verbose=t
>++ shift
>++ test 1 -ne 0
>++ immediate=t
>++ shift
>++ test 0 -ne 0
>++ test -n t
>++ test 'Test shared repository initialization' '!=' ''
>++ test '' = t
>++ exec
>++ test t = t
>++ exec
>++ test_failure=0
>++ test_count=0
>++ test_fixed=0
>++ test_broken=0
>++ test_success=0
>++ trap die exit
>+++ pwd
>++ TEST_DIRECTORY=/usr/local/packages/git-1.6.0.2/t
>++ PATH=/usr/local/packages/git-1.6.0.2/t/..:/usr/local/bin:/usr/local/pgsql/bin:/bin:/sbin:/usr/bin:/usr/local/bin:/usr/sbin:/Volumes/TechmorePB/fergus/Current\ Contract/cwid-fixup/rollitts
>+++ pwd
>++ GIT_EXEC_PATH=/usr/local/packages/git-1.6.0.2/t/..
>+++ pwd
>++ GIT_TEMPLATE_DIR=/usr/local/packages/git-1.6.0.2/t/../templates/blt
>++ unset GIT_CONFIG
>++ unset GIT_CONFIG_LOCAL
>++ GIT_CONFIG_NOSYSTEM=1
>++ GIT_CONFIG_NOGLOBAL=1
>++ export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG_NOSYSTEM GIT_CONFIG_NOGLOBAL
>+++ pwd
>+++ pwd
>++ GITPERLLIB=/usr/local/packages/git-1.6.0.2/t/../perl/blib/lib:/usr/local/packages/git-1.6.0.2/t/../perl/blib/arch/auto/Git
>++ export GITPERLLIB
>++ test -d ../templates/blt
>++ test -x ../test-chmtime
>++ . ../GIT-BUILD-OPTIONS
>+++ SHELL_PATH=/bin/sh
>+++ TAR=tar
>++ test=trash directory
>++ rm -fr 'trash directory'
>++ test_create_repo 'trash directory'
>++ test 1 = 1
>+++ pwd
>++ owd=/usr/local/packages/git-1.6.0.2/t
>++ repo=trash directory
>++ mkdir 'trash directory'
>++ cd 'trash directory'
>++ /usr/local/packages/git-1.6.0.2/t/../git init --template=/usr/local/packages/git-1.6.0.2/t/../templates/blt/
>Initialized empty Git repository in /usr/local/packages/git-1.6.0.2/t/trash directory/.git/
>++ mv .git/hooks .git/hooks-disabled
>++ cd /usr/local/packages/git-1.6.0.2/t
>++ cd -P 'trash directory'
>+++ expr ./t1301-shared-repo.sh : '.*/\(t[0-9]*\)-[^/]*$'
>++ this_test=t1301
>+ test_expect_success 'shared = 0400 (faulty permission u-w)' '
> mkdir sub && (
> cd sub && git init --shared=0400
> )
> ret="$?"
> rm -rf sub
> test $ret != "0"
>'
>+ test 2 = 2
>+ test_skip 'shared = 0400 (faulty permission u-w)' '
> mkdir sub && (
> cd sub && git init --shared=0400
> )
> ret="$?"
> rm -rf sub
> test $ret != "0"
>'
>++ expr ./t1301-shared-repo.sh : '.*/\(t[0-9]*\)-[^/]*$'
>+ this_test=t1301
>++ expr 0 + 1
>+ this_test=t1301.1
>+ to_skip=
>+ false
>+ say 'expecting success:
> mkdir sub && (
> cd sub && git init --shared=0400
> )
> ret="$?"
> rm -rf sub
> test $ret != "0"
>'
>+ say_color info 'expecting success:
> mkdir sub && (
> cd sub && git init --shared=0400
> )
> ret="$?"
> rm -rf sub
> test $ret != "0"
>'
>+ TERM=xterm-color
>+ export TERM
>+ tput setaf 3
>+ shift
>+ echo '* expecting success:
> mkdir sub && (
> cd sub && git init --shared=0400
> )
> ret="$?"
> rm -rf sub
> test $ret != "0"
>'
>* expecting success:
> mkdir sub && (
> cd sub && git init --shared=0400
> )
> ret="$?"
> rm -rf sub
> test $ret != "0"
>
>+ tput sgr0
>+ test_run_ '
> mkdir sub && (
> cd sub && git init --shared=0400
> )
> ret="$?"
> rm -rf sub
> test $ret != "0"
>'
>+ eval '
> mkdir sub && (
> cd sub && git init --shared=0400
> )
> ret="$?"
> rm -rf sub
> test $ret != "0"
>'
>++ mkdir sub
>++ cd sub
>++ git init --shared=0400
>fatal: Problem with core.sharedRepository filemode value (0400).
>The owner of files must always have read and write permissions.
>++ ret=128
>++ rm -rf sub
>++ test 128 '!=' 0
>+ eval_ret=0
>+ return 0
>+ '[' 0 = 0 -a 0 = 0 ']'
>+ test_ok_ 'shared = 0400 (faulty permission u-w)'
>++ expr 0 + 1
>+ test_count=1
>++ expr 0 + 1
>+ test_success=1
>+ say_color '' ' ok 1: shared = 0400 (faulty permission u-w)'
>+ TERM=xterm-color
>+ export TERM
>+ test -n ''
>+ shift
>+ echo '* ok 1: shared = 0400 (faulty permission u-w)'
>* ok 1: shared = 0400 (faulty permission u-w)
>+ tput sgr0
>+ echo ''
>
>+ test_expect_success 'shared=1 does not clear bits preset by umask 002' '
> mkdir sub && (
> cd sub &&
> umask $u &&
> git init --shared=1 &&
> test 1 = "$(git config core.sharedrepository)"
> ) &&
> actual=$(ls -l sub/.git/HEAD)
> case "$actual" in
> -rw-rw-r--*)
> : happy
> ;;
> *)
> echo Oops, .git/HEAD is not 0664 but $actual
> false
> ;;
> esac
> '
>+ test 2 = 2
>+ test_skip 'shared=1 does not clear bits preset by umask 002' '
> mkdir sub && (
> cd sub &&
> umask $u &&
> git init --shared=1 &&
> test 1 = "$(git config core.sharedrepository)"
> ) &&
> actual=$(ls -l sub/.git/HEAD)
> case "$actual" in
> -rw-rw-r--*)
> : happy
> ;;
> *)
> echo Oops, .git/HEAD is not 0664 but $actual
> false
> ;;
> esac
> '
>++ expr ./t1301-shared-repo.sh : '.*/\(t[0-9]*\)-[^/]*$'
>+ this_test=t1301
>++ expr 1 + 1
>+ this_test=t1301.2
>+ to_skip=
>+ false
>+ say 'expecting success:
> mkdir sub && (
> cd sub &&
> umask $u &&
> git init --shared=1 &&
> test 1 = "$(git config core.sharedrepository)"
> ) &&
> actual=$(ls -l sub/.git/HEAD)
> case "$actual" in
> -rw-rw-r--*)
> : happy
> ;;
> *)
> echo Oops, .git/HEAD is not 0664 but $actual
> false
> ;;
> esac
> '
>+ say_color info 'expecting success:
> mkdir sub && (
> cd sub &&
> umask $u &&
> git init --shared=1 &&
> test 1 = "$(git config core.sharedrepository)"
> ) &&
> actual=$(ls -l sub/.git/HEAD)
> case "$actual" in
> -rw-rw-r--*)
> : happy
> ;;
> *)
> echo Oops, .git/HEAD is not 0664 but $actual
> false
> ;;
> esac
> '
>+ TERM=xterm-color
>+ export TERM
>+ tput setaf 3
>+ shift
>+ echo '* expecting success:
> mkdir sub && (
> cd sub &&
> umask $u &&
> git init --shared=1 &&
> test 1 = "$(git config core.sharedrepository)"
> ) &&
> actual=$(ls -l sub/.git/HEAD)
> case "$actual" in
> -rw-rw-r--*)
> : happy
> ;;
> *)
> echo Oops, .git/HEAD is not 0664 but $actual
> false
> ;;
> esac
> '
>* expecting success:
> mkdir sub && (
> cd sub &&
> umask $u &&
> git init --shared=1 &&
> test 1 = "$(git config core.sharedrepository)"
> ) &&
> actual=$(ls -l sub/.git/HEAD)
> case "$actual" in
> -rw-rw-r--*)
> : happy
> ;;
> *)
> echo Oops, .git/HEAD is not 0664 but $actual
> false
> ;;
> esac
>
>+ tput sgr0
>+ test_run_ '
> mkdir sub && (
> cd sub &&
> umask $u &&
> git init --shared=1 &&
> test 1 = "$(git config core.sharedrepository)"
> ) &&
> actual=$(ls -l sub/.git/HEAD)
> case "$actual" in
> -rw-rw-r--*)
> : happy
> ;;
> *)
> echo Oops, .git/HEAD is not 0664 but $actual
> false
> ;;
> esac
> '
>+ eval '
> mkdir sub && (
> cd sub &&
> umask $u &&
> git init --shared=1 &&
> test 1 = "$(git config core.sharedrepository)"
> ) &&
> actual=$(ls -l sub/.git/HEAD)
> case "$actual" in
> -rw-rw-r--*)
> : happy
> ;;
> *)
> echo Oops, .git/HEAD is not 0664 but $actual
> false
> ;;
> esac
> '
>++ mkdir sub
>++ cd sub
>++ umask 002
>++ git init --shared=1
>fatal: Could not make /usr/local/packages/git-1.6.0.2/t/trash directory/sub/.git/refs writable by group
>
>++ echo Oops, .git/HEAD is not 0664 but
>Oops, .git/HEAD is not 0664 but
>++ false
>+ eval_ret=1
>+ return 0
>+ '[' 0 = 0 -a 1 = 0 ']'
>+ test_failure_ 'shared=1 does not clear bits preset by umask 002' '
> mkdir sub && (
> cd sub &&
> umask $u &&
> git init --shared=1 &&
> test 1 = "$(git config core.sharedrepository)"
> ) &&
> actual=$(ls -l sub/.git/HEAD)
> case "$actual" in
> -rw-rw-r--*)
> : happy
> ;;
> *)
> echo Oops, .git/HEAD is not 0664 but $actual
> false
> ;;
> esac
> '
>++ expr 1 + 1
>+ test_count=2
>++ expr 0 + 1
>+ test_failure=1
>+ say_color error 'FAIL 2: shared=1 does not clear bits preset by umask 002'
>+ TERM=xterm-color
>+ export TERM
>+ tput bold
>+ tput setaf 1
>+ shift
>+ echo '* FAIL 2: shared=1 does not clear bits preset by umask 002'
>* FAIL 2: shared=1 does not clear bits preset by umask 002
>+ tput sgr0
>+ shift
>+ echo '
> mkdir sub && (
> cd sub &&
> umask $u &&
> git init --shared=1 &&
> test 1 = "$(git config core.sharedrepository)"
> ) &&
> actual=$(ls -l sub/.git/HEAD)
> case "$actual" in
> -rw-rw-r--*)
> : happy
> ;;
> *)
> echo Oops, .git/HEAD is not 0664 but $actual
> false
> ;;
> esac
> '
>+ sed -e 's/^/ /'
>
> mkdir sub && (
> cd sub &&
> umask $u &&
> git init --shared=1 &&
> test 1 = "$(git config core.sharedrepository)"
> ) &&
> actual=$(ls -l sub/.git/HEAD)
> case "$actual" in
> -rw-rw-r--*)
> : happy
> ;;
> *)
> echo Oops, .git/HEAD is not 0664 but $actual
> false
> ;;
> esac
>
>+ test t = ''
>+ trap - exit
>+ exit 1
>fergus:
Doing this manually I get:-
fergus:mkdir sub
fergus:cd sub
fergus:../../git init --shared=0400
fatal: Problem with core.sharedRepository filemode value (0400).
The owner of files must always have read and write permissions.
fergus:echo $?
128
fergus:ls -al
total 0
drwxr-xr-x 3 fergus wheel 102 Oct 21 18:24 .
drwxr-xr-x 333 fergus wheel 11322 Oct 21 18:23 ..
drwxr-xr-x 2 fergus wheel 68 Oct 21 18:24 sub
fergus:ls -al sub
total 0
drwxr-xr-x 2 fergus wheel 68 Oct 21 18:24 .
drwxr-xr-x 3 fergus wheel 102 Oct 21 18:24 ..
Any ideas where is going on? I have the same version of gcc
and the development environment on both the tiger machines.
--
===============================================================
Fergus McMenemie Email:fergus@twig.me.uk
Techmore Ltd Phone:(UK) 07721 376021
Unix/Mac/Intranets Analyst Programmer
===============================================================
^ permalink raw reply
* Re: [EGIT PATCH] git property page for project properties.
From: Robin Rosenberg @ 2008-10-21 19:13 UTC (permalink / raw)
To: tomi.pakarinen; +Cc: spearce, git
In-Reply-To: <f299b4f30810211109q7f2919f2r1d5cd8faf0048154@mail.gmail.com>
tisdagen den 21 oktober 2008 20.09.13 skrev Tomi Pakarinen:
> That is ok. I just didn't notice that method before. But, what if
> someone wants localize this plugin, he'll propably have to explode
> this back to switch statement.
No, we'd localize getDescription().
-- robin
^ permalink raw reply
* Re: [PATHv2 6/8] gitweb: retrieve snapshot format from PATH_INFO
From: Junio C Hamano @ 2008-10-21 19:09 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: Jakub Narebski, git, Petr Baudis, Junio C Hamano
In-Reply-To: <cb7bb73a0810211136n452ac8bdp7814ff09749b3142@mail.gmail.com>
"Giuseppe Bilotta" <giuseppe.bilotta@gmail.com> writes:
>> But I'd rather have this patch series to be in separate thread...
>
> Yes, a posteriori I think it's better too. I'll resend the 5 path_info
> patches with the minor stylistic corrections you suggested, and send
> these 3 separately.
I've only been watching from the sidelines, but the discussion seemed
sensible. With the resend with Acks I think they are already 'next'
material.
Thanks, both of you.
^ permalink raw reply
* Re: gitk: Turn short SHA1 names into links too
From: Junio C Hamano @ 2008-10-21 19:09 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <18685.4652.287143.717452@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Linus Torvalds writes:
>
>> And the thing I wanted to work was to have the abbreviated SHA1's that
>> have started to get more common in the kernel commit logs work as links in
>> gitk too, just the way a full 40-character SHA1 link works.
>
> I just pushed out a commit to gitk that makes this work, and fixes the
> other bugs you mentioned.
FWIW, pulled and pushed out. Thanks.
^ permalink raw reply
* Re: [PATHv2 6/8] gitweb: retrieve snapshot format from PATH_INFO
From: Giuseppe Bilotta @ 2008-10-21 18:36 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200810211844.35714.jnareb@gmail.com>
On Tue, Oct 21, 2008 at 6:44 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> I like the idea behind this patch, to enable to use path_info for as
> much gitweb parameters as possible. After this patch series the only
> parameters which wouldn't be possible to represent in path_info would
> be:
> * @extra_options ('opt') multi-valued parameter, used to pass
> thinks like '--no-merges', which cannot be fit in the "simplified"
> list-like (as opposed to hash-like query string) path_info URL.
> * $searchtype ('st') and $searchtext ('s') etc. parameters, which
> are generated by HTML form, and are naturally generated in query
> string format.
> * $page ('pg') parameter, which could theoretically be added as last
> part of path_info URL, for example $project/next/2/... if not for
> pesky $project/history/next:/Documentation/2/ where you cannot be
> sure that having /<number>/ at the end is rare.
> * $order ('o') parameter, which would be hard to fit in path_info,
> with its limitation of parameters being specified by position.
> Or even next to impossible.
> * 'by_tag'...
>
> But I'd rather have this patch series to be in separate thread...
Yes, a posteriori I think it's better too. I'll resend the 5 path_info
patches with the minor stylistic corrections you suggested, and send
these 3 separately.
> On Sun, 19 Oct 2008, Giuseppe Bilotta wrote:
>
>> We parse requests for $project/snapshot/$head.$sfx as equivalent to
>> $project/snapshot/$head?sf=$sfx, where $sfx is any of the known
>> (although not necessarily supported) snapshot formats (or its default
>> suffix).
>>
>> The filename for the resulting package preserves the requested
>> extensions (so asking for a .tgz gives a .tgz, and asking for a .tar.gz
>> gives a .tar.gz), although for obvious reasons it doesn't preserve the
>> basename (git/snapshot/next.tgz returns a file names git-next.tgz).
>
> That is a bit of difference from sf=<format> in CGI query string, where
> <format> is always a name of a format (for example 'tgz' or 'tbz2'),
> and actual suffix is defined in %known_snapshot_formats (for example
> '.tar.gz' and '.tar.bz2' respectively). Now you can specify snapshot
> format either either by its name, for example 'tgz' (which is simple
> lookup in hash) which result in proposed filename with '.tgz' suffix,
> or you can specify suffix, for example 'tar.gz' (which requires
> searching through all hash) which result in proposed filename with
> '.tar.gz' suffix.
>
> This is a bit of inconsistency; to be consistent with how we handle
> 'sf' CGI parameter we would translate 'tgz' $sfx into 'tar.gz' in
> snapshot filename. This would also cover currently purely theoretical
> case when different snapshot formats (for example 'tgz' and 'tgz9')
> would use the same snapshot suffix (extension), but differ for example
> in parameters passed to compressor (for example '-9' or '--best' in
> the 'tgz9' case).
>
> On the other hand one would expect that when URL which looks like
> URL to snapshot ends with '.$sfx', then filename for snapshot would
> also end with '.$sfx'.
>
> This certainly requires some further thoughts.
What I decided was to set gitweb to always produce links with the
suffix (.e.g .tar.gz), but I saw no particular reason not to accept
the shorter version which is (1) commonly used as a suffix as well and
(2) happens to be the actual format key used by gitweb.
A different, possibly cleaner approach, but a more extensive change,
would be to have each format describe a list of suffixes, defaulting
to the first one on creation by identifying all of them. This is more
invasive because all of the uses of {'suffix'} have to be replaced
with {'suffix'}[0], or something like that (maybe we could add a
separate key 'other_suffixes' instead?)
>> This introduces a potential case for ambiguity if a project has a head
>> that ends with a snapshot-like suffix (.zip, .tgz, .tar.gz, etc) and the
>> sf CGI parameter is not present; however, gitweb only produces URLs with
>> the sf parameter, so this is only a potential issue for hand-coded URLs
>> for extremely unusual project.
>
> I think you wanted to say here "_currently_ produces URLs with the 'sf'
> parameter" as the next patch in series changes this.
Ah yes, good point.
>> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
>> ---
>>
>> I had second thoughts on this. Now we always look for the snapshot extension if
>> the sf CGI parameter is missing, even if the project has a head that matches
>> the full pseudo-refname $head.$sfx.
>>
>> The reason for this is that (1) there is no ambiguity for gitweb-generated
>> URLs (2) the only URLs that could fail are hand-made URLs for extremely
>> unusual projects and (3) it allows us to set gitweb up to generate
>> (unambiguous) URLs without the sf CGI parameter.
>
> This is also simpler and cheaper solution.
That, too 8-)
>> This also means that I can add 3 patches to the series, instead of just one:
>> * patch #6 that parses the new format
>> * patch #7 that generates the new URLs
>> * patch #8 for some code refactoring
>
> Now, I haven't yet read the last patch in series, so I don't know if
> it is independent refactoring, making sense even before patches named
> #6 and #7 here, or is it connected with searching for snapshot format
> by suffix it uses. If the former, it should be done upfront, as it
> shouldn't need discussion, and being easier to be accepted into git.git.
> If the latter, then it should probably be folded (squashed) into #6,
> first patch in the series.
In fact, patch #8 can be written independently of the other too, and
would provide a significant speed benefit for generation of pages with
lots of 'snapshot' links: what it does is just to make the 'supported
formats' array global, preparing it only once instead of re-preparing
it every time a snapshot link is created.
>> gitweb/gitweb.perl | 34 ++++++++++++++++++++++++++++++++++
>> 1 files changed, 34 insertions(+), 0 deletions(-)
>>
>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>> index 99c8c20..e9e9e60 100755
>> --- a/gitweb/gitweb.perl
>> +++ b/gitweb/gitweb.perl
>> @@ -609,6 +609,40 @@ sub evaluate_path_info {
>> $input_params{'hash_parent'} ||= $parentrefname;
>> }
>> }
>> +
>> + # for the snapshot action, we allow URLs in the form
>> + # $project/snapshot/$hash.ext
>> + # where .ext determines the snapshot and gets removed from the
>> + # passed $refname to provide the $hash.
>> + #
>> + # To be able to tell that $refname includes the format extension, we
>> + # require the following two conditions to be satisfied:
>> + # - the hash input parameter MUST have been set from the $refname part
>> + # of the URL (i.e. they must be equal)
>
> This means no "$project/.tgz?h=next", isn't it?
Right.
>> + # - the snapshot format MUST NOT have been defined already
>
> I would add "which means that 'sf' parameter is not set in URL", or
> something like that as the last line of above comment.
Good idea. I'll make it an 'e.g.' to keep the comment valid for future
additional parameter evaluation such as command-line input.
> I like that the code is so well commented, by the way.
Thanks.
>> + if ($input_params{'action'} eq 'snapshot' && defined $refname &&
>> + $refname eq $input_params{'hash'} &&
>
> Minor nit.
>
> I would use here (the question of style / better readability):
>
> + if ($input_params{'action'} eq 'snapshot' &&
> + defined $refname && $refname eq $input_params{'hash'} &&
>
> to have both conditions about $refname in the same line.
Yes, it'd look much better.
>> + !defined $input_params{'snapshot_format'}) {
>> + # We loop over the known snapshot formats, checking for
>> + # extensions. Allowed extensions are both the defined suffix
>> + # (which includes the initial dot already) and the snapshot
>> + # format key itself, with a prepended dot
>> + while (my ($fmt, %opt) = each %known_snapshot_formats) {
>> + my $hash = $refname;
>> + my $sfx;
>> + $hash =~ s/(\Q$opt{'suffix'}\E|\Q.$fmt\E)$//;
>> + next unless $sfx = $1;
>> + # a valid suffix was found, so set the snapshot format
>> + # and reset the hash parameter
>> + $input_params{'snapshot_format'} = $fmt;
>> + $input_params{'hash'} = $hash;
>> + # we also set the format suffix to the one requested
>> + # in the URL: this way a request for e.g. .tgz returns
>> + # a .tgz instead of a .tar.gz
>> + $known_snapshot_formats{$fmt}{'suffix'} = $sfx;
>> + last;
>> + }
>
> I'm not sure if it worth (see comment at the beginning of this mail)
> adding this code, or just allow $sfx to be snapshot _name_ (key in
> %known_snapshot_formats hash).
>
> Otherwise it would be as simple as checking if $known_snapshot_formats{$sfx}
> exists (assuming that snapshot format names does not contain '.').
>
> If we decide to go more complicated route, then refactoring it in such
> a way that suffixes are also keys to %known_snapshot_formats would be
> preferred... err, sorry, not so simple. But refactoring this check
> into separate subroutine (as I think last patch in series does) would
> be good idea.
See comments above.
> Also, I'd rather you checked if the $refname part contains '.' for it
> to even consider that it can be suffix.
Ah, good idea.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [PATCH, RFC] diff: add option to show context between close chunks
From: Daniel Barkalow @ 2008-10-21 18:16 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, René Scharfe, Git Mailing List,
Davide Libenzi
In-Reply-To: <48FD781C.2000103@viscovery.net>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1363 bytes --]
On Tue, 21 Oct 2008, Johannes Sixt wrote:
> Junio C Hamano schrieb:
> > René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> >
> >> I think it makes sense to make 1, or even 3, the default for this
> >> option for all commands that create patches intended for human
> >> consumption. The patch keeps the default at 0, though.
> >
> > I think defaulting to 1 would make sense, or alternatively, just
> > hardcoding that behaviour without any new option. That would give you
> > more information with the same number of patch lines, iow, upside without
> > any downside.
>
> Are you sure about the "without any downside" part? The extra context line
> inhibits that the patch applies cleanly to a version of the file that has
> that very line modified (including a different number of lines).
We could start allowing "fuzz" by default in the case of a patch with more
context than we'd expect to see. That is, git-apply would ignore context
lines more than 3 lines away from any changed lines, sharing the
assumption of our patch-generation side that lines that far away don't
matter in general. (Now, if people were in the habit of including as
context additional lines in fragile locations, this wouldn't be a good
assumption, but I doubt anybody would be able to identify such lines to
include them).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [EGIT PATCH] git property page for project properties.
From: Tomi Pakarinen @ 2008-10-21 18:09 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: spearce, git
In-Reply-To: <200810211950.50540.robin.rosenberg.lists@dewire.com>
On Tue, Oct 21, 2008 at 8:50 PM, Robin Rosenberg
<robin.rosenberg.lists@dewire.com> wrote:
> måndagen den 20 oktober 2008 21.06.44 skrev Tomi Pakarinen:
>> Show git property page in project's properties, if project
>> has git repository provider.
> [...]
>> + switch (repository.getRepositoryState()) {
>> + case BISECTING:
>> + state.setText("Bisecting");
>> + break;
>> + case MERGING:
>> + state.setText("Merging");
>> + break;
>> + case REBASING:
>> + state.setText("Rebasing");
>> + break;
>> + case REBASING_INTERACTIVE:
>> + state.setText("Rebasing interactive");
>> + break;
>> + case REBASING_MERGE:
>> + state.setText("Rebasing merge");
>> + break;
>> + case SAFE:
>> + state.setText("Safe");
>> + break;
>> + }
> Why not this:
>
> state.setText(repository.getRepositoryState().getDescription());
>
> Description is ment for presentation purposes. The enum for code.
>
> -- robin
>
That is ok. I just didn't notice that method before. But, what if
someone wants localize this plugin, he'll propably have to explode
this back to switch statement.
Tomi.
^ permalink raw reply
* new plan for cleaning up the worktree mess, was Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Johannes Schindelin @ 2008-10-21 17:59 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyen Thai Ngoc Duy, Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <20081021174303.GA25827@coredump.intra.peff.net>
Hi,
On Tue, 21 Oct 2008, Jeff King wrote:
> On Tue, Oct 21, 2008 at 07:02:48PM +0200, Johannes Schindelin wrote:
>
> > So I propose this change in semantics:
> >
> > - setup_git_directory_gently(): rename to discover_git_directory(),
> > and avoid any chdir() at all.
> > - setup_git_directory(): keep the semantics that it chdir()s to the
> > worktree, or to the git directory for bare repositories.
> >
> > Using _gently() even for RUN_SETUP builtins should solve the long
> > standing pager problem, too.
>
> I'm not sure there aren't hidden problems lurking in that strategy
> (every time I look at this area of code, something unexpected prevents
> what I think should Just Work from Just Working), but I think that is a
> promising direction to go for clearing up some of the long-standing
> issues.
Same here. I grew a pretty strong opinion about the whole worktree thing,
but maybe that is only because it was done trying to change as little as
possible.
> I think you will need to do something for a few commands which use
> _gently() but then, if we _are_ in a git repo, assume we are chdir'd
> properly.
Right.
> We may also be able to just call setup_git_directory_gently() as the
> first thing in the wrapper, which should help us more consistently find
> config before the 'exec' stage (see 4e10738a for a discussion of some of
> the issues).
Yep, that's what I referred to as "pager" problems. Thanks for the
pointer! For other people's convenience I quote it here :-)
-- snip --
Allow per-command pager config
There is great debate over whether some commands should set
up a pager automatically. This patch allows individuals to
set their own pager preferences for each command, overriding
the default. For example, to disable the pager for git
status:
git config pager.status false
If "--pager" or "--no-pager" is specified on the command
line, it takes precedence over the config option.
There are two caveats:
- you can turn on the pager for plumbing commands.
Combined with "core.pager = always", this will probably
break a lot of things. Don't do it.
- This only works for builtin commands. The reason is
somewhat complex:
Calling git_config before we do setup_git_directory
has bad side effects, because it wants to know where
the git_dir is to find ".git/config". Unfortunately,
we cannot call setup_git_directory indiscriminately,
because some builtins (like "init") break if we do.
For builtins, this is OK, since we can just wait until
after we call setup_git_directory. But for aliases, we
don't know until we expand (recursively) which command
we're doing. This should not be a huge problem for
aliases, which can simply use "--pager" or "--no-pager"
in the alias as appropriate.
For external commands, however, we don't know we even
have an external command until we exec it, and by then
it is too late to check the config.
An alternative approach would be to have a config mode
where we don't bother looking at .git/config, but only
at the user and system config files. This would make the
behavior consistent across builtins, aliases, and
external commands, at the cost of not allowing per-repo
pager config for at all.
-- snap --
Ciao,
Dscho
^ permalink raw reply
* Re: [EGIT PATCH] git property page for project properties.
From: Robin Rosenberg @ 2008-10-21 17:50 UTC (permalink / raw)
To: Tomi Pakarinen; +Cc: spearce, git
In-Reply-To: <1224529604-42397-1-git-send-email-tomi.pakarinen@iki.fi>
måndagen den 20 oktober 2008 21.06.44 skrev Tomi Pakarinen:
> Show git property page in project's properties, if project
> has git repository provider.
[...]
> + switch (repository.getRepositoryState()) {
> + case BISECTING:
> + state.setText("Bisecting");
> + break;
> + case MERGING:
> + state.setText("Merging");
> + break;
> + case REBASING:
> + state.setText("Rebasing");
> + break;
> + case REBASING_INTERACTIVE:
> + state.setText("Rebasing interactive");
> + break;
> + case REBASING_MERGE:
> + state.setText("Rebasing merge");
> + break;
> + case SAFE:
> + state.setText("Safe");
> + break;
> + }
Why not this:
state.setText(repository.getRepositoryState().getDescription());
Description is ment for presentation purposes. The enum for code.
-- robin
^ permalink raw reply
* Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Jeff King @ 2008-10-21 17:43 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Nguyen Thai Ngoc Duy, Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0810211856090.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Tue, Oct 21, 2008 at 07:02:48PM +0200, Johannes Schindelin wrote:
> So I propose this change in semantics:
>
> - setup_git_directory_gently(): rename to discover_git_directory(),
> and avoid any chdir() at all.
> - setup_git_directory(): keep the semantics that it chdir()s to the
> worktree, or to the git directory for bare repositories.
>
> Using _gently() even for RUN_SETUP builtins should solve the long standing
> pager problem, too.
I'm not sure there aren't hidden problems lurking in that strategy
(every time I look at this area of code, something unexpected prevents
what I think should Just Work from Just Working), but I think that is a
promising direction to go for clearing up some of the long-standing
issues.
I think you will need to do something for a few commands which use
_gently() but then, if we _are_ in a git repo, assume we are chdir'd
properly.
We may also be able to just call setup_git_directory_gently() as the
first thing in the wrapper, which should help us more consistently find
config before the 'exec' stage (see 4e10738a for a discussion of some of
the issues).
-Peff
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Junio C Hamano @ 2008-10-21 16:56 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Junio C Hamano, Andreas Ericsson, git
In-Reply-To: <ee2a733e0810210323j249c3460x881af6d6aefc647c@mail.gmail.com>
"Leo Razoumov" <slonik.az@gmail.com> writes:
> Even though the old behavior is "long established", it introduces
> unnecessary ambiguity. If I have two repos
> ...
Of course. Now you know why people don't name such a pair of repositories
like that ;-).
^ permalink raw reply
* Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Johannes Schindelin @ 2008-10-21 17:02 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <fcaeb9bf0810210757w1c14e0a3x1eb61a589a089f10@mail.gmail.com>
Hi,
On Tue, 21 Oct 2008, Nguyen Thai Ngoc Duy wrote:
> Maybe we should let setup_*_gently() do read-only stuff only and let its
> consumers to handle cwd.
I think that makes sense. This would allow setup*gently() to be much
cleaner, and only setup_git_directory() itself would do the
chdir(worktree).
However, let's think this really through this time, so that that darned
worktree stuff is fixed for good.
So I propose this change in semantics:
- setup_git_directory_gently(): rename to discover_git_directory(),
and avoid any chdir() at all.
- setup_git_directory(): keep the semantics that it chdir()s to the
worktree, or to the git directory for bare repositories.
Using _gently() even for RUN_SETUP builtins should solve the long standing
pager problem, too.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATHv2 6/8] gitweb: retrieve snapshot format from PATH_INFO
From: Jakub Narebski @ 2008-10-21 16:44 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <1224426270-27755-1-git-send-email-giuseppe.bilotta@gmail.com>
I like the idea behind this patch, to enable to use path_info for as
much gitweb parameters as possible. After this patch series the only
parameters which wouldn't be possible to represent in path_info would
be:
* @extra_options ('opt') multi-valued parameter, used to pass
thinks like '--no-merges', which cannot be fit in the "simplified"
list-like (as opposed to hash-like query string) path_info URL.
* $searchtype ('st') and $searchtext ('s') etc. parameters, which
are generated by HTML form, and are naturally generated in query
string format.
* $page ('pg') parameter, which could theoretically be added as last
part of path_info URL, for example $project/next/2/... if not for
pesky $project/history/next:/Documentation/2/ where you cannot be
sure that having /<number>/ at the end is rare.
* $order ('o') parameter, which would be hard to fit in path_info,
with its limitation of parameters being specified by position.
Or even next to impossible.
* 'by_tag'...
But I'd rather have this patch series to be in separate thread...
On Sun, 19 Oct 2008, Giuseppe Bilotta wrote:
> We parse requests for $project/snapshot/$head.$sfx as equivalent to
> $project/snapshot/$head?sf=$sfx, where $sfx is any of the known
> (although not necessarily supported) snapshot formats (or its default
> suffix).
>
> The filename for the resulting package preserves the requested
> extensions (so asking for a .tgz gives a .tgz, and asking for a .tar.gz
> gives a .tar.gz), although for obvious reasons it doesn't preserve the
> basename (git/snapshot/next.tgz returns a file names git-next.tgz).
That is a bit of difference from sf=<format> in CGI query string, where
<format> is always a name of a format (for example 'tgz' or 'tbz2'),
and actual suffix is defined in %known_snapshot_formats (for example
'.tar.gz' and '.tar.bz2' respectively). Now you can specify snapshot
format either either by its name, for example 'tgz' (which is simple
lookup in hash) which result in proposed filename with '.tgz' suffix,
or you can specify suffix, for example 'tar.gz' (which requires
searching through all hash) which result in proposed filename with
'.tar.gz' suffix.
This is a bit of inconsistency; to be consistent with how we handle
'sf' CGI parameter we would translate 'tgz' $sfx into 'tar.gz' in
snapshot filename. This would also cover currently purely theoretical
case when different snapshot formats (for example 'tgz' and 'tgz9')
would use the same snapshot suffix (extension), but differ for example
in parameters passed to compressor (for example '-9' or '--best' in
the 'tgz9' case).
On the other hand one would expect that when URL which looks like
URL to snapshot ends with '.$sfx', then filename for snapshot would
also end with '.$sfx'.
This certainly requires some further thoughts.
>
> This introduces a potential case for ambiguity if a project has a head
> that ends with a snapshot-like suffix (.zip, .tgz, .tar.gz, etc) and the
> sf CGI parameter is not present; however, gitweb only produces URLs with
> the sf parameter, so this is only a potential issue for hand-coded URLs
> for extremely unusual project.
I think you wanted to say here "_currently_ produces URLs with the 'sf'
parameter" as the next patch in series changes this.
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
>
> I had second thoughts on this. Now we always look for the snapshot extension if
> the sf CGI parameter is missing, even if the project has a head that matches
> the full pseudo-refname $head.$sfx.
>
> The reason for this is that (1) there is no ambiguity for gitweb-generated
> URLs (2) the only URLs that could fail are hand-made URLs for extremely
> unusual projects and (3) it allows us to set gitweb up to generate
> (unambiguous) URLs without the sf CGI parameter.
This is also simpler and cheaper solution.
>
> This also means that I can add 3 patches to the series, instead of just one:
> * patch #6 that parses the new format
> * patch #7 that generates the new URLs
> * patch #8 for some code refactoring
Now, I haven't yet read the last patch in series, so I don't know if
it is independent refactoring, making sense even before patches named
#6 and #7 here, or is it connected with searching for snapshot format
by suffix it uses. If the former, it should be done upfront, as it
shouldn't need discussion, and being easier to be accepted into git.git.
If the latter, then it should probably be folded (squashed) into #6,
first patch in the series.
>
> gitweb/gitweb.perl | 34 ++++++++++++++++++++++++++++++++++
> 1 files changed, 34 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 99c8c20..e9e9e60 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -609,6 +609,40 @@ sub evaluate_path_info {
> $input_params{'hash_parent'} ||= $parentrefname;
> }
> }
> +
> + # for the snapshot action, we allow URLs in the form
> + # $project/snapshot/$hash.ext
> + # where .ext determines the snapshot and gets removed from the
> + # passed $refname to provide the $hash.
> + #
> + # To be able to tell that $refname includes the format extension, we
> + # require the following two conditions to be satisfied:
> + # - the hash input parameter MUST have been set from the $refname part
> + # of the URL (i.e. they must be equal)
This means no "$project/.tgz?h=next", isn't it?
> + # - the snapshot format MUST NOT have been defined already
I would add "which means that 'sf' parameter is not set in URL", or
something like that as the last line of above comment.
I like that the code is so well commented, by the way.
> + if ($input_params{'action'} eq 'snapshot' && defined $refname &&
> + $refname eq $input_params{'hash'} &&
Minor nit.
I would use here (the question of style / better readability):
+ if ($input_params{'action'} eq 'snapshot' &&
+ defined $refname && $refname eq $input_params{'hash'} &&
to have both conditions about $refname in the same line.
> + !defined $input_params{'snapshot_format'}) {
> + # We loop over the known snapshot formats, checking for
> + # extensions. Allowed extensions are both the defined suffix
> + # (which includes the initial dot already) and the snapshot
> + # format key itself, with a prepended dot
> + while (my ($fmt, %opt) = each %known_snapshot_formats) {
> + my $hash = $refname;
> + my $sfx;
> + $hash =~ s/(\Q$opt{'suffix'}\E|\Q.$fmt\E)$//;
> + next unless $sfx = $1;
> + # a valid suffix was found, so set the snapshot format
> + # and reset the hash parameter
> + $input_params{'snapshot_format'} = $fmt;
> + $input_params{'hash'} = $hash;
> + # we also set the format suffix to the one requested
> + # in the URL: this way a request for e.g. .tgz returns
> + # a .tgz instead of a .tar.gz
> + $known_snapshot_formats{$fmt}{'suffix'} = $sfx;
> + last;
> + }
I'm not sure if it worth (see comment at the beginning of this mail)
adding this code, or just allow $sfx to be snapshot _name_ (key in
%known_snapshot_formats hash).
Otherwise it would be as simple as checking if $known_snapshot_formats{$sfx}
exists (assuming that snapshot format names does not contain '.').
If we decide to go more complicated route, then refactoring it in such
a way that suffixes are also keys to %known_snapshot_formats would be
preferred... err, sorry, not so simple. But refactoring this check
into separate subroutine (as I think last patch in series does) would
be good idea.
Also, I'd rather you checked if the $refname part contains '.' for it
to even consider that it can be suffix.
> + }
> }
> evaluate_path_info();
>
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] git-remote: list branches in vertical lists
From: Johannes Schindelin @ 2008-10-21 16:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <48FDEA82.5050903@viscovery.net>
Hi,
On Tue, 21 Oct 2008, Johannes Sixt wrote:
> Previously, branches were listed on a single line in each section. But
> if there are many branches, then horizontal, line-wrapped lists are very
> inconvenient to scan for a human. This makes the lists vertical, i.e one
> branch per line is printed.
>
> This does mean that users' scripts must be updated because the output
> format changed, but the result is friendlier to the eye *and* easier to
> parse.
My initial reaction to that was: add an option, and keep the old behavior
then.
But on second thought: No script has any business scanning the output of
git-remote. That command is a pure convenience wrapper, and scripts
trying to list remote branches should use git show-ref instead.
So I'd say: replace the last comment with
Since "git remote" is porcelain, we can easily make this
backwards-incompatible change.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-10-21 16:30 UTC (permalink / raw)
To: git; +Cc: gitster
After fixing clone -q I noticed that pull -q does not do what
it's supposed to do and implemented --quiet/--verbose by
adding it to builtin-merge and fixing two places in builtin-fetch.
I have not touched/adjusted contrib/completion/git-completion.bash
but can take a look if wanted. I think it already needs one or two
adjustments caused by recent --OPTIONS changes in master.
I've tested the following invocations with the below changes applied:
$ git pull
$ git pull -q
$ git pull -v
$ git fetch -q
$ git pull -q -v -q
Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
---
Documentation/merge-options.txt | 8 ++++++++
builtin-fetch.c | 21 +++++++++++----------
builtin-merge.c | 22 +++++++++++++++-------
git-pull.sh | 11 ++++++++---
4 files changed, 42 insertions(+), 20 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 007909a..427cdef 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -1,3 +1,11 @@
+-q::
+--quiet::
+ Operate quietly.
+
+-v::
+--verbose::
+ Be verbose.
+
--stat::
Show a diffstat at the end of the merge. The diffstat is also
controlled by the configuration option merge.stat.
diff --git a/builtin-fetch.c b/builtin-fetch.c
index ee93d3a..b067512 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -22,16 +22,17 @@ enum {
TAGS_SET = 2
};
-static int append, force, keep, update_head_ok, verbose, quiet;
+static int append, force, keep, update_head_ok;
static int tags = TAGS_DEFAULT;
static const char *depth;
static const char *upload_pack;
static struct strbuf default_rla = STRBUF_INIT;
static struct transport *transport;
+static enum { QUIET, NORMAL, VERBOSE } verbosity = NORMAL;
static struct option builtin_fetch_options[] = {
- OPT__QUIET(&quiet),
- OPT__VERBOSE(&verbose),
+ OPT_SET_INT('v', "verbose", &verbosity, "be verbose", VERBOSE),
+ OPT_SET_INT('q', "quiet", &verbosity, "operate quietly", QUIET),
OPT_BOOLEAN('a', "append", &append,
"append to .git/FETCH_HEAD instead of overwriting"),
OPT_STRING(0, "upload-pack", &upload_pack, "PATH",
@@ -192,7 +193,6 @@ static int s_update_ref(const char *action,
static int update_local_ref(struct ref *ref,
const char *remote,
- int verbose,
char *display)
{
struct commit *current = NULL, *updated;
@@ -210,7 +210,7 @@ static int update_local_ref(struct ref *ref,
die("object %s not found", sha1_to_hex(ref->new_sha1));
if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
- if (verbose)
+ if (verbosity == VERBOSE)
sprintf(display, "= %-*s %-*s -> %s", SUMMARY_WIDTH,
"[up to date]", REFCOL_WIDTH, remote,
pretty_ref);
@@ -366,18 +366,19 @@ static int store_updated_refs(const char *url, const char *remote_name,
note);
if (ref)
- rc |= update_local_ref(ref, what, verbose, note);
+ rc |= update_local_ref(ref, what, note);
else
sprintf(note, "* %-*s %-*s -> FETCH_HEAD",
SUMMARY_WIDTH, *kind ? kind : "branch",
REFCOL_WIDTH, *what ? what : "HEAD");
if (*note) {
- if (!shown_url) {
+ if (verbosity > QUIET && !shown_url) {
fprintf(stderr, "From %.*s\n",
url_len, url);
shown_url = 1;
}
- fprintf(stderr, " %s\n", note);
+ if (verbosity > QUIET)
+ fprintf(stderr, " %s\n", note);
}
}
fclose(fp);
@@ -622,9 +623,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
remote = remote_get(argv[0]);
transport = transport_get(remote, remote->url[0]);
- if (verbose >= 2)
+ if (verbosity == VERBOSE)
transport->verbose = 1;
- if (quiet)
+ if (verbosity == QUIET)
transport->verbose = -1;
if (upload_pack)
set_option(TRANS_OPT_UPLOADPACK, upload_pack);
diff --git a/builtin-merge.c b/builtin-merge.c
index 5e7910b..76e2890 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -50,6 +50,7 @@ static unsigned char head[20], stash[20];
static struct strategy **use_strategies;
static size_t use_strategies_nr, use_strategies_alloc;
static const char *branch;
+static enum { QUIET, NORMAL, VERBOSE } verbosity = NORMAL;
static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -152,6 +153,8 @@ static int option_parse_n(const struct option *opt,
}
static struct option builtin_merge_options[] = {
+ OPT_SET_INT('v', "verbose", &verbosity, "be verbose", VERBOSE),
+ OPT_SET_INT('q', "quiet", &verbosity, "operate quietly", QUIET),
{ OPTION_CALLBACK, 'n', NULL, NULL, NULL,
"do not show a diffstat at the end of the merge",
PARSE_OPT_NOARG, option_parse_n },
@@ -250,7 +253,8 @@ static void restore_state(void)
/* This is called when no merge was necessary. */
static void finish_up_to_date(const char *msg)
{
- printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
+ if (verbosity > QUIET)
+ printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
drop_save();
}
@@ -331,14 +335,15 @@ static void finish(const unsigned char *new_head, const char *msg)
if (!msg)
strbuf_addstr(&reflog_message, getenv("GIT_REFLOG_ACTION"));
else {
- printf("%s\n", msg);
+ if (verbosity > QUIET)
+ printf("%s\n", msg);
strbuf_addf(&reflog_message, "%s: %s",
getenv("GIT_REFLOG_ACTION"), msg);
}
if (squash) {
squash_message();
} else {
- if (!merge_msg.len)
+ if (verbosity > QUIET && !merge_msg.len)
printf("No merge message -- not updating HEAD\n");
else {
const char *argv_gc_auto[] = { "gc", "--auto", NULL };
@@ -872,6 +877,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, builtin_merge_options,
builtin_merge_usage, 0);
+ if (verbosity > QUIET)
+ show_diffstat = 0;
if (squash) {
if (!allow_fast_forward)
@@ -1013,10 +1020,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
- printf("Updating %s..%s\n",
- hex,
- find_unique_abbrev(remoteheads->item->object.sha1,
- DEFAULT_ABBREV));
+ if (verbosity > QUIET)
+ printf("Updating %s..%s\n",
+ hex,
+ find_unique_abbrev(remoteheads->item->object.sha1,
+ DEFAULT_ABBREV));
strbuf_addstr(&msg, "Fast forward");
if (have_message)
strbuf_addstr(&msg,
diff --git a/git-pull.sh b/git-pull.sh
index 75c3610..c982d08 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,13 +16,17 @@ cd_to_toplevel
test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
-strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
+strategy_args= no_stat= no_commit= squash= no_ff= log_arg= verbosity=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
rebase=$(git config --bool branch.$curr_branch_short.rebase)
while :
do
case "$1" in
+ -q|--quiet)
+ verbosity=-q ;;
+ -v|--verbose)
+ verbosity=-v ;;
-n|--no-stat|--no-summary)
no_stat=-n ;;
--stat|--summary)
@@ -121,7 +125,7 @@ test true = "$rebase" && {
"refs/remotes/$origin/$reflist" 2>/dev/null)"
}
orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
-git fetch --update-head-ok "$@" || exit 1
+git fetch $verbosity --update-head-ok "$@" || exit 1
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
if test "$curr_head" != "$orig_head"
@@ -181,5 +185,6 @@ merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
test true = "$rebase" &&
exec git-rebase $strategy_args --onto $merge_head \
${oldremoteref:-$merge_head}
-exec git-merge $no_stat $no_commit $squash $no_ff $log_arg $strategy_args \
+exec git-merge $verbosity $no_stat $no_commit \
+ $squash $no_ff $log_arg $strategy_args \
"$merge_name" HEAD $merge_head
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-10-21 16:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsg22568.fsf@gitster.siamese.dyndns.org>
On Tue, Oct 21, 2008 at 1:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> On Sun, Oct 19, 2008 at 11:26 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> ...
>>>> @@ -23,6 +24,10 @@ rebase=$(git config --bool branch.$curr_branch_short.rebase)
>>>> while :
>>>> do
>>>> case "$1" in
>>>> + -q|--quiet)
>>>> + verbosity="$verbosity -q" ;;
>>>> + -v|--verbose)
>>>> + verbosity="$verbosity -v" ;;
>>>
>>> You know verbosity flags (-q and -v) are "the last one wins", so I do not
>>> see much point in this concatenation.
>>
>> Without concatenation I would need to analyze the content
>> of the variable each time the option is passed to the shell
>> script. Do you know of a simpler/better way still keeping the
>> functionality that
>> $ git pull -q -v --quiet --verbose --quiet gives verbosity=QUIET
>> and
>> $ git pull -q -v --quiet --verbose --quiet -v yields verbosity=VERBOSE
>> ?
>
> Wouldn't
>
> verbosity=
> while :
> do
> case "$1" in
> -q|--quiet) verbosity=-q ;;
> -v|--verbose) verbosity=-v ;;
> ... others ...
> esac
> shift
> done
> git pull $verbosity other options
>
> give the -q for the former and -v for the latter to "git pull"?
Yes that is much simpler and works :). Thanks.
Please see my next patch in a few minutes.
I might not reply before the weekend as I'm pretty busy, btw.
^ permalink raw reply
* Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Nicolas Pitre @ 2008-10-21 15:54 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <fcaeb9bf0810210757w1c14e0a3x1eb61a589a089f10@mail.gmail.com>
On Tue, 21 Oct 2008, Nguyen Thai Ngoc Duy wrote:
> On 10/21/08, Nicolas Pitre <nico@cam.org> wrote:
> > Before commit d0b92a3f6e it was possible to run 'git index-pack'
> > directly in the .git/objects/pack/ directory. Restore that ability.
>
> I am sorry I did not catch this in the first place. While the fix
> should be fine for "git index-pack". I wonder what can happen for
> other setup_*_gently()'s consumers. Other commands may be affected too
> (e.g. running "git apply" or "git bundle" from inside .git).
Normally you should not be running such commands inside the .git
directory. The index-pack command is a bit special in that regard.
Nicolas
^ permalink raw reply
* Re: Working with remotes; cloning remote references
From: Marc Branchaud @ 2008-10-21 15:17 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Peter Harris, git
In-Reply-To: <48FDA5A0.8030506@drmicha.warpmail.net>
Michael J Gruber wrote:
>
>> clone/$ git config remote.origin.fetch \
>> '+refs/remotes/ThingOne/*:refs/remotes/ThingOne/*'
>
> If you want to fetch main's local branches also, use option "--add" here
> so that you don't override the default fetch refspec (forgot last time,
> sorry).
Okay, got it.
> I thought you wanted to avoid pulling directly from ThingOne to clone?
Ah, I see (part of) our disconnect here -- sorry for not explaining it
clearly before!
Yes, indeed, I do want to pull directly from ThingOne into the clone.
The scenario is that there's a bunch of us sharing the main repo, and
when some upstream changes happen in ThingOne I'd like for one of us to
be able to clone the main repo, pull the changes from ThingOne into the
clone (fixing any conflicts; remember that we have our own changes in
ThingOne's code), then push the merged changes back to main for everyone
else to grab.
> If you pull directly you might as well set up the same remote config as
> on main: for the correct pull line you need to know the same info as for
> the correct remote config.
Yes, I see that -- it's why I'm basically satisfied with being able to do
clone/$ git pull -s subtree /path/to/ThingOne master
from the clone, and all I'm doing now is kvetching about having to
remember the location and branch of ThingOne when that was already
configured in main (and thanks for being patient with my kvetching!).
> git fetch
> git merge -s subtree remotes/ThingOne/master
>
> should do the trick.
AFAICT that only refers to the clone's local branch for the ThingOne
repo. The above git-config command doesn't add the ThingOne repo's URL
to the clone, so I'm still stuck having to use that URL directly to pull
changes from ThingOne into the clone. (And when I use the URL directly,
I have to use a branch name that's defined in the ThingOne repo. I'd
like to also be able to use whatever branch name got set up in main when
"git remote add" was run.)
> If that works you can set up things so that pulling
> from origin (pulling when you're in your integration branch) does that
> merge automatically, using branch.integrationbranch.remote=origin,
> branch.integrationbranch.merge=remotes/ThingOne/master (untested ;) ).
>
> To be clear: The idea here is that main decides which ThingOne branch to
> store in remotes/ThingOne/master and where to get it from; clones always
> pull that one.
I think that "where to get it from" part is what I'm going on about.
There doesn't seem to be a way for the main repo to tell the clone where
the ThingOne repo is, so that the clone can pull in ThingOne changes
directly.
>> I just feel that there are some
>> situations where you want the origin's remotes in your clone, and some
>> where you don't, and git should let you decide.
>
> Well, it let's you decide: It tracks local branches by default, and
> using additional "git config" you can track remotes as well. You can
> also use the "--mirror" option to "git clone" or "git remote add", but
> that has other side effects.
I think we're mis-communicating, mainly because I'm not yet able to
express things well in git-speak. Let me give it another stab...
I believe git lets you track the origin's _branches_ not the origin's
_remotes_. I don't think --mirror does what I'm looking for, because
(side effects aside) it only deals with branches, not remotes.
I find myself getting confused, and I think it's because the files in
.git/refs/remotes/ are indeed tracking branches on remote repositories.
So I think our conversation gets a bit circular because our ideas of a
"remote" differ.
"git remote add" does two things (maybe more?): It adds a [remote]
section to the .git/config file, and it adds a branch reference in
.git/refs/remotes/. I think what I'd like is for the clone to be able
to obtain both these things from the origin. The reason I think it's
useful is that it would let the clone pull directly from the origin's
remote repositories, without having to directly specify the remote
repository's URL and branch name.
Fundamentally, I'm looking to do exactly
clone/$ git pull -s subtree /path/to/ThingOne master
i.e. pull stuff from one of main's remotes directly into the clone. But
I want to replace the "/path/to/ThingOne master" part with something
that means "use whatever URL and branch name was defined in the origin
for this remote".
My questions are: Am I right in thinking this is desirable? Is there
already some way to do this? If not, is it something worth
implementing? (I'm happy to roll up my own sleeves here...)
I hope that clarifies things. Sorry for taking so long to get here!
Marc
^ permalink raw reply
* Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Jeff King @ 2008-10-21 15:02 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <fcaeb9bf0810210757w1c14e0a3x1eb61a589a089f10@mail.gmail.com>
On Tue, Oct 21, 2008 at 09:57:04PM +0700, Nguyen Thai Ngoc Duy wrote:
> (e.g. running "git apply" or "git bundle" from inside .git). Maybe we
> should let setup_*_gently() do read-only stuff only and let its
> consumers to handle cwd. I recall Jeff has plan about worktree setup
> rework, though could not find the thread. Will think more of it
> tomorrow.
If by "plan" you mean "intense desire to see it fixed", then yes, I have
a plan. But there isn't a concrete plan yet, and I'm not sure when I'll
get to it. I have a vague assumption that we should move in the
direction of just setting up as much of the environment as possible
(finding git dir, finding work tree, reading config, etc) as soon as
possible, but not producing any error messages or dying as a result.
Then those commands which want to enforce that some setup has occurred
can easily do so.
-Peff
^ permalink raw reply
* Re: [PATCH] rehabilitate 'git index-pack' inside the object store
From: Nguyen Thai Ngoc Duy @ 2008-10-21 14:57 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0810202110380.26244@xanadu.home>
On 10/21/08, Nicolas Pitre <nico@cam.org> wrote:
> Before commit d0b92a3f6e it was possible to run 'git index-pack'
> directly in the .git/objects/pack/ directory. Restore that ability.
I am sorry I did not catch this in the first place. While the fix
should be fine for "git index-pack". I wonder what can happen for
other setup_*_gently()'s consumers. Other commands may be affected too
(e.g. running "git apply" or "git bundle" from inside .git). Maybe we
should let setup_*_gently() do read-only stuff only and let its
consumers to handle cwd. I recall Jeff has plan about worktree setup
rework, though could not find the thread. Will think more of it
tomorrow.
--
Duy
^ 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