* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Jan Hudec @ 2008-08-03 20:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Johannes Sixt, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807261613120.26810@eeepc-johanness>
On Sat, Jul 26, 2008 at 16:14:33 +0200, Johannes Schindelin wrote:
> When the program 'git' is in the PATH, the argv[0] is set to the basename.
> However, argv0_path needs the full path, so add a function to discover the
> program by traversing the PATH manually.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> So it is not easily possible to reuse this function in
> compat/mingw.c, as Junio said that compat/ should not depend
> (at least too much) on libgit.a.
>
> Of course, we could try to follow a symlinked git, too, but I
> think this is overkill until someone proves me wrong.
On UNIX, not only that argv[0] can contain the program without path -- it can
contain anything the user thinks of. However most systems provide some way to
get the path of the executable. On Linux (and some other unices, but not all
of them) a reliable way is to readlink("/proc/self/exe", ...). Maybe since
it's only needed for resolving a relative exec dir, relative exec dir could
be supported only on systems that have such method (which is most of them).
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Junio C Hamano @ 2008-08-03 20:43 UTC (permalink / raw)
To: Jan Hudec; +Cc: Johannes Schindelin, Steffen Prohaska, Johannes Sixt, git
In-Reply-To: <20080803202513.GC3482@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
> On UNIX, not only that argv[0] can contain the program without path -- it can
> contain anything the user thinks of.... Maybe since
> it's only needed for resolving a relative exec dir, relative exec dir could
> be supported only on systems that have such method (which is most of them).
The "relocatable install" itself is not usually a common concept in the
UNIX world, and I do not think this matters anyway.
^ permalink raw reply
* Re: [PATCH] git-name-rev: don't use printf without format
From: Junio C Hamano @ 2008-08-03 20:44 UTC (permalink / raw)
To: René Scharfe; +Cc: Pieter de Bie, Git Mailinglist, Johannes Schindelin
In-Reply-To: <4895B641.1050500@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> printf() without an explicit format string is not a good coding practise,
> unless the printed string is guaranteed to not contain percent signs. While
> fixing this, we might as well combine the calls to fwrite() and printf().
Good catch; I should have caught it when I applied the "split overlong
function" patch, but I apparently was blind.
Thanks.
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: Johannes Schindelin @ 2008-08-03 20:48 UTC (permalink / raw)
To: Jan Hudec; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <20080803183749.GA3482@efreet.light.src>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2401 bytes --]
Hi,
On Sun, 3 Aug 2008, Jan Hudec wrote:
> On Wed, Jul 23, 2008 at 17:55:14 +0100, Johannes Schindelin wrote:
> > On Wed, 23 Jul 2008, Nguyen Thai Ngoc Duy wrote:
> > > On 7/23/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > On Wed, 23 Jul 2008, Nguyễn Thái Ngọc Duy wrote:
> > > >
> > > > > So in short, sparse prefix will be stored in config,
> > > > > core.sparsecheckout.
> > > >
> > > > Do you really think the prefix should be stored anywhere else than
> > > > the index?
> > > >
> > > > With core.sparseCheckout you have to introduce a _sh*tload_ of
> > > > config loaders.
> > > >
> > > > And with core.sparseCheckout you are at the whim of the user,
> > > > since .git/config is _supposed_ to be user-editable.
> > > >
> > > > From a logical point of view, I'd say that the sparse prefix has
> > > > nothing to do with the "configuration" of the local repository.
> > >
> > > Well, whatever place. I chose .git/config because I did not want to
> > > introduce a new config place. But then how about
> > > .git/sparsecheckout?
> >
> > No, I did mean the index. This is an attribute of the index: either
> > it is sparsely checked out or not. You can even have multiple indices
> > (switching between them by setting GIT_INDEX_FILE) which have
> > different prefixes.
>
> Um, but does the prefix we want to use depend on what files are
> physically present in the tree?
The thing is: in a checkout, the flow of data is
HEAD -> index -> worktree
To check in, the flow is exactly opposite.
There are also legal workflows where you do not work on the worktree at
all.
And there are legal workflows where you work with multiple
indices/worktrees.
Now, it appears pretty obvious to me that the logical thing is to tell the
(current) index what is supposed to be checked out and what not.
After all, a merge is done inside the index. And if the merge touches
parts outside of the sparse checkout, it is natural to have the index know
about it.
Because the merge _has_ to complain then.
In any case, isn't it clearly the more elegant solution to just put the
information into the index when you touch it _anyway_?
I am really puzzled why people think it is a good idea to separate the
file metadata from the information what files were checked out to begin
with, as if they were totally independent.
Because they are not.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] hash-object --no-filters
From: Junio C Hamano @ 2008-08-03 20:44 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Alexander Litvinov, git, Eric Wong
In-Reply-To: <20080803055602.GN7008@dpotapov.dyndns.org>
Very nicely done; will queue along with the 5 patch series.
Thanks.
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Junio C Hamano @ 2008-08-03 20:45 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: Eric Wong, Petr Baudis, git
In-Reply-To: <1217765241.6178.11.camel@heerbeest>
Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:
> Documentation/RelNotes-1.6.0.txt | 3 +
Nice try, but after -rc1 we won't take feature enhancements on the
'master' branch. The earliest this will appear is in 1.6.1.
Thanks for clean-up, and starting tests, but I have a few more comments:
* Documentation; introduce this with heading --clean-changelog=<style>; I
kept the list of supported styles in-line, but we may later want to
have other supported styles at which time it might become easier to
read if it were a separate itemized list.
You seem to have taken the "arbitrary Perl snippet" part of my patch as
well, but it is not described here...
* Script; two separate _clean_changelog and _clean_log_message variables
are not necessary (I removed the extra variable in the patch below).
* Tests.
Your new tests do not seem to check these, but I think you should:
- what should happen without --clean-changelog=gnu? (iow, additional
code does not regress the behaviour when this shiny new toy is not
used).
- what should happen when an unknown style is given e.g. --clean-changelog=yak?
We prefer to use "test_cmp" for comparing expected and actual result,
not bare "cmp".
Here is what I tested and based the above comments on after minor fixes to
ask comments from Eric.
-- >8 --
From: Jan Nieuwenhuizen <janneke@gnu.org>
Subject: git-svn: --clean-changelog=<style> to sanitize messages
Some projects write ChangeLog entries and use those for Subverison commit
messages. Converting such a repository makes for a most uninteresting git
log --pretty=oneline output:
482cfc6... 2008-08-01 Kohei Yoshida <kyoshida@novell.com>
90c16d7... 2008-08-01 Fong Lin <pflin@novell.com> * patches/dev300/cws-npow
...
The --clean-changelog=<style> option can be used to remove useless bits
when reading log messages from Subversion side, to produce more readable
result:
44e7784... patches/dev300/apply: added upstream issue numbers to some of my p
1a19026... patches/dev300/cws-npower11.diff: Add vba events stuff.
...
Signed-off-by: Jan Nieuwenhuizen <janneke@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/git-svn.txt | 4 +
git-svn.perl | 37 +++++++-
t/t9125-git-svn-clean-changelog.sh | 187 ++++++++++++++++++++++++++++++++++++
3 files changed, 227 insertions(+), 1 deletions(-)
create mode 100755 t/t9125-git-svn-clean-changelog.sh
diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index f230125..04b44c6 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -118,6 +118,10 @@ accept. However, '--fetch-all' only fetches from the current
Like 'git-rebase'; this requires that the working tree be clean
and have no uncommitted changes.
+--clean-changelog=<style>;;
+ Manipulate SVN commit log messages to produce clean commit
+ messages. Supported styles are: 'gnu', which strips
+ GNU ChangeLog bits.
-l;;
--local;;
Do not fetch remotely; only run 'git-rebase' against the
diff --git a/git-svn.perl b/git-svn.perl
index cf6dbbc..ff17457 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -66,7 +66,7 @@ my ($_stdin, $_help, $_edit,
$_version, $_fetch_all, $_no_rebase,
$_merge, $_strategy, $_dry_run, $_local,
$_prefix, $_no_checkout, $_url, $_verbose,
- $_git_format);
+ $_git_format, $_clean_changelog);
$Git::SVN::_follow_parent = 1;
my %remote_opts = ( 'username=s' => \$Git::SVN::Prompt::_username,
'config-dir=s' => \$Git::SVN::Ra::config_dir,
@@ -109,9 +109,11 @@ my %cmd = (
fetch => [ \&cmd_fetch, "Download new revisions from SVN",
{ 'revision|r=s' => \$_revision,
'fetch-all|all' => \$_fetch_all,
+ 'clean-changelog=s' => \$_clean_changelog,
%fc_opts } ],
clone => [ \&cmd_clone, "Initialize and fetch revisions",
{ 'revision|r=s' => \$_revision,
+ 'clean-changelog=s' => \$_clean_changelog,
%fc_opts, %init_opts } ],
init => [ \&cmd_init, "Initialize a repo for tracking" .
" (requires URL argument)",
@@ -178,6 +180,7 @@ my %cmd = (
'local|l' => \$_local,
'fetch-all|all' => \$_fetch_all,
'dry-run|n' => \$_dry_run,
+ 'clean-changelog=s' => \$_clean_changelog,
%fc_opts } ],
'commit-diff' => [ \&cmd_commit_diff,
'Commit a diff between two trees',
@@ -238,6 +241,35 @@ my $rv = GetOptions(%opts, 'help|H|h' => \$_help, 'version|V' => \$_version,
$Git::SVN::default_repo_id = $_[1] });
exit 1 if (!$rv && $cmd && $cmd ne 'log');
+my %canned_changelog_cleaner =
+(
+ 'gnu' => sub {
+ local ($_) = @_;
+ s/(^|\n)\s*((\n|\s)*(199[0-9]|20[0-1][0-9])(-[0-9]{2}){2}\s+.*<.*>\s*\n\s+)?/$1/g;
+ s/(^|\n)\* /\n$1/g;
+ s/^[\n\s]*//;
+ s/[\n\s]*$//;
+ s/\n\s*/ /g if length ($_) < 81;
+ $_ . "\n";
+ }
+);
+
+if (defined $_clean_changelog) {
+ my $ccl = $_clean_changelog;
+ if (exists $canned_changelog_cleaner{$_clean_changelog}) {
+ $_clean_changelog = $canned_changelog_cleaner{$_clean_changelog};
+ } elsif ($_clean_changelog ne '') {
+ $_clean_changelog = eval "
+ sub { local(\$_) = \@_; $_clean_changelog; return \$_; }
+ ";
+ if ($@) {
+ die "$!: $ccl";
+ }
+ } else {
+ die "$ccl: unknown way to clean log message";
+ }
+}
+
usage(0) if $_help;
version() if $_version;
usage(1) unless defined $cmd;
@@ -2463,6 +2495,9 @@ sub make_log_entry {
close $un or croak $!;
$log_entry{date} = parse_svn_date($log_entry{date});
+ if ($_clean_changelog) {
+ $log_entry{log} = $_clean_changelog->($log_entry{log});
+ }
$log_entry{log} .= "\n";
my $author = $log_entry{author} = check_author($log_entry{author});
my ($name, $email) = defined $::users{$author} ? @{$::users{$author}}
diff --git a/t/t9125-git-svn-clean-changelog.sh b/t/t9125-git-svn-clean-changelog.sh
new file mode 100755
index 0000000..f6a02b8
--- /dev/null
+++ b/t/t9125-git-svn-clean-changelog.sh
@@ -0,0 +1,187 @@
+#!/bin/sh
+#
+# Copyright (c) 2008 Jan Nieuwenhuizen <janneke@gnu.org>
+
+test_description='git-svn fetch --clean-changelog'
+
+. ./lib-git-svn.sh
+
+cat >dumpfile.svn <<\EOF
+SVN-fs-dump-format-version: 2
+
+UUID: 3e54420c-6148-11dd-bf80-b901c556354a
+
+Revision-number: 0
+Prop-content-length: 56
+Content-length: 56
+
+K 8
+svn:date
+V 27
+2008-08-03T10:38:00.279529Z
+PROPS-END
+
+Revision-number: 1
+Prop-content-length: 231
+Content-length: 231
+
+K 7
+svn:log
+V 128
+2008-08-03 Jan Nieuwenhuizen <janneke@gnu.org>
+
+ * one: New file. This adds the `one' file to the svn
+ repository.
+
+
+K 10
+svn:author
+V 7
+janneke
+K 8
+svn:date
+V 27
+2008-08-03T10:42:21.211246Z
+PROPS-END
+
+Node-path: one
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 4
+Text-content-md5: 5bbf5a52328e7439ae6e719dfe712200
+Content-length: 14
+
+PROPS-END
+one
+
+
+Revision-number: 2
+Prop-content-length: 217
+Content-length: 217
+
+K 7
+svn:log
+V 114
+2008-08-03 Jan Nieuwenhuizen <janneke@gnu.org>
+
+ * one: Change to numeral.
+ * /path/to/two (foo, bar): Update.
+
+
+K 10
+svn:author
+V 7
+janneke
+K 8
+svn:date
+V 27
+2008-08-03T10:47:11.023749Z
+PROPS-END
+
+Node-path: one
+Node-kind: file
+Node-action: change
+Text-content-length: 2
+Text-content-md5: b026324c6904b2a9cb4b88d6d61c81d1
+Content-length: 2
+
+1
+
+
+Node-path: two
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 4
+Text-content-md5: c193497a1a06b2c72230e6146ff47080
+Content-length: 14
+
+PROPS-END
+two
+
+
+Revision-number: 3
+Prop-content-length: 192
+Content-length: 192
+
+K 7
+svn:log
+V 90
+ * three: Add yet another commit that is too long to fit on one
+line, i.e., 81 chars.
+
+
+K 10
+svn:author
+V 7
+janneke
+K 8
+svn:date
+V 27
+2008-08-03T10:51:21.214317Z
+PROPS-END
+
+Node-path: three
+Node-kind: file
+Node-action: add
+Prop-content-length: 10
+Text-content-length: 6
+Text-content-md5: febe6995bad457991331348f7b9c85fa
+Content-length: 16
+
+PROPS-END
+three
+
+
+EOF
+
+test_expect_success 'load svn dumpfile' '
+ svnadmin load "$PWD/svnrepo" <dumpfile.svn
+'
+
+test_expect_success 'clone revision from svn' '
+ git-svn clone --clean-changelog=gnu -r0 "file://$PWD/svnrepo" test-git
+'
+
+test_expect_success 'fetch revision from svn' '
+ (cd test-git && git-svn fetch --clean-changelog=gnu)
+'
+
+test_expect_success 'rebase revision from svn' '
+ (cd test-git && git-svn rebase --clean-changelog=gnu)
+'
+
+test_expect_success 'get log' '
+ (cd test-git && git log | grep -Ev "^(commit|Author)" >git-log.output)
+'
+
+sed -e 's/|$//' >git-log.expect <<EOF
+Date: Sun Aug 3 10:51:21 2008 +0000
+
+ three: Add yet another commit that is too long to fit on one
+ line, i.e., 81 chars.
+ |
+ |
+ git-svn-id: file://$PWD/svnrepo@3 3e54420c-6148-11dd-bf80-b901c556354a
+
+Date: Sun Aug 3 10:47:11 2008 +0000
+
+ one: Change to numeral. /path/to/two (foo, bar): Update.
+ |
+ |
+ git-svn-id: file://$PWD/svnrepo@2 3e54420c-6148-11dd-bf80-b901c556354a
+
+Date: Sun Aug 3 10:42:21 2008 +0000
+
+ one: New file. This adds the \`one' file to the svn repository.
+ |
+ |
+ git-svn-id: file://$PWD/svnrepo@1 3e54420c-6148-11dd-bf80-b901c556354a
+EOF
+
+test_expect_success 'git svn clone/fetch --changelog=gnu' '
+ test_cmp git-log.expect test-git/git-log.output
+'
+
+test_done
--
1.6.0.rc1.58.g807d8
^ permalink raw reply related
* [PATCHv2] gitweb: ref markers link to named shortlogs
From: Giuseppe Bilotta @ 2008-08-03 20:48 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Giuseppe Bilotta
In-Reply-To: <20080803132050.GA10151@machine.or.cz>
This patch turns ref markers for tags and heads into links to
appropriate views for the ref name. Appropriate changes are made in the
CSS to prevent ref markers to be annoyingly blue and underlined.
For all git ref types it's assumed that the preferred view is named like
the ref type itself. For commits, we map the view to shortlog.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Following pasky's suggestion, the action used by the ref marker
is now determined from the ref type, default action to the ref type
itsef. Currently the only non-default action is shortlog for commit
refs, but the map can be expanded as needed.
gitweb/gitweb.css | 5 +++++
gitweb/gitweb.perl | 7 ++++++-
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.css b/gitweb/gitweb.css
index aa0eeca..2b43eea 100644
--- a/gitweb/gitweb.css
+++ b/gitweb/gitweb.css
@@ -481,6 +481,11 @@ span.refs span {
border-color: #ffccff #ff00ee #ff00ee #ffccff;
}
+span.refs span a {
+ text-decoration: none;
+ color: inherit;
+}
+
span.refs span.ref {
background-color: #aaaaff;
border-color: #ccccff #0033cc #0033cc #ccccff;
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 90cd99b..a12ce87 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1093,10 +1093,14 @@ sub format_log_line_html {
sub format_ref_marker {
my ($refs, $id) = @_;
my $markers = '';
+ my %view = (
+ "commit" => "shortlog",
+ );
if (defined $refs->{$id}) {
foreach my $ref (@{$refs->{$id}}) {
my ($type, $name) = qw();
+ my $git_type = git_get_type($ref);
# e.g. tags/v2.6.11 or heads/next
if ($ref =~ m!^(.*?)s?/(.*)$!) {
$type = $1;
@@ -1107,7 +1111,8 @@ sub format_ref_marker {
}
$markers .= " <span class=\"$type\" title=\"$ref\">" .
- esc_html($name) . "</span>";
+ $cgi->a({-href => href(action=>$view{$git_type} || $git_type, hash=>$name)}, $name) .
+ "</span>";
}
}
--
1.5.6.3
^ permalink raw reply related
* Re: Gitweb: Provide Git links in project list?
From: J.H. @ 2008-08-03 20:53 UTC (permalink / raw)
To: Robert Richter; +Cc: git
In-Reply-To: <20080730161126.GE31295@erda.amd.com>
Working on refactoring the patch so that it can go upstream, one of the
things I'm definitely making an assumption about (in my original code)
is that the base url will be uniform for the entire project_list (as it
is on kernel.org). If that's acceptable I will probably be able to
submit something today, if not I will need to muck about and read out
the url from .git/cloneurl (which would be a rather hefty performance
hit - needing to read that from each repository)
- John
On Wed, 2008-07-30 at 18:11 +0200, Robert Richter wrote:
> On 30.07.08 08:49:30, J.H. wrote:
> > That is a kernel.org specific change - if the community at large wants
> > it I can dig the patch out (I likely didn't do it as it's own patch when
> > I did it, being young, naive and stupid at the time - I'm now slightly
> > older and slightly less naive now ;-)
> >
> > But yeah - if people feel that's interesting I'm happy to rip it out
> > later today and submit it to the mailing list.
>
> John, I would like the patch.
>
> Yes, I have seen the commit as well and it is not the only change in
> this commit. Also, if I got it right, the repository is not taken from
> .git/cloneurl. So, with the current implementation the git url in the
> summary page may be different to cloneurl. But this is not a major
> issue.
>
> It would be great if you could provide a patch with your changes for
> gitweb.
>
> Thanks,
>
> -Robert
>
^ permalink raw reply
* Re: [PATCH] git-p4: chdir now properly sets PWD environment variable in msysGit
From: Junio C Hamano @ 2008-08-03 21:13 UTC (permalink / raw)
To: Robert Blum; +Cc: simon, shausman, marius, hanwen, gitster, git
In-Reply-To: <bad7471c0808011250v569ffaaby9e20a5ba1f971927@mail.gmail.com>
"Robert Blum" <rob.blum@gmail.com> writes:
> P4 on Windows expects the PWD environment variable to be set to the
> current working dir, but os.chdir in python doesn't do that by default
Missing full stop at the end of sentence aside, this comment makes me
wonder if there is an optional way to have it set it, as opposed to the
inconvenient way it behaves "by defualt". If there is none, I think your
patch, even though it looks ugly, is the least evil approach. Another way
might be to wrap callsites of system() by introducing a "run_p4" function,
like:
def run_p4(arg):
os.environ['PWD'] = os.getcwd() if os.name == 'nt'
return system(arg)
> ---
>
> Pushing it out to the list since I'm not entirely sure who the git-p4 owner
> even is. CC'ed likely suspects for ownership ;)
Thanks. I've been waiting for an Ack from somewhere or success reports
from p4 users on Windows.
^ permalink raw reply
* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Junio C Hamano @ 2008-08-03 21:21 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Steffen Prohaska, git, Björn Steinbrink
In-Reply-To: <1217793328.48960d306d2b7@webmail.nextra.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Zitat von Steffen Prohaska <prohaska@zib.de>:
> ...
>> The modified define works.
>>
>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>
> Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
>
> I was not aware that my version (block-scoped static function forward
> declaration) is not valid C. Thanks, Björn, for pointing out the gcc bugzilla
> entries.
Thanks all. Applied.
^ permalink raw reply
* Re: [PATCH] git-gui: update Japanese translation
From: Junio C Hamano @ 2008-08-03 21:24 UTC (permalink / raw)
To: しらいしななこ
Cc: Shawn O. Pearce, git
In-Reply-To: <20080803170150.6117@nanako3.lavabit.com>
しらいしななこ <nanako3@lavabit.com> writes:
> This updates Japanese translation to match the updated git-gui.pot.
>
> Signed-off-by: しらいしななこ <nanako3@lavabit.com>
Looks fine to me, thanks.
> ...
> -#: git-gui.sh:41 git-gui.sh:634 git-gui.sh:648 git-gui.sh:661 git-gui.sh:744
> -#: git-gui.sh:763
> +#: git-gui.sh:41 git-gui.sh:688 git-gui.sh:702 git-gui.sh:715 git-gui.sh:798
> +#: git-gui.sh:817
It makes me wonder if we can do something about these line number changes
appearing on the patch, though...
Yes, I know it is a useful piece of information for PO aware editors to
help translators, but still...
^ permalink raw reply
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: Shawn O. Pearce @ 2008-08-03 21:25 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: git
In-Reply-To: <489598C5.6060508@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> wrote:
> Shawn O. Pearce wrote:
>> +#define hex(a) (hexchar[(a) & 15])
>> +static void chunked_write(const char *fmt, ...)
>> +{
>
> Maybe I am slightly confused, but I thought handling HTTP chunking for
> HTTP/1.1+ clients was usually done by Apache above the level of the CGI
> script?
You may be right. Apache undoes the chunking during a POST before
feeding the data to the CGI script. If we can omit this mess of
code from git-http-backend that's a good thing.
Thanks for the sanity check.
--
Shawn.
^ permalink raw reply
* [PATCH] Use line buffering for standard output
From: Anders Melchiorsen @ 2008-08-03 21:26 UTC (permalink / raw)
To: git; +Cc: gitster, Anders Melchiorsen
Normally, stdout is fully buffered, unless it refers to a terminal
device. This gives problems when fork() is in play: the buffer is
cloned and output appears twice.
By always setting stdout to line buffering, we make the output work
identically for all output devices.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
On #git, blix mentioned that running git clone through a pipe made it
output the "Initialized empty" line twice. This seems to be due to
bad interactions between fork() and buffered stdio.
Rather than putting in flushing at all the right places, this
sledgehammer fix simply reverts to line buffering for all output devices.
Anders.
git.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/git.c b/git.c
index 37b1d76..040b900 100644
--- a/git.c
+++ b/git.c
@@ -421,6 +421,12 @@ int main(int argc, const char **argv)
int done_alias = 0;
/*
+ * Use line buffering, even if we do not have interactive
+ * output. Full buffering mixes badly with fork().
+ */
+ setvbuf(stdout, NULL, _IOLBF, 0);
+
+ /*
* Take the basename of argv[0] as the command
* name, and the dirname as the default exec_path
* if we don't have anything better.
--
1.5.6.4
^ permalink raw reply related
* Re: [PATCH] Use line buffering for standard output
From: Junio C Hamano @ 2008-08-03 21:38 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git
In-Reply-To: <1217798768-18021-1-git-send-email-mail@cup.kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> Normally, stdout is fully buffered, unless it refers to a terminal
> device. This gives problems when fork() is in play: the buffer is
> cloned and output appears twice.
I thought we have been careful to flush() them before we fork but perhaps
there are recent changes that were not careful. Wouldn't it be better to
fix them first, independent of this change?
^ permalink raw reply
* Re: [PATCH] Use line buffering for standard output
From: Linus Torvalds @ 2008-08-03 21:46 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git, gitster
In-Reply-To: <1217798768-18021-1-git-send-email-mail@cup.kalibalik.dk>
On Sun, 3 Aug 2008, Anders Melchiorsen wrote:
>
> Normally, stdout is fully buffered, unless it refers to a terminal
> device. This gives problems when fork() is in play: the buffer is
> cloned and output appears twice.
>
> By always setting stdout to line buffering, we make the output work
> identically for all output devices.
Please don't.
This is a huge peformance issue for things like
git log -p > file
where we really want it to be fully buffered.
So please just find the place where we do a fork() without flushing
pending output...
(We really shouldn't have all that many "fork()" calls left, I thought -
the Windows stuff means that most of it should be abstracted away. So it's
not like we're talking about hundreds of sites, there should be just a
couple).
Linus
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Junio C Hamano @ 2008-08-03 22:00 UTC (permalink / raw)
To: Jonas Fonseca
Cc: Petr Baudis, Jakub Narebski, Scott Chacon, Junio C Hamano, git
In-Reply-To: <2c6b72b30808030750w383ff4e9y8f9dbbc3b254722f@mail.gmail.com>
"Jonas Fonseca" <jonas.fonseca@gmail.com> writes:
> .... I
> am aware that the my current lack of involvement in git development
> (which is mostly limited to documentation improvements) and the
> resulting possible lack of trust from the community has limited its
> use....
Huh? Lack of trust? Don't be ridiculous to forget "tig".
^ permalink raw reply
* [RFH] - git-svn auth bug (possibly SVN 1.5.0-related)
From: Eric Wong @ 2008-08-03 22:02 UTC (permalink / raw)
To: Brad King; +Cc: git
In-Reply-To: <488B2FC5.4080801@kitware.com>
Brad King <brad.king@kitware.com> wrote:
> Eric Wong wrote:
> > Brad King <brad.king@kitware.com> wrote:
> >> Eric Wong wrote:
> >>> I haven't had the chance to look at this. Can anybody else shed more
> >>> light on that bug? It's really strange that the tests won't run because
> >>> of it. Are you unable to run some git-svn tests or all of them?
> >> Just that one fails. All others (including the one in the patch below) pass.
> >
> > Exactly which test fails for you? Perhaps it's some setting in your
> > ~/.subversion/config that's causing it to fail. Maybe we should set
> > $HOME and use a clean ~/.subversion/config for git-svn tests regardless
> > if that turns out to be the case...
>
> $ cd $gitsrc/t
> $ export SVNSERVE_PORT=5432
> $ ./t9113-git-svn-dcommit-new-file.sh
> * ok 1: start tracking an empty repo
> * FAIL 2: create files in new directory with dcommit
>
> mkdir git-new-dir &&
> echo hello > git-new-dir/world &&
> git update-index --add git-new-dir/world &&
> git commit -m hello &&
> start_svnserve &&
> git svn dcommit
>
> * failed 1 among 2 test(s)
>
> I hacked the test script to log the dcommit output to a file, and I see
> this:
>
> Committing to svn://127.0.0.1:5432 ...
> Use of uninitialized value in concatenation (.) or string at
> /usr/lib/perl5/SVN/Core.pm line 584.
> Authorization failed: at $gitsrc/t/../git-svn line 3329
>
> (I replaced my git source dir full path with $gitsrc).
>
> The version of libsvn-perl is: 1.5.0dfsg1-4
It could be another incompatibility introduced in SVN 1.5.0.
I'll try to dist-upgrade a machine to Lenny sometime in the next two
weeks so I can test; I'm pretty busy these days but if anybody else
wants to figure this out in the meantime, please do :)
> Please let me know if you need more info.
>
> I tried moving my ~/.subversion/config out of the way but it makes no
> difference. However, I agree we should block the user's home svn config
> when running other dcommit tests now that we have auto-props. Perhaps
> just using the --config-dir option with an empty directory would be enough.
Thanks for the additional info!
--
Eric Wong
^ permalink raw reply
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: Junio C Hamano @ 2008-08-03 22:16 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, H. Peter Anvin
In-Reply-To: <1217748317-70096-2-git-send-email-spearce@spearce.org>
I very much like it.
But could you be a bit more explicit than application/x-git-refs magic? I
suspect very strongly that clueless server operators would advertise the
type on repositories statically hosted there, and would defeat the point
of your patch.
We are not changing update-server-info so if we can find a place we can
use to hide the "magic", it would be a much more robust.
Perhaps "#" comment line in info/refs that is ignored on the reading side
but update-server-info never generates on its own?
Or perhaps sort the output differently from how update-server-info
produces its output, so that older client would not care but the magic
aware client can notice?
^ permalink raw reply
* Re: [PATCH] Use line buffering for standard output
From: Anders Melchiorsen @ 2008-08-03 22:48 UTC (permalink / raw)
To: Linus Torvalds, gitster; +Cc: git
In-Reply-To: <alpine.LFD.1.10.0808031444270.3668@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 3 Aug 2008, Anders Melchiorsen wrote:
>>
>> By always setting stdout to line buffering, we make the output work
>> identically for all output devices.
>
> Please don't.
>
> This is a huge peformance issue for things like
>
> git log -p > file
>
> where we really want it to be fully buffered.
>
> So please just find the place where we do a fork() without flushing
> pending output...
Sure. The sledgehammer approach was partly to get some advice on the
proper solution. I now realize that you have generally been careful
about this, and so a single flush should be enough.
Below are two alternative proposals, one local and one global. Both of
them fix the problem for me, but maybe you were even thinking about a
third place?
For the run-command.c one, I was not sure whether to put it inside or
outside the ifdef, and I also was not sure whether to add it for
start_command(). Not having other testcases, and not knowing Windows,
this is the way it ended up.
Cheers,
Anders.
From: Anders Melchiorsen <mail@cup.kalibalik.dk>
Date: Mon, 4 Aug 2008 00:21:49 +0200
Subject: [PATCH] Flush stdout in init-db
Before this change, clone outputs "Initialized empty ..." twice
if output is piped.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
builtin-init-db.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index baf0d09..954c7e9 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -315,11 +315,13 @@ int init_db(const char *template_dir, unsigned int flags)
git_config_set("receive.denyNonFastforwards", "true");
}
- if (!(flags & INIT_DB_QUIET))
+ if (!(flags & INIT_DB_QUIET)) {
printf("%s%s Git repository in %s/\n",
reinit ? "Reinitialized existing" : "Initialized empty",
shared_repository ? " shared" : "",
get_git_dir());
+ fflush(stdout);
+ }
return 0;
}
From: Anders Melchiorsen <mail@cup.kalibalik.dk>
Date: Mon, 4 Aug 2008 00:35:40 +0200
Subject: [PATCH] Flush standard output in start_async
This prevents double output in case stdout is redirected.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
run-command.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/run-command.c b/run-command.c
index a3b28a6..67be079 100644
--- a/run-command.c
+++ b/run-command.c
@@ -304,6 +304,9 @@ int start_async(struct async *async)
async->out = pipe_out[0];
#ifndef __MINGW32__
+ /* Flush output before fork() to avoid cloning the buffer */
+ fflush(stdout);
+
async->pid = fork();
if (async->pid < 0) {
error("fork (async) failed: %s", strerror(errno));
^ permalink raw reply related
* Re: git-svn and svn:externals, was Re: Hackontest ideas?
From: Eric Wong @ 2008-08-03 22:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.0807291354130.4631@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 29 Jul 2008, Jakub Narebski wrote:
>
> > * handling of svn:externals using submodules
>
> I doubt that this is easy. Otherwise, Eric would have done it a long time
> ago.
I started working on externals support a long time ago, but got hung up
on corner-cases (with .gitmodules and .gitignore being in the tree) and
backward-compatibility issues with commiting back to SVN.
The more I think about it, the more I think the worse-is-better approach
I used for "git svn show-ignore" is the way to go (using the unversioned
.git/info/exclude). That would mean ignoring submodules as implemented
by git and just shotgunning another git-svn-created subdirectory into
where the external would've been...
> The main concern I have is to get the semantics right: AFAICT
> svn:externals has _no notion_ of "what is current". It just _always_
> fetches the HEAD. Even if you check out an ancient revision in the
> "superproject".
Based on my limited understanding, peg revisions are only needed in SVN
because of the cost of traversing history to DTRT. git-svn should be
able to just use the -r<rev> syntax that has always been supported
without needing peg revisions. On the other hand, implicit rename/copy
detection in git may not pick up drastic changes...
--
Eric Wong
^ permalink raw reply
* [PATCH 0/5] Fix 'url.*.insteadOf' for submodule URLs
From: Johan Herland @ 2008-08-03 22:57 UTC (permalink / raw)
To: git, Junio C Hamano
As suggested in a thread some time ago, one could redefine the URL used to
fetch submodules by adding a 'url.*.insteadOf' rule prior to the first
invocation of 'git submodule update'.
However, this does not work with current Git, because the super-repo config
(which is home to the 'url.*.insteadOf' rule) is not consulted by the 'git
clone' that is invoked by 'git submodule update'.
These patches fix this issue by making 'git submodule' explicitly rewrite
the submodule URL according to the super-repo config, prior to calling 'git
clone'.
In order for the 'git submodule' shell script to properly rewrite URLs, it
must gain access to the URL rewriting functionality in remote.c. To expose
the URL rewriting functionality to 'git submodule' (and others, if needed),
a new option ('rewrite-url') has been added to 'git config'.
The patch series is based on master. Whether or not this should be
considered for v1.6.0 is to be decided by Junio. (My personal opinion is
that although we're late in the release cycle, the patches are fairly
straightforward, and should not pose a great risk of regressions.)
Johan Herland (5):
Add testcase for 'git submodule' with url.*.insteadOf set in the
super-repo
Teach 'git config' to rewrite URLs according to current
url.*.insteadOf rules
Add selftest for new option '--rewrite-url' to 'git config'
Add documentation on the new --rewrite-url option to 'git config'
Teach 'git submodule' to rewrite submodule URLs according to
super-repo's rules
Documentation/git-config.txt | 10 ++++++++++
builtin-config.c | 23 ++++++++++++++++++++++-
git-submodule.sh | 6 ++++++
t/t1300-repo-config.sh | 14 ++++++++++++++
t/t7400-submodule-basic.sh | 11 +++++++++++
5 files changed, 63 insertions(+), 1 deletions(-)
Have fun!
...Johan
^ permalink raw reply
* [PATCH 1/5] Add testcase for 'git submodule' with url.*.insteadOf set in the super-repo
From: Johan Herland @ 2008-08-03 23:00 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <200808040057.00221.johan@herland.net>
Currently, setting url.*.insteadOf in the super-repo in order to rewrite
submodule URLs, don't work. When cloning/fetching the submodule, the
super-repo config is never consulted, and thus the url.*.insteadOf rule
is never seen. This adds a testcase that confirms the current behaviour.
Signed-off-by: Johan Herland <johan@herland.net>
---
t/t7400-submodule-basic.sh | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index cbc0c34..bafc46c 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -209,4 +209,15 @@ test_expect_success 'update --init' '
'
+test_expect_failure 'update --init with url.*.insteadOf' '
+
+ rm -rf init &&
+ git config -f .gitmodules submodule.example.url "http://example.com/init2"
&&
+ git config --remove-section submodule.example
+ git config "url.$(pwd)/.insteadOf" "http://example.com/" &&
+ git submodule update --init init &&
+ test -d init/.git
+
+'
+
test_done
--
1.6.0.rc1.34.g0fe8c
^ permalink raw reply related
* [PATCH 3/5] Add selftest for new option '--rewrite-url' to 'git config'
From: Johan Herland @ 2008-08-03 23:02 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <200808040057.00221.johan@herland.net>
Simple check that URL rewriting functionality works as expected.
Signed-off-by: Johan Herland <johan@herland.net>
---
t/t1300-repo-config.sh | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 64567fb..dcd04c2 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -741,4 +741,18 @@ test_expect_success 'symlinked configuration' '
'
+test_expect_success '--rewrite-url' '
+
+ git config url.ssh://example.com/foo/.insteadOf http://example.com/ &&
+ git config url.../.insteadOf git://example.com/ &&
+ a=$(git config --rewrite-url http://example.com/baz/xyzzy.git) &&
+ test "zssh://example.com/foo/baz/xyzzy.git" = "z$a" &&
+ b=$(git config --rewrite-url git://example.com/baz/xyzzy.git) &&
+ test "z../baz/xyzzy.git" = "z$b" &&
+ c=$(git config --rewrite-url ssh://example.com/foo/baz/xyzzy.git) &&
+ test "zssh://example.com/foo/baz/xyzzy.git" = "z$c" &&
+ d=$(git config --rewrite-url rsync://example.com/baz/xyzzy.git) &&
+ test "zrsync://example.com/baz/xyzzy.git" = "z$d"
+'
+
test_done
--
1.6.0.rc1.34.g0fe8c
^ permalink raw reply related
* [PATCH 2/5] Teach 'git config' to rewrite URLs according to current url.*.insteadOf rules
From: Johan Herland @ 2008-08-03 23:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <200808040057.00221.johan@herland.net>
This patch adds the --rewrite-url option to 'git config'. The option takes
exactly one argument; a URL that is to be rewritten according to the longest
matching url.*.insteadOf rule in the current config. The resulting URL is
printed on stdout, and 0 is returned.
The rationale for this patch is to enable access to Git's URL rewriting
functionality from shell scripts.
The URL rewriting functionality is implemented by piggybacking on the
existing URL rewriting code in remote.c.
Signed-off-by: Johan Herland <johan@herland.net>
---
builtin-config.c | 23 ++++++++++++++++++++++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/builtin-config.c b/builtin-config.c
index 91fdc49..977e6cb 100644
--- a/builtin-config.c
+++ b/builtin-config.c
@@ -1,9 +1,10 @@
#include "builtin.h"
#include "cache.h"
#include "color.h"
+#include "remote.h"
static const char git_config_set_usage[] =
-"git config [ --global | --system | [ -f | --file ] config-file ] [ --bool | --int | --bool-or-int ] [ -z | --null ]
[--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list | --get-color
var [default] | --get-colorbool name [stdout-is-tty]";
+"git config [ --global | --system | [ -f | --file ] config-file ] [ --bool | --int | --bool-or-int ] [ -z | --null ]
[--get | --get-all | --get-regexp | --replace-all | --add | --unset | --unset-all] name [value [value_regex]] | --rename-section old_name new_name | --remove-section name | --list | --get-color
var [default] | --get-colorbool name [stdout-is-tty] | --rewrite-url url";
static char *key;
static regex_t *key_regexp;
@@ -281,6 +282,24 @@ static int get_colorbool(int argc, const char **argv)
}
}
+static int rewrite_url(int argc, const char **argv)
+{
+ /*
+ * git config --rewrite_url <url>
+ *
+ * returns <url> after rewriting it according to url.*.insteadOf rules.
+ */
+
+ if (argc > 1)
+ usage(git_config_set_usage);
+
+ struct remote *remote = remote_get(argv[0]);
+ if (remote->url_nr != 1)
+ die("Expected exactly one URL from remote_get()!");
+ printf("%s\n", remote->url[0]);
+ return 0;
+}
+
int cmd_config(int argc, const char **argv, const char *prefix)
{
int nongit;
@@ -362,6 +381,8 @@ int cmd_config(int argc, const char **argv, const char *prefix)
return get_color(argc-2, argv+2);
} else if (!strcmp(argv[1], "--get-colorbool")) {
return get_colorbool(argc-2, argv+2);
+ } else if (!strcmp(argv[1], "--rewrite-url")) {
+ return rewrite_url(argc-2, argv+2);
} else
break;
argc--;
--
1.6.0.rc1.34.g0fe8c
^ permalink raw reply related
* [PATCH 4/5] Add documentation on the new --rewrite-url option to 'git config'
From: Johan Herland @ 2008-08-03 23:02 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <200808040057.00221.johan@herland.net>
Signed-off-by: Johan Herland <johan@herland.net>
---
Documentation/git-config.txt | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-config.txt b/Documentation/git-config.txt
index 28e1861..154c80b 100644
--- a/Documentation/git-config.txt
+++ b/Documentation/git-config.txt
@@ -22,6 +22,7 @@ SYNOPSIS
'git config' [<file-option>] [-z|--null] -l | --list
'git config' [<file-option>] --get-color name [default]
'git config' [<file-option>] --get-colorbool name [stdout-is-tty]
+'git config' [<file-option>] --rewrite-url url
DESCRIPTION
-----------
@@ -157,6 +158,15 @@ See also <<FILES>>.
output. The optional `default` parameter is used instead, if
there is no color configured for `name`.
+--rewrite-url url::
+
+ Rewrite `url` according to the longest matching URL rewriting rule
+ (see documentation on `url.<base>.insteadOf` for more information
+ on URL rewriting rules), and output the resulting URL to the
+ standard output. If there is no matching URL rewriting rule, the
+ original `url` is printed on the standard output. In either case,
+ the exit code is 0.
+
[[FILES]]
FILES
-----
--
1.6.0.rc1.34.g0fe8c
^ 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