* [PATCH] setup_work_tree: adjust relative $GIT_WORK_TREE after moving cwd
From: Nguyễn Thái Ngọc Duy @ 2010-12-26 11:46 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1293285457-11915-2-git-send-email-pclouds@gmail.com>
When setup_work_tree() is called, it moves cwd to $GIT_WORK_TREE and
makes internal copy of $GIT_WORK_TREE absolute. The environt variable,
if set by user, remains unchanged. If the variable is relative, it is
no longer correct because its base dir has changed.
Instead of making $GIT_WORK_TREE absolute too, we just say "." and let
subsequent git processes handle it.
Reported-by: Michel Briand <michelbriand@free.fr>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
This one is better, on top of master because the next one is on top
of nd/setup.
And I forgot to tell why I did not put the fault in real life [1]
into tests: I don't like git-merge spawning another process just for
resetting worktree. Sooner or later it should be replaced to use
unpack_trees() directly. When that happens, the test would become
invalid.
[1] http://thread.gmane.org/gmane.comp.version-control.git/164066/focus=164171
.gitignore | 1 +
Makefile | 1 +
setup.c | 8 ++++++++
t/t1501-worktree.sh | 11 +++++++++++
test-subprocess.c | 21 +++++++++++++++++++++
5 files changed, 42 insertions(+), 0 deletions(-)
create mode 100644 test-subprocess.c
diff --git a/.gitignore b/.gitignore
index 87b833c..3dd6ef7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -177,6 +177,7 @@
/test-sha1
/test-sigchain
/test-string-pool
+/test-subprocess
/test-svn-fe
/test-treap
/common-cmds.h
diff --git a/Makefile b/Makefile
index 57d9c65..bdf86a3 100644
--- a/Makefile
+++ b/Makefile
@@ -431,6 +431,7 @@ TEST_PROGRAMS_NEED_X += test-run-command
TEST_PROGRAMS_NEED_X += test-sha1
TEST_PROGRAMS_NEED_X += test-sigchain
TEST_PROGRAMS_NEED_X += test-string-pool
+TEST_PROGRAMS_NEED_X += test-subprocess
TEST_PROGRAMS_NEED_X += test-svn-fe
TEST_PROGRAMS_NEED_X += test-treap
TEST_PROGRAMS_NEED_X += test-index-version
diff --git a/setup.c b/setup.c
index 91887a4..3833569 100644
--- a/setup.c
+++ b/setup.c
@@ -239,6 +239,14 @@ void setup_work_tree(void)
git_dir = make_absolute_path(git_dir);
if (!work_tree || chdir(work_tree))
die("This operation must be run in a work tree");
+
+ /*
+ * Make sure subsequent git processes find correct worktree
+ * if $GIT_WORK_TREE is set relative
+ */
+ if (getenv(GIT_WORK_TREE_ENVIRONMENT))
+ setenv(GIT_WORK_TREE_ENVIRONMENT, ".", 1);
+
set_git_dir(make_relative_path(git_dir, work_tree));
initialized = 1;
}
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index 2c8f01f..1f3b50d 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -340,4 +340,15 @@ test_expect_success 'make_relative_path handles double slashes in GIT_DIR' '
git --git-dir="$(pwd)//repo.git" --work-tree="$(pwd)" add dummy_file
'
+test_expect_success 'relative $GIT_WORK_TREE and git subprocesses' '
+ (
+ GIT_DIR=repo.git &&
+ GIT_WORK_TREE=repo.git/work &&
+ export GIT_DIR GIT_WORK_TREE &&
+ test-subprocess --setup-work-tree rev-parse --show-toplevel >actual &&
+ echo "`pwd`/repo.git/work" >expected &&
+ test_cmp expected actual
+ )
+'
+
test_done
diff --git a/test-subprocess.c b/test-subprocess.c
new file mode 100644
index 0000000..667d3e5
--- /dev/null
+++ b/test-subprocess.c
@@ -0,0 +1,21 @@
+#include "cache.h"
+#include "run-command.h"
+
+int main(int argc, char **argv)
+{
+ const char *prefix;
+ struct child_process cp;
+ int nogit = 0;
+
+ prefix = setup_git_directory_gently(&nogit);
+ if (nogit)
+ die("No git repo found");
+ if (!strcmp(argv[1], "--setup-work-tree")) {
+ setup_work_tree();
+ argv++;
+ }
+ memset(&cp, 0, sizeof(cp));
+ cp.git_cmd = 1;
+ cp.argv = (const char **)argv+1;
+ return run_command(&cp);
+}
--
1.7.3.4.878.g439c7
^ permalink raw reply related
* [PATCH] setup_explicit_git_dir: adjust relative $GIT_WORK_TREE after moving cwd
From: Nguyễn Thái Ngọc Duy @ 2010-12-26 11:46 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <1293364014-8463-1-git-send-email-pclouds@gmail.com>
setup_explicit_git_dir() can move cwd. If $GIT_WORK_TREE is relative
to original cwd, then the subsequent git processes will take wrong
worktree.
Instead of making $GIT_WORK_TREE absolute too, we just say "." and let
subsequent git processes handle it.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
This one is on top of nd/setup. If nd/setup does not make it in the
next release, I can still make similar patch for master, but I don't
think this happens in real life, therefore not really urgent to fix.
There are only few cases where git spawns more git processes.
For those that do that, setup_work_tree() is likely called by git.c
already, which is what the first patch is for.
setup.c | 7 +++++++
t/t1501-worktree.sh | 12 ++++++++++++
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/setup.c b/setup.c
index 3d73269..10b8f16 100644
--- a/setup.c
+++ b/setup.c
@@ -392,6 +392,13 @@ static const char *setup_explicit_git_dir(const char *gitdirenv,
set_git_dir(make_absolute_path(gitdirenv));
if (chdir(worktree))
die_errno("Could not chdir to '%s'", worktree);
+ /*
+ * Make sure subsequent git processes find correct worktree
+ * if $GIT_WORK_TREE is set relative
+ */
+ if (work_tree_env)
+ setenv(GIT_WORK_TREE_ENVIRONMENT, ".", 1);
+
cwd[len++] = '/';
cwd[len] = '\0';
free(gitfile);
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index 1f3b50d..fa35c3e 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -351,4 +351,16 @@ test_expect_success 'relative $GIT_WORK_TREE and git subprocesses' '
)
'
+test_expect_success 'relative $GIT_WORK_TREE and git subprocesses (2)' '
+ (
+ cd repo.git/work/sub &&
+ GIT_DIR=../.. &&
+ GIT_WORK_TREE=.. &&
+ export GIT_DIR GIT_WORK_TREE &&
+ test-subprocess rev-parse --show-toplevel >actual &&
+ echo "$TRASH_DIRECTORY/repo.git/work" >expected &&
+ test_cmp expected actual
+ )
+'
+
test_done
--
1.7.3.4.878.g439c7
^ permalink raw reply related
* Re: [RFC/PATCH] diff: funcname and word patterns for perl
From: Jonathan Nieder @ 2010-12-26 11:22 UTC (permalink / raw)
To: Thomas Rast
Cc: Jakub Narebski, git, J.H., John 'Warthog9' Hawley,
Jeff King
In-Reply-To: <201012261206.11942.trast@student.ethz.ch>
Thomas Rast wrote:
> I just took the laziest (and most obvious) approach possible when I
> wrote the original patterns. I think the second most laziest one
> would be to observe that bit patterns for leading characters are
> always 11.., while those for continuation chars are 10..
>
> So that gives
>
> |[\xc0-\xff][\x80-\xbf]+
Yes, that's what I was thinking of. v2 will be a two-part series
starting with that.
BTW, the perl token matcher is pretty half-hearted. In part this is
because "only perl can parse perl" [1] terrifies me and in part it is
because I am too lazy to write down the state machine implied by
PPI/Token/*.pm.
If some tokenization wizard would like to work on it, something like
the following might produce more pleasant word diffs:
"[%&$][[:space:]]*[0-9]+" /* $1 */
"|[%&$][[:space:]]*([[:alpha:]_']|::)([[:alnum:]_']|::)*" /* $var1 */
"|[%&$][[:space:]]*\\$([[:alnum:]_]|::)([[:alnum:]_']|::)*" /* $$var1 */
"|[%&$][[:space:]]*\\$\\{" /* $${ introducing complicated expression */
"|[%&$][[:space:]]*\\$\\$" /* $$$ introducing complicated expression */
"|[%&$][[:space:]]*[^[:alnum:]_:'^$]" /* $! */
"|[%&$][[:space:]]*\\^[][A-Z\\^_?]" /* $^A */
"|[%&$][[:space:]]*\\{\\^[][A-Z\\^_?]\\}" /* ${^A} */
"|[%&$][[:space:]]*\\{\\^[][A-Z\\^_?][[:alnum:]_]*\\}" /* ${^Foo} */
/* ${var} */
"|[%&$][[:space:]]*\\{[[:space:]]*([[:alpha:]_']|::)[[:alnum:]_:]*[[:space:]]\\}"
"|[%&$][[:space:]]*\\{" /* ${ introducing complicated expression */
...
though it is an unmaintainable mess. :)
[1] perl::toke.c and http://www.perlmonks.org/?node_id=44722
^ permalink raw reply
* Re: [RFC/PATCH] diff: funcname and word patterns for perl
From: Jonathan Nieder @ 2010-12-26 10:54 UTC (permalink / raw)
To: Thomas Rast
Cc: Jakub Narebski, git, J.H., John 'Warthog9' Hawley,
Jeff King
In-Reply-To: <201012261143.33190.trast@student.ethz.ch>
Thomas Rast wrote:
> Jonathan Nieder wrote:
>> + "|[^[:space:]]"),
>
> I think it should get the |[\x80-\xff]+ arm, too. That one was
> designed to avoid splitting UTF-8 characters. At the risk of gluing
> together too many of them, of course, but I think confusing the
> terminal would be worse.
Hmm. Should it be
|([\x80-\xff]+[\x00-\x7f])
then, to match exactly one multibyte UTF-8 character?
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
From: Thomas Rast @ 2010-12-26 10:46 UTC (permalink / raw)
To: Yann Dirson; +Cc: Junio C Hamano, git
In-Reply-To: <7vlj3i5zz9.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> * yd/dir-rename (2010-10-29) 5 commits
> - Allow hiding renames of individual files involved in a directory rename.
> - Unified diff output format for bulk moves.
> - Add testcases for the --detect-bulk-moves diffcore flag.
> - Raw diff output format for bulk moves.
> - Introduce bulk-move detection in diffcore.
>
> Need to re-queue the reroll.
This BTW does not even compile on OS X because of its use of memrchr.
(I recently set up a Darwin 10.5 smoke tester that reports to Ævar's
site.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Possible bug in "git rebase" (non-interactive) with regards to post-rewrite
From: Thomas Rast @ 2010-12-26 10:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mihai Rusu, git
In-Reply-To: <7vd3ot48ke.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> When "rebase --skip" is used to skip the last patch in the series, the
> code to wrap up the rewrite by copying the notes from old to new commits
> and also by running the post-rewrite hook was bypassed.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
[...]
> -if test "$this" -gt "$last"
> -then
> - say Nothing to do.
> - rm -fr "$dotest"
> - exit
> -fi
> -
> while test "$this" -le "$last"
> do
> msgnum=`printf "%0${prec}d" $this`
Ack, thanks for patching this.
(I think it's saner anyway not to say "nothing to do" when the user
would expect "we're all done here"...)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [RFC PATCH v7 1/9] gitweb: Go to DONE_REQUEST rather than DONE_GITWEB in die_error
From: Jonathan Nieder @ 2010-12-26 9:50 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, J.H., John 'Warthog9' Hawley
In-Reply-To: <201012252314.22541.jnareb@gmail.com>
Jakub Narebski wrote:
> On Thu, 23 Dec 2010, Jonathan Nieder wrote:
>> This seems to remove the last user of the DONE_GITWEB label. Why not
>> delete the label, too?
>
> Well, actually this patch is in this series only for the label ;-)
>
> Anyway, I can simply drop this patch, and have next one in series
> (adding exception-based error handling, making die_error work like
> 'die') delete DONE_GITWEB label...
I like the current order (first the brief patch to change the
semantics, then the more ambitious change to an eval {} based error
handling implementation), but it doesn't matter so much.
>> die_error gets called when server load is too high; I wonder whether
>> it is right to go back for another request in that case.
>
> If client (web browser) are requesting connection, we have to tell it
> something anyway.
Right, I should have thought a few seconds more. Respawning
gitweb.perl would generate _more_ load[1].
>> A broken per-request (or other) configuration could potentially leave
>> a gitweb process in a broken state,
[...]
> 'die $@ if $@' would call CORE::die, which means it would end gitweb
> process.
This is referring to a later patch?
> For CGI server it doesn't matter anyway, as for each request the process
> is respawned anyway (together with respawning Perl interpreter), and I
> think that ModPerl::Registry and FastCGI servers monitor process that it
> is to serve requests, and respawn it if/when it dies.
Sorry, that was unclear of me. I meant that buggy configuration could
leave a gitweb process in buggy but alive state and frequent failing
requests might be a way to notice that. Contrived example (just to
illustrate what I mean):
our $version .= ".custom";
if (length $version >= 1000) { # untested, buggy code goes here.
@diff_opts = ("--nonsense");
}
I think I was not right to worry about this, either. It is better to
make such unusual and buggy configurations as noticeable as possible
so they can be fixed.
[...]
> But actually handle_errors_html gets called only from fatalsToBrowser,
> which in turn gets called from CGI::Carp::die... which ends calling
> CODE::die (aka realdie), which ends CGI process anyway.
>
> That is why die_error ends with
>
> goto DONE_GITWEB
> unless ($opts{'-error_handler'});
>
> i.e. it doesn't goto DONE_GITWEB nor DONE_REQUEST if called from
> handle_errors_html anyway.
[...]
> Thanks a lot for your comments.
Thanks for a thorough explanation. For what it's worth, with or
without removal of the DONE_GITWEB: label,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
[1] I can imagine scenarios in which exiting gitweb would help
alleviate the load, involving:
- large memory footprint for each gitweb process forcing the system
into swapping (e.g., from a memory leak), or
- FastCGI-like server noticing the load and choosing to decrease the
number of gitweb instances.
In the usual case, presumably gitweb memory footprint is small and
FastCGI-like servers limit the number of gitweb instances to a modest
fixed number.
^ permalink raw reply
* [RFC/PATCH] diff: funcname and word patterns for perl
From: Jonathan Nieder @ 2010-12-26 9:07 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, J.H., John 'Warthog9' Hawley, Thomas Rast, Jeff King
In-Reply-To: <201012252314.22541.jnareb@gmail.com>
The default function name discovery already works quite well for Perl
code... with the exception of here-documents (or rather their ending).
sub foo {
print <<END
here-document
END
return 1;
}
The default funcname pattern treats the unindented END line as a
function declaration and puts it in the @@ line of diff and "grep
--show-function" output.
With a little knowledge of perl syntax, we can do better. You can
try it out by adding "*.perl diff=perl" to the gitattributes file.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Jakub Narebski wrote:
> BTW. do you know how such perl support should look like?
Maybe something like this?
Documentation/gitattributes.txt | 2 ++
t/t4018-diff-funcname.sh | 2 +-
userdiff.c | 15 +++++++++++++++
3 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index 5a7f936..e59b878 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -494,6 +494,8 @@ patterns are available:
- `pascal` suitable for source code in the Pascal/Delphi language.
+- `perl` suitable for source code in the Perl language.
+
- `php` suitable for source code in the PHP language.
- `python` suitable for source code in the Python language.
diff --git a/t/t4018-diff-funcname.sh b/t/t4018-diff-funcname.sh
index 0a61b57..3646930 100755
--- a/t/t4018-diff-funcname.sh
+++ b/t/t4018-diff-funcname.sh
@@ -32,7 +32,7 @@ EOF
sed 's/beer\\/beer,\\/' < Beer.java > Beer-correct.java
-builtin_patterns="bibtex cpp csharp fortran html java objc pascal php python ruby tex"
+builtin_patterns="bibtex cpp csharp fortran html java objc pascal perl php python ruby tex"
for p in $builtin_patterns
do
test_expect_success "builtin $p pattern compiles" '
diff --git a/userdiff.c b/userdiff.c
index 2d54536..fc2afe3 100644
--- a/userdiff.c
+++ b/userdiff.c
@@ -61,6 +61,21 @@ PATTERNS("pascal",
"|[-+0-9.e]+|0[xXbB]?[0-9a-fA-F]+"
"|<>|<=|>=|:=|\\.\\."
"|[^[:space:]]|[\x80-\xff]+"),
+PATTERNS("perl",
+ "^[ \t]*package .*;\n"
+ "^[ \t]*sub .* \\{",
+ /* -- */
+ "[[:alpha:]_'][[:alnum:]_']*"
+ "|0[xb]?[0-9a-fA-F_]*"
+ /* taking care not to interpret 3..5 as (3.)(.5) */
+ "|[0-9a-fA-F_]+(\\.[0-9a-fA-F_]+)?([eE][-+]?[0-9_]+)?"
+ "|=>|-[rwxoRWXOezsfdlpSugkbctTBMAC>]|~~|::"
+ "|&&=|\\|\\|=|//=|\\*\\*="
+ "|&&|\\|\\||//|\\+\\+|--|\\*\\*|\\.\\.\\.?"
+ "|[-+*/%.^&<>=!|]="
+ "|=~|!~"
+ "|<<|<>|<=>|>>"
+ "|[^[:space:]]"),
PATTERNS("php",
"^[\t ]*(((public|protected|private|static)[\t ]+)*function.*)$\n"
"^[\t ]*(class.*)$",
--
1.7.2.3.554.gc9b5c.dirty
^ permalink raw reply related
* Re: [RFC PATCH v7 2/9] gitweb: use eval + die for error (exception) handling
From: Jakub Narebski @ 2010-12-25 23:17 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, J.H., John 'Warthog9' Hawley
In-Reply-To: <20101223020801.GB14585@burratino>
On Thu, 23 Dec 2010, Jonathan Nieder wrote:
> Jakub Narebski wrote:
>
> > Gitweb assumes here that exceptions thrown by Perl would be simple
> > strings; die_error() throws hash reference (if not for minimal
> > external dependencies, it would be probable object of Class::Exception
> > or Throwable class thrown).
>
> Hmm, why not throw an object of new type Gitweb::Exception?
First, 'gitweb: Prepare for splitting gitweb' commit is only later in
series... ;-) but that of course is not a serious issue.
Second, more important is that I'd rather gitweb doesn't go "reinvent
the wheel" route. I'd rather (re)use Exception::Class (like e.g.
SVN::Web does it) if we go the OO exception handling route.
But if we are going to use Exception::Class, then we can also use
Try::Tiny, I think.
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -1045,21 +1045,6 @@ sub configure_gitweb_features {
> > }
> > }
> >
> > -# custom error handler: 'die <message>' is Internal Server Error
> > -sub handle_errors_html {
> > - my $msg = shift; # it is already HTML escaped
> > -
> > - # to avoid infinite loop where error occurs in die_error,
> > - # change handler to default handler, disabling handle_errors_html
> > - set_message("Error occured when inside die_error:\n$msg");
> > -
> > - # you cannot jump out of die_error when called as error handler;
> > - # the subroutine set via CGI::Carp::set_message is called _after_
> > - # HTTP headers are already written, so it cannot write them itself
> > - die_error(undef, undef, $msg, -error_handler => 1, -no_http_header => 1);
> > -}
> > -set_message(\&handle_errors_html);
> > -
>
> Hoorah!
Yeah, that is very nice.
> > # dispatch
> > sub dispatch {
> > if (!defined $action) {
> > @@ -1167,7 +1152,11 @@ sub run {
> > $pre_dispatch_hook->()
> > if $pre_dispatch_hook;
> >
> > - run_request();
> > + eval { run_request() };
> > + if (defined $@ && !ref($@)) {
Ooops, it should be 'if ($@ ...)', not 'if (defined $@ ...)'.
> > + # some Perl error, but not one thrown by die_error
> > + die_error(undef, undef, $@, -error_handler => 1);
> > + }
>
> The !ref($@) seems overzealous, which is why I am wondering if it
> would be possible to use bless() for a finer-grained check.
You meant Scalar::Util::blessed here, isn't it? Fortunately Scalar::Util
is core Perl module.
By 'overzealous' do you mean here possibility of catching what we
shouldn't, i.e. non-gitweb error (not thrown by die_error)? We can
narrow it to "ref($@) eq 'HASH'", but I don't think it would be ever
necessary: Perl throws string exceptions.
> >
> > DONE_REQUEST:
> > $post_dispatch_hook->()
> > @@ -3768,7 +3757,8 @@ EOF
> > print "</div>\n";
> >
> > git_footer_html();
> > - goto DONE_REQUEST
> > +
> > + die {'status' => $status, 'error' => $error}
> > unless ($opts{'-error_handler'});
>
> Is the DONE_REQUEST label still needed?
No it isn't.
> Thanks, I am happy to see the semantics becoming less thorny.
Now I should check if this doesn't affect gitweb performance too badly.
IIRC I have chosen 'goto DONE_GITWEB' because I didn't know about
ModPerl::Registry redefining 'exit' (why it was done), and because of
some microbenchmark showing that it performs better than die/eval (why
this specific solution)...
But I think that the performance hit would be negligible in practice;
making gitweb more maintainable is I think worth the cost.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [RFC PATCH v7 1/9] gitweb: Go to DONE_REQUEST rather than DONE_GITWEB in die_error
From: Jakub Narebski @ 2010-12-25 22:14 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, J.H., John 'Warthog9' Hawley
In-Reply-To: <20101223015540.GA14585@burratino>
On Thu, 23 Dec 2010, Jonathan Nieder wrote:
> Jakub Narebski wrote:
>
> > End the request after die_error finishes, rather than exiting gitweb
> > instance
> [...]
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -1169,6 +1169,7 @@ sub run {
> >
> > run_request();
> >
> > + DONE_REQUEST:
> > $post_dispatch_hook->()
> > if $post_dispatch_hook;
> > $first_request = 0;
> > @@ -3767,7 +3768,7 @@ EOF
>
> [side note: the "@@ EOF" line above would say "@@ sub die_error {" if
> userdiff.c had perl support and gitattributes used it.]
Hmmm, I thought that git has Perl-specific diff driver (xfuncname), but
I see that it doesn't. The default funcname works quite well for Perl
code... with exception of here-documents (or rather their ending).
BTW. do you know how such perl support should look like?
> > print "</div>\n";
> >
> > git_footer_html();
> > - goto DONE_GITWEB
> > + goto DONE_REQUEST
> > unless ($opts{'-error_handler'});
>
> This seems to remove the last user of the DONE_GITWEB label. Why not
> delete the label, too?
Well, actually this patch is in this series only for the label ;-)
Anyway, I can simply drop this patch, and have next one in series
(adding exception-based error handling, making die_error work like
'die') delete DONE_GITWEB label...
> When die_error is called by CGI::Carp (via handle_errors_html), it
> does not rearm the error handler afaict. Previously that did not
> matter because die_error kills gitweb; now should it be set up
> again?
Thanks, I missed this (but after examining it turns out to be a
non-issue). That will teach me to leave code outside of run()
subroutine; one of reasons behind creating c2394fe (gitweb: Put all
per-connection code in run() subroutine, 2010-05-07) was to clarify
code flow.
A note: using set_message inside handle_errors_html was necessary
because if there was a fatal error in die_error, then
handle_errors_html would be called recursively - this was fixed in
CGI.pm 3.45, but we cannot rely on this; we cannot rely on having new
enough version of CGI::Carp that supports set_die_handler either.
But actually handle_errors_html gets called only from fatalsToBrowser,
which in turn gets called from CGI::Carp::die... which ends calling
CODE::die (aka realdie), which ends CGI process anyway.
That is why die_error ends with
goto DONE_GITWEB
unless ($opts{'-error_handler'});
i.e. it doesn't goto DONE_GITWEB nor DONE_REQUEST if called from
handle_errors_html anyway.
> die_error gets called when server load is too high; I wonder whether
> it is right to go back for another request in that case.
If client (web browser) are requesting connection, we have to tell it
something anyway. Note that each request might serve different client.
But when the die_error(503, "The load average on the server is too
high") doesn't generate load by itself, all should be all right.
>
> A broken per-request (or other) configuration could potentially leave
> a gitweb process in a broken state, and until now the state would be
> reset on the first error. I wonder if escape valve would be needed
> --- e.g., does the CGI harness take care of starting a new gitweb
> process after every couple hundred requests or so?
'die $@ if $@' would call CORE::die, which means it would end gitweb
process.
For CGI server it doesn't matter anyway, as for each request the process
is respawned anyway (together with respawning Perl interpreter), and I
think that ModPerl::Registry and FastCGI servers monitor process that it
is to serve requests, and respawn it if/when it dies.
> Aside from those (minor) worries, this patch seems like a good idea.
Thanks a lot for your comments.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 1/2] t1501: avoid bashisms
From: Nguyen Thai Ngoc Duy @ 2010-12-25 14:44 UTC (permalink / raw)
To: Andreas Schwab, Junio C Hamano; +Cc: git, Michel Briand
In-Reply-To: <AANLkTinhrBf14446rJBZSYWTSH6sxOchMcgBsrq8DoLO@mail.gmail.com>
On Sat, Dec 25, 2010 at 9:29 PM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> 2010/12/25 Andreas Schwab <schwab@linux-m68k.org>:
>> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>>
>>> @@ -322,7 +322,10 @@ test_expect_success 'git grep' '
>>> test_expect_success 'git commit' '
>>> (
>>> cd repo.git &&
>>> - GIT_DIR=. GIT_WORK_TREE=work git commit -a -m done
>>
>> In which way is that not portable?
>
> I admit that I rarely leave bash, so I'll quote Johannes answer [1]
>
> -- 8< --
> Sure, it is (bashisms). This:
>
> GIT_DIR="$TRASH_DIRECTORY/2/.git" test_repo 2/sub
>
> does not work the same way in all shells when test_repo is a shell
> function. You have to export GIT_DIR explicitly before the function call.
Hmm.. I misread it. That's only for shell _functions_. [1] says
variable assignments for simple commands are actually exported.
Junio, please don't pick up this patch.
[1] http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
--
Duy
^ permalink raw reply
* Re: [PATCH 1/2] t1501: avoid bashisms
From: Nguyen Thai Ngoc Duy @ 2010-12-25 14:29 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git, Junio C Hamano, Michel Briand
In-Reply-To: <m2aajudjqt.fsf@whitebox.home>
2010/12/25 Andreas Schwab <schwab@linux-m68k.org>:
> Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
>
>> @@ -322,7 +322,10 @@ test_expect_success 'git grep' '
>> test_expect_success 'git commit' '
>> (
>> cd repo.git &&
>> - GIT_DIR=. GIT_WORK_TREE=work git commit -a -m done
>
> In which way is that not portable?
I admit that I rarely leave bash, so I'll quote Johannes answer [1]
-- 8< --
Sure, it is (bashisms). This:
GIT_DIR="$TRASH_DIRECTORY/2/.git" test_repo 2/sub
does not work the same way in all shells when test_repo is a shell
function. You have to export GIT_DIR explicitly before the function call.
(But since in this case, test_repo invokes its own subshell anyway, you
better do it in the function.)
-- 8< --
[1] http://article.gmane.org/gmane.comp.version-control.git/162207
--
Duy
^ permalink raw reply
* Re: [PATCH 1/2] t1501: avoid bashisms
From: Andreas Schwab @ 2010-12-25 14:12 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano, Michel Briand
In-Reply-To: <1293285457-11915-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> @@ -322,7 +322,10 @@ test_expect_success 'git grep' '
> test_expect_success 'git commit' '
> (
> cd repo.git &&
> - GIT_DIR=. GIT_WORK_TREE=work git commit -a -m done
In which way is that not portable?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* [PATCH 2/2] setup_work_tree: adjust relative $GIT_WORK_TREE after moving cwd
From: Nguyễn Thái Ngọc Duy @ 2010-12-25 13:57 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Michel Briand, Nguyễn Thái Ngọc Duy
In-Reply-To: <1293285457-11915-1-git-send-email-pclouds@gmail.com>
When setup_work_tree() is called, it moves cwd to $GIT_WORK_TREE and
makes internal copy of $GIT_WORK_TREE absolute. The environt variable,
if set by user, remains unchanged. If the variable is relative, it is
no longer correct because its base dir has changed.
Instead of making $GIT_WORK_TREE absolute too, we just say "." and let
subsequence git processes handle it.
Reported-by: Michel Briand <michelbriand@free.fr>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
.gitignore | 1 +
Makefile | 1 +
setup.c | 8 ++++++++
t/t1501-worktree.sh | 11 +++++++++++
test-subprocess.c | 18 ++++++++++++++++++
5 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644 test-subprocess.c
diff --git a/.gitignore b/.gitignore
index 87b833c..3dd6ef7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -177,6 +177,7 @@
/test-sha1
/test-sigchain
/test-string-pool
+/test-subprocess
/test-svn-fe
/test-treap
/common-cmds.h
diff --git a/Makefile b/Makefile
index 57d9c65..bdf86a3 100644
--- a/Makefile
+++ b/Makefile
@@ -431,6 +431,7 @@ TEST_PROGRAMS_NEED_X += test-run-command
TEST_PROGRAMS_NEED_X += test-sha1
TEST_PROGRAMS_NEED_X += test-sigchain
TEST_PROGRAMS_NEED_X += test-string-pool
+TEST_PROGRAMS_NEED_X += test-subprocess
TEST_PROGRAMS_NEED_X += test-svn-fe
TEST_PROGRAMS_NEED_X += test-treap
TEST_PROGRAMS_NEED_X += test-index-version
diff --git a/setup.c b/setup.c
index 91887a4..3833569 100644
--- a/setup.c
+++ b/setup.c
@@ -239,6 +239,14 @@ void setup_work_tree(void)
git_dir = make_absolute_path(git_dir);
if (!work_tree || chdir(work_tree))
die("This operation must be run in a work tree");
+
+ /*
+ * Make sure subsequent git processes find correct worktree
+ * if $GIT_WORK_TREE is set relative
+ */
+ if (getenv(GIT_WORK_TREE_ENVIRONMENT))
+ setenv(GIT_WORK_TREE_ENVIRONMENT, ".", 1);
+
set_git_dir(make_relative_path(git_dir, work_tree));
initialized = 1;
}
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index 488160e..16c953b 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -343,4 +343,15 @@ test_expect_success 'make_relative_path handles double slashes in GIT_DIR' '
git --git-dir="$(pwd)//repo.git" --work-tree="$(pwd)" add dummy_file
'
+test_expect_success 'relative $GIT_WORK_TREE and git subprocesses' '
+ (
+ GIT_DIR=repo.git
+ GIT_WORK_TREE=repo.git/work
+ export GIT_DIR GIT_WORK_TREE
+ test-subprocess rev-parse --show-toplevel >actual &&
+ echo "`pwd`/repo.git/work" >expected &&
+ test_cmp expected actual
+ )
+'
+
test_done
diff --git a/test-subprocess.c b/test-subprocess.c
new file mode 100644
index 0000000..55ad719
--- /dev/null
+++ b/test-subprocess.c
@@ -0,0 +1,18 @@
+#include "cache.h"
+#include "run-command.h"
+
+int main(int argc, char **argv)
+{
+ const char *prefix;
+ struct child_process cp;
+ int nogit;
+
+ prefix = setup_git_directory_gently(&nogit);
+ if (nogit)
+ die("No git repo found");
+ setup_work_tree();
+ memset(&cp, 0, sizeof(cp));
+ cp.git_cmd = 1;
+ cp.argv = (const char **)argv+1;
+ return run_command(&cp);
+}
--
1.7.3.4.878.g439c7
^ permalink raw reply related
* [PATCH 1/2] t1501: avoid bashisms
From: Nguyễn Thái Ngọc Duy @ 2010-12-25 13:57 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Michel Briand, Nguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
t/t1501-worktree.sh | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/t/t1501-worktree.sh b/t/t1501-worktree.sh
index 2c8f01f..488160e 100755
--- a/t/t1501-worktree.sh
+++ b/t/t1501-worktree.sh
@@ -322,7 +322,10 @@ test_expect_success 'git grep' '
test_expect_success 'git commit' '
(
cd repo.git &&
- GIT_DIR=. GIT_WORK_TREE=work git commit -a -m done
+ GIT_DIR=. &&
+ GIT_WORK_TREE=work &&
+ export GIT_DIR GIT_WORK_TREE &&
+ git commit -a -m done
)
'
--
1.7.3.4.878.g439c7
^ permalink raw reply related
* Re: [PATCH 3/3] Fixes bug: GIT_PS1_SHOWDIRTYSTATE is no not respect diff.ignoreSubmodules config variable
From: Johannes Schindelin @ 2010-12-25 13:08 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Zapped, git
In-Reply-To: <4D15E48A.9050805@web.de>
Hi,
On Sat, 25 Dec 2010, Jens Lehmann wrote:
> In commit 37aea37 Dscho (CCed) introduced this configuration setting
> while explicitly stating that it only affects porcelain. As the other
> config options always influence porcelain and plumbing, it looks like we
> would want to have this option honored by plumbing too, no?
IIRC Junio was real happy that I did not honor plumbing.
Ciao,
Dscho
^ permalink raw reply
* Re: FIX/COMMENT: git remote manual page
From: Nguyen Thai Ngoc Duy @ 2010-12-25 13:00 UTC (permalink / raw)
To: Michel Briand; +Cc: git
In-Reply-To: <20101225124104.06a4f83c@eana.kheb.homelinux.org>
On Sat, Dec 25, 2010 at 6:41 PM, Michel Briand <michelbriand@free.fr> wrote:
> Hi,
>
> I'm running Debian squeeze. Git is version 1.7.2.3.
>
> Here is the complete command sequence I used:
>
> ~/tmp/git $ mkdir toto toto_wk
> ~/tmp/git $ GIT_DIR=toto GIT_WORK_TREE=toto_wk git init
Note that this also sets core.worktree=`cwd`/toto_wk so you only need
to set GIT_DIR in the following commands. But I wouldn't recommend it,
just set GIT_WORK_TREE the way you are doing, until maybe 1.7.4.
core.worktree is buggy.
> ~/tmp/git $ GIT_DIR=toto GIT_WORK_TREE=toto_wk git merge TOTO
> fatal: This operation must be run in a work tree
> fatal: read-tree failed
Thanks for the instructions. We've got a problem with $GIT_WORK_TREE
vs cwd here. I'll send a patch later.
> ~/tmp/git $ ls toto_wk/
> <NOTHING>
>
> I re-issue the latest command :
>
> ~/tmp/git $ GIT_DIR=toto GIT_WORK_TREE=toto_wk git merge TOTO
> Already up-to-date.
>
> Strange isn't it ?
Actually no. 'git-merge' is successful and its last step is to call
'git read-tree --reset -u SHA-1' to update worktree. Unfortunately,
git's internal cwd has been moved to ~/tmp/git/toto_wk while
$GIT_WORK_TREE is still "toto_wk". When git-read-tree is run, it tries
to find a worktree at ~/tmp/git/toto_wk/toto_wk.
> But directory is still empty
> ~/tmp/git $ ls toto_wk/
> <NOTHING>
Because git-read-tree fails to run.
> Trying to recover :
>
> ~/tmp/git $ GIT_DIR=toto GIT_WORK_TREE=toto_wk git reset --hard
Or you can try this until new git release:
GIT_DIR=toto GIT_WORK_TREE=$HOME/tmp/toto_wk git merge TOTO
or
GIT_DIR=toto git merge TOTO
In other words, making worktree absolute should work (core.worktree is
always set absolute by git-init).
--
Duy
^ permalink raw reply
* Re: [PATCH] close file on error in read_mmfile()
From: René Scharfe @ 2010-12-25 12:44 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Martin Ettl
In-Reply-To: <4D15E5D6.2040800@lsrfire.ath.cx>
Am 25.12.2010 13:38, schrieb René Scharfe:
> Reported in http://qa.debian.org/daca/cppcheck/sid/git_1.7.2.3-2.2.html.
Oh, and also in http://thread.gmane.org/gmane.comp.version-control.git/123042.
René
^ permalink raw reply
* [PATCH] close file on error in read_mmfile()
From: René Scharfe @ 2010-12-25 12:38 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Reported in http://qa.debian.org/daca/cppcheck/sid/git_1.7.2.3-2.2.html.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
xdiff-interface.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/xdiff-interface.c b/xdiff-interface.c
index cd2285d..cd9fa33 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -212,8 +212,10 @@ int read_mmfile(mmfile_t *ptr, const char *filename)
return error("Could not open %s", filename);
sz = xsize_t(st.st_size);
ptr->ptr = xmalloc(sz ? sz : 1);
- if (sz && fread(ptr->ptr, sz, 1, f) != 1)
+ if (sz && fread(ptr->ptr, sz, 1, f) != 1) {
+ fclose(f);
return error("Could not read %s", filename);
+ }
fclose(f);
ptr->size = sz;
return 0;
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH 3/3] Fixes bug: GIT_PS1_SHOWDIRTYSTATE is no not respect diff.ignoreSubmodules config variable
From: Jens Lehmann @ 2010-12-25 12:33 UTC (permalink / raw)
To: Zapped; +Cc: git, Johannes Schindelin
In-Reply-To: <1293240049-7744-3-git-send-email-zapped@mail.ru>
Am 25.12.2010 02:20, schrieb Zapped:
> Signed-off-by: Zapped <zapped@mail.ru>
> ---
> contrib/completion/git-completion.bash | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index d3037fc..50fc385 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -280,7 +280,8 @@ __git_ps1 ()
> elif [ "true" = "$(git rev-parse --is-inside-work-tree 2>/dev/null)" ]; then
> if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
> if [ "$(git config --bool bash.showDirtyState)" != "false" ]; then
> - git diff --no-ext-diff --quiet --exit-code || w="*"
> + is=$(git config diff.ignoreSubmodules)
> + git diff --no-ext-diff --quiet --exit-code --ignore-submodules=$is || w="*"
> if git rev-parse --quiet --verify HEAD >/dev/null; then
> git diff-index --cached --quiet HEAD -- || i="+"
> else
Thanks for resubmitting this as an inline patch for review (although
it would have been easier for me if the commit message would have
described the problem you tried to fix a bit more in detail ;-).
After testing this patch it looks like it has a few issues:
1) it will break any per-submodule configuration done via
the 'submodule.<name>.ignore' setting in .git/config or
.gitmodules, as using the --ignore-submodules option
overrides those while only setting 'diff.ignoreSubmodules'
should not do that.
2) If diff.ignoreSubmodules is unset it leads to an error
every time the prompt is displayed:
'fatal: bad --ignore-submodules argument:'
3) And for me it didn't change the behavior at all:
- The '*' in the prompt vanishes as I set diff.ignoreSubmodules
as expected with or without your patch.
Am I missing something here?
- The real problem here is that the '+' never goes away even
when 'diff.ignoreSubmodules' is set to 'all'. This is due
to the fact that 'diff.ignoreSubmodules' is only honored by
"git diff", but not by "git diff-index".
So the real issue here seems to be the "git diff-index" call, which
doesn't honor the 'diff.ignoreSubmodules' setting. In commit 37aea37
Dscho (CCed) introduced this configuration setting while explicitly
stating that it only affects porcelain. As the other config options
always influence porcelain and plumbing, it looks like we would want
to have this option honored by plumbing too, no?
So are there any reasons for the plumbing diff commands not to honor
the diff.ignoreSubmodules setting?
^ permalink raw reply
* Re: FIX/COMMENT: git remote manual page
From: Michel Briand @ 2010-12-25 11:41 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <AANLkTim_pHYEZ+7-Rm5N4Ycw2MTHD8AhvZrZqNhttkck@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> - Sat, 25 Dec 2010 17:48:58
+0700
>On Wed, Dec 22, 2010 at 8:15 AM, Michel Briand <michelbriand@free.fr> wrote:
>> Hello,
>>
>> I tried the example given at the bottom if the manual page of git
>> remote.
>>
>> · Imitate git clone but track only selected branches
>>
>> $ mkdir project.git
>> $ cd project.git
>> $ git init
>> $ git remote add -f -t master -m master origin git://example.com/git.git/
>> $ git merge origin
>>
>> It works like it is written.
>>
>> But it seems this does not work with my special setup:
>> - I use GIT_DIR and GIT_WORK_TREE to specify another location for my
>> repository, and to work from another directory,
>> - I name my remote with a custom name (not origin).
>
>So you set GIT_DIR and GIT_WORK_TREE before running "git remote add"?
>
Yes.
>> It fails at the last command :
>>
>> fatal: <my name> - not something we can merge
>
>It fails to see "<my name>" points to a commit. Maybe it fails to read
>remote information from config..
>
Huh, I don't know.
>> But if I try the command :
>>
>> git merge <my name>/master
>>
>> the error message is different :
>>
>> fatal: This operation must be run in a work tree
>> fatal: read-tree failed
>>
>> I cd to the work tree and issue the same last command.
>> Then it works.
>
>What git version are use using? I did
>
>GIT_DIR=git/.git GIT_WORK_TREE=git git/git merge origin # or a specific branch
>
>and it worked fine here (recent master). That message means work-tree
>settings are not propagated to git-read-tree (run by git-merge).
Hi,
I'm running Debian squeeze. Git is version 1.7.2.3.
Here is the complete command sequence I used:
~/tmp/git $ mkdir toto toto_wk
~/tmp/git $ GIT_DIR=toto GIT_WORK_TREE=toto_wk git init
Initialized empty Git repository in xxxxxxxxxxxxxxxx/tmp/git/toto/
~/tmp/git $ GIT_DIR=toto GIT_WORK_TREE=toto_wk git remote add -f -t master -m master TOTO xxxxxx/shlib
Updating TOTO
remote: Counting objects: 36, done.
remote: Compressing objects: 100% (32/32), done.
remote: Total 36 (delta 9), reused 0 (delta 0)
Unpacking objects: 100% (36/36), done.
From xxxxxxxxxxxxxxxxx/shlib
* [new branch] master -> TOTO/master
From xxxxxxxxxxxxxxxxx/shlib
* [new tag] 1.0 -> 1.0
* [new tag] 1.0.1 -> 1.0.1
~/tmp/git $ GIT_DIR=toto GIT_WORK_TREE=toto_wk git merge TOTO
fatal: This operation must be run in a work tree
fatal: read-tree failed
~/tmp/git $ ls toto_wk/
<NOTHING>
I re-issue the latest command :
~/tmp/git $ GIT_DIR=toto GIT_WORK_TREE=toto_wk git merge TOTO
Already up-to-date.
Strange isn't it ?
But directory is still empty
~/tmp/git $ ls toto_wk/
<NOTHING>
Trying to recover :
~/tmp/git $ GIT_DIR=toto GIT_WORK_TREE=toto_wk git reset --hard
The directory is correct (in sync with my master branch).
If I do :
...git init
...git remote add...
cd toto_wk
GIT_DIR=../toto GIT_WORK_TREE=. git merge TOTO
It works !
Adding /master after remote name doesn't make any difference. Please
forget this idea.
The problem seems to reside in the work tree parameter (. or not).
Cheers,
Michel
^ permalink raw reply
* Re: FIX/COMMENT: git remote manual page
From: Nguyen Thai Ngoc Duy @ 2010-12-25 10:48 UTC (permalink / raw)
To: Michel Briand; +Cc: git
In-Reply-To: <20101222021546.4b24c4e9@eana.kheb.homelinux.org>
On Wed, Dec 22, 2010 at 8:15 AM, Michel Briand <michelbriand@free.fr> wrote:
> Hello,
>
> I tried the example given at the bottom if the manual page of git
> remote.
>
> · Imitate git clone but track only selected branches
>
> $ mkdir project.git
> $ cd project.git
> $ git init
> $ git remote add -f -t master -m master origin git://example.com/git.git/
> $ git merge origin
>
> It works like it is written.
>
> But it seems this does not work with my special setup:
> - I use GIT_DIR and GIT_WORK_TREE to specify another location for my
> repository, and to work from another directory,
> - I name my remote with a custom name (not origin).
So you set GIT_DIR and GIT_WORK_TREE before running "git remote add"?
> It fails at the last command :
>
> fatal: <my name> - not something we can merge
It fails to see "<my name>" points to a commit. Maybe it fails to read
remote information from config..
> But if I try the command :
>
> git merge <my name>/master
>
> the error message is different :
>
> fatal: This operation must be run in a work tree
> fatal: read-tree failed
>
> I cd to the work tree and issue the same last command.
> Then it works.
What git version are use using? I did
GIT_DIR=git/.git GIT_WORK_TREE=git git/git merge origin # or a specific branch
and it worked fine here (recent master). That message means work-tree
settings are not propagated to git-read-tree (run by git-merge).
--
Duy
^ permalink raw reply
* Re: StandardInput Not Continuing Process
From: Tay Ray Chuan @ 2010-12-25 2:45 UTC (permalink / raw)
To: Chase Brammer; +Cc: git
In-Reply-To: <AANLkTikBdOLjzJxikXCwTs52RByfNZzKamK+F-JhY0mQ@mail.gmail.com>
On Thu, Dec 9, 2010 at 1:25 AM, Chase Brammer <cbrammer@gmail.com> wrote:
> For example, doing a clone from a HTTPS server may require a username/password.
> I writing the password as utf, and also tried just UTF byes (ie no
> prepended 16-bit int)
> but am unable to get the process to continue and start the clone process.
Try putting the username and password in ~/.netrc, or in the url with
https://user:pwd@foo.com/ - that way, you can skip the "input process"
altogether.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
From: Nguyen Thai Ngoc Duy @ 2010-12-25 2:20 UTC (permalink / raw)
To: Joshua Jensen; +Cc: Junio C Hamano, git
In-Reply-To: <4D14CFF2.9050705@workspacewhiz.com>
On Fri, Dec 24, 2010 at 11:53 PM, Joshua Jensen
<jjensen@workspacewhiz.com> wrote:
> As I recall (I'd have to examine other unsubmitted case insensitivity
> patches), merely adding case insensitivity support to ce_path_match() is not
> enough. The cache is stored alphabetically in a case sensitive fashion.
> That means filenames starting with 'A' are stored in a completely different
> place than filenames starting with 'a'. Certain parts of the code call
> ce_path_match() and then walk the cache sequentially for possible matches.
> It aborts long before hitting the 'a' filename.
Hmm.. what you describe sounds like never_interesting optimization in
tree_entry_interesting(). By the way do you still remember the parts
that it walk sequentially after ce_path_match() is matched?
> I have a patch that appears to resolve most of these issues. For
> core.ignorecase=true, when the cache is read, it is re-sorted alphabetically
> in a case insensitive manner. ce_path_match() still needs fixes, but the
> rest were covered by the case insensitive cache. 'A' and 'a' are not
> interleaved, and the combination of sequential and binary(?) searches Git
> uses are successful. Finally, when the cache is written, I re-sort the
> cache in a case insensitive fashion.
Resorting the cache is quite risky. Many parts of git depend on the
cache being sorted as it is now. Also if you go this way, then you
will also need to resort tree objects (git-log walks them directly).
--
Duy
^ permalink raw reply
* [PATCH 3/3] Fixes bug: GIT_PS1_SHOWDIRTYSTATE is no not respect diff.ignoreSubmodules config variable
From: Zapped @ 2010-12-25 1:20 UTC (permalink / raw)
To: git
In-Reply-To: <1293240049-7744-1-git-send-email-zapped@mail.ru>
Signed-off-by: Zapped <zapped@mail.ru>
---
contrib/completion/git-completion.bash | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d3037fc..50fc385 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -280,7 +280,8 @@ __git_ps1 ()
elif [ "true" = "$(git rev-parse --is-inside-work-tree 2>/dev/null)" ]; then
if [ -n "${GIT_PS1_SHOWDIRTYSTATE-}" ]; then
if [ "$(git config --bool bash.showDirtyState)" != "false" ]; then
- git diff --no-ext-diff --quiet --exit-code || w="*"
+ is=$(git config diff.ignoreSubmodules)
+ git diff --no-ext-diff --quiet --exit-code --ignore-submodules=$is || w="*"
if git rev-parse --quiet --verify HEAD >/dev/null; then
git diff-index --cached --quiet HEAD -- || i="+"
else
--
1.7.3.4.3.g3f811
^ permalink raw reply related
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