* Re: [RFC PATCH v7 2/9] gitweb: use eval + die for error (exception) handling
From: Jonathan Nieder @ 2010-12-23 2:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, J.H., John 'Warthog9' Hawley
In-Reply-To: <20101222235525.7998.99816.stgit@localhost.localdomain>
Jakub Narebski wrote:
> Gitweb assumes here that exceptions thrown by Perl would be simple
> strings; die_error() throws hash reference (if not for minimal
> extrenal dependencies, it would be probable object of Class::Exception
> or Throwable class thrown).
Hmm, why not throw an object of new type Gitweb::Exception?
> --- 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!
> # 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($@)) {
> + # 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.
>
> 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?
Thanks, I am happy to see the semantics becoming less thorny.
Jonathan
^ permalink raw reply
* Re: [PATCH 1/3] Makefile: add NO_FNMATCH_CASEFOLD to IRIX sections
From: Junio C Hamano @ 2010-12-23 4:00 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Brandon Casey
In-Reply-To: <jpN7nm-rtl4sNXi5qt9pXMafcDOI0AxF95o77x_r5JQwZeaH94BApUuIwonUaYfzmYTgqeFNpSm6S7VFnIZVag@cipher.nrlssc.navy.mil>
Thanks; I am unsure about the third one, though (see a separate message).
^ permalink raw reply
* Re: Using overlay filesystem for "other" files idea
From: Tomas Carnecky @ 2010-12-23 5:27 UTC (permalink / raw)
To: Evgeniy Ivanov; +Cc: git
In-Reply-To: <AANLkTi=f2MXoWE_Dx_thWb3VXGu-V-9cJAC8F_RzGAg=@mail.gmail.com>
On 12/23/10 12:02 AM, Evgeniy Ivanov wrote:
> Hello,
>
> I got following idea.
>
> If different branches seriously differ and you switch branches, then
> it's more likely you will loose most part of build files (e.g. when
> run build).
Use ccache.
> Also in projects that may have some bugs in build system (e.g. buggy
> makefiles) there is a chance you will not get clean build environment.
> E.g. somebody forgot to add include file as dependency in Makefile ---
> oops, you're in trouble.
Fix your Makefiles. Or run git clean, see below.
> Even without bugs in build system, some temp files are overwritten
> each time you run build for a custom branch.
>
> I think using overlays for other files can help much to solve this
> issue. You can have git repository in regular directory (like now) and
> overlay fs mounted over this repository (for each branch its own
> overlay).
> Another benefit is clearing source tree after build.
git clean -dfx.
Or use two different working trees. See contrib/workdir/git-new-workdir.
tom
^ permalink raw reply
* Re: git-svn author file and svn2cl compatibility
From: strk @ 2010-12-23 8:11 UTC (permalink / raw)
To: git
In-Reply-To: <20101222184110.GA53847@keybit.net>
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]
I attach a patch implementing the added support.
--strk;
On Wed, Dec 22, 2010 at 07:41:10PM +0100, strk wrote:
> The svn2cl tool [1] supports an author file to use for
> generating the ChangeLog.
>
> [1] http://arthurdejong.org/svn2cl/
>
> Format of the file is:
> nick1:Name <email>
> nick2:Name 2 <email2>
>
> It would be nice if git-svn could support the same format
> in addition to the one using ``='' instead of ``:''.
>
> That way you might have the authors file already available
> in projects that made use of svn2cl.
>
> Does it make sense ?
>
> Please include me in reply as I'm not subscribed.
[-- Attachment #2: 0001-Also-accept-svn2cl-format-for-authors-file.patch --]
[-- Type: text/plain, Size: 758 bytes --]
>From 0e6d6f3415b6d206e9cd8001ed4ce994e4150c39 Mon Sep 17 00:00:00 2001
From: Sandro Santilli <strk@keybit.net>
Date: Thu, 23 Dec 2010 09:07:10 +0100
Subject: [PATCH] Also accept svn2cl format for authors file
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 177dd25..6fd0f7f 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1424,7 +1424,7 @@ sub load_authors {
my $log = $cmd eq 'log';
while (<$authors>) {
chomp;
- next unless /^(.+?|\(no author\))\s*=\s*(.+?)\s*<(.+)>\s*$/;
+ next unless /^(.+?|\(no author\))\s*[=:]\s*(.+?)\s*<(.+)>\s*$/;
my ($user, $name, $email) = ($1, $2, $3);
if ($log) {
$Git::SVN::Log::rusers{"$name <$email>"} = $user;
--
1.7.0.4
^ permalink raw reply related
* Re: Expected behaviour of 'git log -S' when searching in a merged/deleted file?
From: Jonathan del Strother @ 2010-12-23 9:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vzkrx4qp6.fsf@alter.siamese.dyndns.org>
On 22 December 2010 18:17, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan del Strother <jdelstrother@gmail.com> writes:
>
>> I was trying to find a particular string in my project this morning.
>> 'git grep mystring' suggested that the string didn't exist in my repo,
>> but 'git log -Smystring' turned up a single commit that had added it.
>> It took me a long time to figure out that in the past, a branch had
>> added that string to foo.c, but a second branch deleted foo.c, and the
>> two branches were later merged (deleting foo.c and ignoring mystring).
>
> This is a typical case of the history simplification in action, isn't it?
>
> "log" will give you one possible and simplest explanation of how the
> project came into the current shape. Because side branches with changes
> that were discarded before merging it to the history that lead to the
> commit you run "log" from do not contribute anything to the end result,
> "log" will not traverse the entire side branch when it sees the merge.
I don't follow ... 'log' isn't showing me how the project came into
it's current shape. In the test case I posted, for example, it's
showing me that 'needle' was added to the repository at some point,
but it neglects to mention that it was removed. If 'needle' was added
and removed within the duration of a single branch, I could understand
"git log -S" never finding 'needle' due to history simplication, but I
don't understand how simplification applies here.
>
> Try your "log" with --full-history, perhaps?
Doesn't seem to affect the output in this case.
^ permalink raw reply
* Re: Using overlay filesystem for "other" files idea
From: Evgeniy Ivanov @ 2010-12-23 9:53 UTC (permalink / raw)
To: Tomas Carnecky; +Cc: git
In-Reply-To: <4D12DDD5.4050103@dbservice.com>
Thank you Tom, that's what I wanted.
On Thu, Dec 23, 2010 at 8:27 AM, Tomas Carnecky <tom@dbservice.com> wrote:
> On 12/23/10 12:02 AM, Evgeniy Ivanov wrote:
>>
>> Hello,
>>
>> I got following idea.
>>
>> If different branches seriously differ and you switch branches, then
>> it's more likely you will loose most part of build files (e.g. when
>> run build).
>
> Use ccache.
>>
>> Also in projects that may have some bugs in build system (e.g. buggy
>> makefiles) there is a chance you will not get clean build environment.
>> E.g. somebody forgot to add include file as dependency in Makefile ---
>> oops, you're in trouble.
>
> Fix your Makefiles. Or run git clean, see below.
>>
>> Even without bugs in build system, some temp files are overwritten
>> each time you run build for a custom branch.
>>
>> I think using overlays for other files can help much to solve this
>> issue. You can have git repository in regular directory (like now) and
>> overlay fs mounted over this repository (for each branch its own
>> overlay).
>> Another benefit is clearing source tree after build.
>
> git clean -dfx.
>
>
> Or use two different working trees. See contrib/workdir/git-new-workdir.
>
> tom
>
>
>
--
Evgeniy Ivanov
^ permalink raw reply
* Re: [PATCH 1/3] Makefile: add NO_FNMATCH_CASEFOLD to IRIX sections
From: Brandon Casey @ 2010-12-23 15:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brandon Casey
In-Reply-To: <7v1v593zqm.fsf@alter.siamese.dyndns.org>
On 12/22/2010 10:00 PM, Junio C Hamano wrote:
> Thanks; I am unsure about the third one, though (see a separate message).
I haven't received a separate message about the 3rd patch.
Not sure if you sent it out yet, but fyi.
-Brandon
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
From: Heiko Voigt @ 2010-12-23 15:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlj3i5zz9.fsf@alter.siamese.dyndns.org>
Hi,
On Tue, Dec 21, 2010 at 05:59:54PM -0800, Junio C Hamano wrote:
> * hv/mingw-fs-funnies (2010-12-14) 5 commits
> - mingw_rmdir: set errno=ENOTEMPTY when appropriate
> - mingw: add fallback for rmdir in case directory is in use
> - mingw: make failures to unlink or move raise a question
> - mingw: work around irregular failures of unlink on windows
> - mingw: move unlink wrapper to mingw.c
>
> Can somebody remind me what the status of this series is?
Still dicussing and preparing a new series. I hope I will get to answer
and send the new series soon.
Cheers Heiko
^ permalink raw reply
* Re: Expected behaviour of 'git log -S' when searching in a merged/deleted file?
From: Junio C Hamano @ 2010-12-23 16:03 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Git Mailing List
In-Reply-To: <AANLkTim4z3XvpjnEERuXgTE6CtA7D-dnBxSUgO3mE-FM@mail.gmail.com>
Jonathan del Strother <jdelstrother@gmail.com> writes:
> .... If 'needle' was added
> and removed within the duration of a single branch, I could understand
> "git log -S" never finding 'needle' due to history simplication, but I
> don't understand how simplification applies here.
Ahh, sorry, I misunderstood the scenario. Just like you do not see a
patch output from "log -p", the diff machinery (including -S and its newer
cousin -G) does not kick in by default for merge commits (this is a bit of
white lie as "log -p" defaults to "combine diff", i.e. be silent on any
uninteresting merge that takes its results literally from either parent).
Please try it with "-m" (not "--full-history"). We _might_ want to change
this behaviour for -S/-G but it needs a bit more thought.
^ permalink raw reply
* Re: [PATCH 3/3] t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
From: Junio C Hamano @ 2010-12-23 16:05 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, Brandon Casey
In-Reply-To: <jpN7nm-rtl4sNXi5qt9pXHOvlLOZP9xRq2h9eZev444l6GTi02jDn5C-Llxwsz3_tVhVKGvU5Vryto5cM6uchw@cipher.nrlssc.navy.mil>
This still leaves --no-bcc, --no-to and --no-cc in "no-foo overrides
sendemail.foo" tests, it seems. Do they also need to be fixed?
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
From: Nguyen Thai Ngoc Duy @ 2010-12-23 16:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlj3i5zz9.fsf@alter.siamese.dyndns.org>
On Wed, Dec 22, 2010 at 8:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
> * nd/struct-pathspec (2010-12-15) 21 commits
> ...
> (this branch is used by en/object-list-with-pathspec.)
>
> Rerolled again. Getting nicer by the round ;-)
With jj/icase-directory merged to master, match_pathspec() and
match_pathspec_depth() now diverse again.
When I wrote match_pathspec_depth(), I assumed that match_pathspec()
would not change much and I would have more time for converting the
rest of git to use match_*_depth(). Looks like I need to add case
insensitive matching to struct pathspec and friends then remove
match_pathspec() in this series too. At least if somebody changes
match_pathspec() again, it would cause a conflict so I can catch it.
--
Duy
^ permalink raw reply
* Re: [PATCH 3/3] t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
From: Brandon Casey @ 2010-12-23 16:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Brandon Casey
In-Reply-To: <7vlj3g326l.fsf@alter.siamese.dyndns.org>
On 12/23/2010 10:05 AM, Junio C Hamano wrote:
> This still leaves --no-bcc, --no-to and --no-cc in "no-foo overrides
> sendemail.foo" tests, it seems. Do they also need to be fixed?
No, those are handled completely separately. The --chainreplyto
option is a boolean option, and the '--no' prefix is an automatic
feature that is provided by Getopt::Long for boolean options (i.e.
those suffixed with '!').
The three options you mentioned are actually distinct options that
are configured in the call to GetOptions and are named so that they
appear to be 'no-' prefixed automatic versions of --bcc, --to, and
--cc, just like the boolean options. But there is really just a
separate option named --no-bcc, that sets the variable $no_bcc that
is distinct from the --bcc option which populates @bcclist.
So, people with a somewhat old Getopt::Long (or those accustomed
to prefixing '--no' without the dash) may get confused when they
have to leave off the dash when negating --chainreplyto as
--nochainreplyto, but _must_ use the dash when typing --no-bcc.
If we want to be consistent with Getopt::Long which accepts both
'--no-' and '--no', then we could add --nobcc, --noto, and --nocc.
Not sure if it's worth the trouble.
-Brandon
^ permalink raw reply
* Re: StandardInput Not Continuing Process
From: Chase Brammer @ 2010-12-23 16:55 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTikBdOLjzJxikXCwTs52RByfNZzKamK+F-JhY0mQ@mail.gmail.com>
Bump, any ideas?
Chase
On Wed, Dec 8, 2010 at 10:25 AM, Chase Brammer <cbrammer@gmail.com> wrote:
>
> I am try to directly interact with Git by using only stdin, stdout,
> and stderr. So
> not going through a terminal at all, but calling Git directly. I am
> having an issue
> with being able to continue a process that requires input.
>
> 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.
>
> Is there some signal, or trick to getting the process to continue? I
> thought that sending a
> "\n" would work, but that doesn't seem to be working either.
>
> Thanks for any help!
>
> Chase
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
From: Junio C Hamano @ 2010-12-23 17:17 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <AANLkTinH0h5euL=_wMpGirVEEYgoA9hXGhKGja9oPa2j@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Wed, Dec 22, 2010 at 8:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * nd/struct-pathspec (2010-12-15) 21 commits
>> ...
>> (this branch is used by en/object-list-with-pathspec.)
>>
>> Rerolled again. Getting nicer by the round ;-)
>
> With jj/icase-directory merged to master, match_pathspec() and
> match_pathspec_depth() now diverse again.
>
> When I wrote match_pathspec_depth(), I assumed that match_pathspec()
> would not change much and I would have more time for converting the
> rest of git to use match_*_depth(). Looks like I need to add case
> insensitive matching to struct pathspec and friends then remove
> match_pathspec() in this series too. At least if somebody changes
> match_pathspec() again, it would cause a conflict so I can catch it.
While this topic is something I have long wanted to see, I have started
feeling that this needs to cook a bit longer than be in the next release.
So perhaps the best course of action might be to rebase the series once
after the 1.7.4 feature freeze, cook it in 'next' for a while and make it
part of the release after that. I think at that point we may probably
want to have other changes that are not strictly backward compatible but
their incompatibilities do not matter in practice (e.g. cquoting pathspecs
in the attributes file comes to mind, but I am sure there will be other
changes that people wanted to have but we held them off due to worries on
compatibility).
What do you think?
^ permalink raw reply
* Re: StandardInput Not Continuing Process
From: Junio C Hamano @ 2010-12-23 17:20 UTC (permalink / raw)
To: Chase Brammer; +Cc: git
In-Reply-To: <AANLkTikvrDWYT8h_MCESd9sg4_8ykSOq3XFEsoNsYDuZ@mail.gmail.com>
Certain things do want a real user sitting at the terminal (or GUI) even
when the standard streams are connected elsewhere, and password input
is one of the obvious things that would explicitly want to read from the
tty.
Perhaps driving whatever script you are writing via "expect" would work?
^ permalink raw reply
* Re: StandardInput Not Continuing Process
From: Brian Gernhardt @ 2010-12-23 17:18 UTC (permalink / raw)
To: Chase Brammer; +Cc: git
In-Reply-To: <AANLkTikvrDWYT8h_MCESd9sg4_8ykSOq3XFEsoNsYDuZ@mail.gmail.com>
OnOn Wed, Dec 8, 2010 at 10:25 AM, Chase Brammer <cbrammer@gmail.com> wrote:
>
> I am try to directly interact with Git by using only stdin, stdout,
> and stderr. So
> not going through a terminal at all, but calling Git directly. I am
> having an issue
> with being able to continue a process that requires input.
>
> 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.
>
> Is there some signal, or trick to getting the process to continue? I
> thought that sending a
> "\n" would work, but that doesn't seem to be working either.
Depending on what language you're using and your pipe settings, you might need to issue an fflush(git_stdin).
~~ Brian
^ permalink raw reply
* Re: Expected behaviour of 'git log -S' when searching in a merged/deleted file?
From: Jonathan del Strother @ 2010-12-23 17:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vwrn0328p.fsf@alter.siamese.dyndns.org>
On 23 December 2010 16:03, Junio C Hamano <gitster@pobox.com> wrote:
> Jonathan del Strother <jdelstrother@gmail.com> writes:
>
>> .... If 'needle' was added
>> and removed within the duration of a single branch, I could understand
>> "git log -S" never finding 'needle' due to history simplication, but I
>> don't understand how simplification applies here.
>
> Ahh, sorry, I misunderstood the scenario. Just like you do not see a
> patch output from "log -p", the diff machinery (including -S and its newer
> cousin -G) does not kick in by default for merge commits (this is a bit of
> white lie as "log -p" defaults to "combine diff", i.e. be silent on any
> uninteresting merge that takes its results literally from either parent).
>
> Please try it with "-m" (not "--full-history"). We _might_ want to change
> this behaviour for -S/-G but it needs a bit more thought.
>
Yep, '-m' produces the expected (or at least, *my* expected) results.
^ permalink raw reply
* [PATCH] lib-git-svn.sh: Move web-server handling code into separate function
From: Ramsay Jones @ 2010-12-23 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list
This library file is currently sourced by 57 test files, of which
only four may (optionally) start a web-server in order to access
the svn repo via an http url, rather than a file url.
In addition to isolating the current web-server handling code from
the majority of tests, in a new prepare_httpd function, we also
add some error checking and reporting code to validate the apache
installation. Only those tests which attempt to start the web-
server, by calling start_httpd, will execute this code.
Note that it is important for start_httpd to return an error
indication, if prepare_httpd fails, so that the failure to use
the web-server, as requested by the user, should not go unnoticed.
(Unless the svnrepo variable is set to an http url at the end of
start_httpd, the remaining tests will use file urls, without
comment.)
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Hi Junio,
Sorry for taking so long on this, I've been somewhat busy this week.
This is the patch I promised, except that I decided not to squash
all of the previous lib-git-svn.sh patches. This replaces the
"lib-git-svn.sh: Add check for mis-configured web server variables"
patch in the rj/maint-test-fixes branch. (ie. patches #4 and #5, but
not #3, from the original series)
Hope that makes sense! :-P
ATB,
Ramsay Jones
t/lib-git-svn.sh | 36 +++++++++++++++++++++++++-----------
1 files changed, 25 insertions(+), 11 deletions(-)
diff --git a/t/lib-git-svn.sh b/t/lib-git-svn.sh
index 919d45a..199f22c 100644
--- a/t/lib-git-svn.sh
+++ b/t/lib-git-svn.sh
@@ -68,8 +68,7 @@ svn_cmd () {
svn "$orig_svncmd" --config-dir "$svnconf" "$@"
}
-if test -n "$SVN_HTTPD_PORT"
-then
+prepare_httpd () {
for d in \
"$SVN_HTTPD_PATH" \
/usr/sbin/apache2 \
@@ -81,6 +80,11 @@ then
break
fi
done
+ if test -z "$SVN_HTTPD_PATH"
+ then
+ echo >&2 '*** error: Apache not found'
+ return 1
+ fi
for d in \
"$SVN_HTTPD_MODULE_PATH" \
/usr/lib/apache2/modules \
@@ -92,20 +96,18 @@ then
break
fi
done
-fi
-
-start_httpd () {
- repo_base_path="$1"
- if test -z "$SVN_HTTPD_PORT"
+ if test -z "$SVN_HTTPD_MODULE_PATH"
then
- echo >&2 'SVN_HTTPD_PORT is not defined!'
- return
+ echo >&2 '*** error: Apache module dir not found'
+ return 1
fi
- if test -z "$repo_base_path"
+ if test ! -f "$SVN_HTTPD_MODULE_PATH/mod_dav_svn.so"
then
- repo_base_path=svn
+ echo >&2 '*** error: Apache module "mod_dav_svn" not found'
+ return 1
fi
+ repo_base_path="${1-svn}"
mkdir "$GIT_DIR"/logs
cat > "$GIT_DIR/httpd.conf" <<EOF
@@ -122,12 +124,24 @@ LoadModule dav_svn_module $SVN_HTTPD_MODULE_PATH/mod_dav_svn.so
SVNPath "$rawsvnrepo"
</Location>
EOF
+}
+
+start_httpd () {
+ if test -z "$SVN_HTTPD_PORT"
+ then
+ echo >&2 'SVN_HTTPD_PORT is not defined!'
+ return
+ fi
+
+ prepare_httpd "$1" || return 1
+
"$SVN_HTTPD_PATH" -f "$GIT_DIR"/httpd.conf -k start
svnrepo="http://127.0.0.1:$SVN_HTTPD_PORT/$repo_base_path"
}
stop_httpd () {
test -z "$SVN_HTTPD_PORT" && return
+ test ! -f "$GIT_DIR/httpd.conf" && return
"$SVN_HTTPD_PATH" -f "$GIT_DIR"/httpd.conf -k stop
}
--
1.7.3
^ permalink raw reply related
* [PATCH] msvc: Fix compilation error due to missing mktemp() declaration
From: Ramsay Jones @ 2010-12-23 19:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: GIT Mailing-list, kusmabite
Commit d1b6e6e (win32: use our own dirent.h, 2010-11-23) removed
the compat/vcbuild/include/dirent.h compatibility header file.
This file, among other things, included the <io.h> system header
file which provides the declaration of the mktemp() function.
In order to fix the compilation error, we add an include directive
for <io.h> to the compat/vcbuild/include/unistd.h header. (The
MinGW build includes <io.h> from it's <unistd.h> header too.)
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
compat/vcbuild/include/unistd.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/compat/vcbuild/include/unistd.h b/compat/vcbuild/include/unistd.h
index b14fcf9..a61160f 100644
--- a/compat/vcbuild/include/unistd.h
+++ b/compat/vcbuild/include/unistd.h
@@ -1,6 +1,8 @@
#ifndef _UNISTD_
#define _UNISTD_
+#include <io.h>
+
/* Win32 define for porting git*/
#ifndef _MODE_T_
--
1.7.3
^ permalink raw reply related
* Re: Dangerous "git am --abort" behavior
From: Steven E. Harris @ 2010-12-23 22:06 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTikUn+Mco3YeJ7Rj=xZrr1H5xr1Z0=cknf1MdCqC@mail.gmail.com>
Adam Monsen <haircut@gmail.com> writes:
> That's a good way to keep tabs on whether you're in the middle of a
> rebase or am (as well as many other statuses).
How so? How are you using it for this purpose?
--
Steven E. Harris
^ permalink raw reply
* Re: Dangerous "git am --abort" behavior
From: Junio C Hamano @ 2010-12-23 22:32 UTC (permalink / raw)
To: Steven E. Harris; +Cc: git
In-Reply-To: <m2tyi45ell.fsf@Spindle.sehlabs.com>
"Steven E. Harris" <seh@panix.com> writes:
> Adam Monsen <haircut@gmail.com> writes:
>
>> That's a good way to keep tabs on whether you're in the middle of a
>> rebase or am (as well as many other statuses).
>
> How so? How are you using it for this purpose?
There is this gem in the completion script:
# 3) Consider changing your PS1 to also show the current branch:
# PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
With this, you will see something like:
[junio@alter git.git (master|AM)]$
as your prompt while you are working to fix corrupt patch you tried but
failed to apply.
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2010, #06; Tue, 21)
From: Joshua Jensen @ 2010-12-23 23:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vfwto2ytb.fsf@alter.siamese.dyndns.org>
----- Original Message -----
From: Junio C Hamano
Date: 12/23/2010 10:17 AM
> Nguyen Thai Ngoc Duy<pclouds@gmail.com> writes:
>
>> On Wed, Dec 22, 2010 at 8:59 AM, Junio C Hamano<gitster@pobox.com> wrote:
>> With jj/icase-directory merged to master, match_pathspec() and
>> match_pathspec_depth() now diverse again.
>>
>> When I wrote match_pathspec_depth(), I assumed that match_pathspec()
>> would not change much and I would have more time for converting the
>> rest of git to use match_*_depth(). Looks like I need to add case
>> insensitive matching to struct pathspec and friends then remove
>> match_pathspec() in this series too. At least if somebody changes
>> match_pathspec() again, it would cause a conflict so I can catch it.
> While this topic is something I have long wanted to see, I have started
> feeling that this needs to cook a bit longer than be in the next release.
> So perhaps the best course of action might be to rebase the series once
> after the 1.7.4 feature freeze, cook it in 'next' for a while and make it
> part of the release after that. I think at that point we may probably
> want to have other changes that are not strictly backward compatible but
> their incompatibilities do not matter in practice (e.g. cquoting pathspecs
> in the attributes file comes to mind, but I am sure there will be other
> changes that people wanted to have but we held them off due to worries on
> compatibility).
>
> What do you think?
Certainly, you know what's best overall for Git.
Having said that, I have had 100 people using the jj/icase-directory
series on Windows daily for 4 months now without issue. Prior to that,
a majority of the series had been used for a full year by a dozen
people. In any case, the improvement on non-case sensitive file systems
is the difference between night and day, and the series has helped
prevent a number of messes that occurred without it (git add readme.txt
and git add Readme.txt, for example... ugh...).
More than Windows, this series also affects Mac OS X in a positive
manner, though the case sensitivity problems can be considered worse.
When you change directories at the command line, the command line
retains the case you used to change directory, and then Git uses that
case as the relative path into the repository. Ugh... this is different
than on Windows where the file system's directory case is retained at
the Command Prompt as you change directories. (Cygwin actually appears
to have the problem, too, but MinGW, what msysGit is built upon, does not.)
The Mac OS X issue listed above is not a reason not to publish the
series, though, as the fixes necessary to make that work are in
completely different areas in Git than the current jj/icase-directory
series.
Finally, I'm sitting on a bunch of other case sensitivity refinements,
but I'd like to get one series published before evolving this more. I'd
like to get the other ones out there for discussion, but they build on
the current series.
In reference to above, where is match_pathspec_depth()? I can only find
match_pathspec().
Josh
^ permalink raw reply
* Re: Dangerous "git am --abort" behavior
From: Steven E. Harris @ 2010-12-24 0:24 UTC (permalink / raw)
To: git
In-Reply-To: <7vtyi415oo.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> There is this gem in the completion script:
Thanks. I use zsh, and didn't want to force zsh to load the bash
completion scripts. After fumbling around first with the "vcs_info"
facility from zshcontrib, which worked acceptably, I found the
"zsh-git-prompt" project¹, integrated that, and am now amazed.
Footnotes:
¹ https://github.com/olivierverdier/zsh-git-prompt
--
Steven E. Harris
^ permalink raw reply
* Allow empty commits to be rebased
From: Mihai Rusu @ 2010-12-24 0:48 UTC (permalink / raw)
To: git
Hi
When trying to rebase empty Git commits (git commit --allow-empty),
"git rebase" (and "git rebase -i") just skip the empty commits. This
may make some sense in the context of "git rebase" trying to determine
if the code to be rebased already exists in "upstream" but in our case
we need to rebase purely because of parent changes. Playing with "git
rebase", the only way to force it to rebase empty commits was to do
something like:
$ git rebase -i --onto upstream HEAD~N # where N is the number of
commits we want rebased
And then for every empty commit it stops as if it got a conflict, I
have to issue git commit --allow-empty and then git rebase --continue
(if I just run git rebase --continue as I should it skips the empty
commit). If I drop "-i" or if I don't use the onto/HEAD~N trick I'm
not able to rebase empty commits.
If you don't think that "git rebase" should support rebasing of empty
commits by default then please consider adding an --allow-empty
argument to enable such functionality.
Thanks!
--
Mihai Rusu
^ permalink raw reply
* Re: [PATCH] msvc: Fix compilation error due to missing mktemp() declaration
From: Erik Faye-Lund @ 2010-12-24 1:00 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <4D139D91.8080503@ramsay1.demon.co.uk>
On Thu, Dec 23, 2010 at 8:05 PM, Ramsay Jones
<ramsay@ramsay1.demon.co.uk> wrote:
>
> Commit d1b6e6e (win32: use our own dirent.h, 2010-11-23) removed
> the compat/vcbuild/include/dirent.h compatibility header file.
> This file, among other things, included the <io.h> system header
> file which provides the declaration of the mktemp() function.
>
> In order to fix the compilation error, we add an include directive
> for <io.h> to the compat/vcbuild/include/unistd.h header. (The
> MinGW build includes <io.h> from it's <unistd.h> header too.)
>
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
Thanks. But shouldn't this header be included in mingw.h (or perhaps
msvc.h) because of _get_osfhandle and _commit?
^ 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