* [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
* [PATCH 5/5] Teach 'git submodule' to rewrite submodule URLs according to super-repo's rules
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>
When a 'url.*.insteadOf' rule in the superrepo matches a submodule URL, we
should rewrite the submodule URL accordingly, so that we don't request the
submodule from location that is inaccessible (or unwanted by the user for
some other reason).
Signed-off-by: Johan Herland <johan@herland.net>
---
git-submodule.sh | 6 ++++++
t/t7400-submodule-basic.sh | 2 +-
2 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index b40f876..ea2aa3b 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -96,6 +96,12 @@ module_clone()
test -e "$path" &&
die "A file already exist at path '$path'"
+ # The user may have added url.*.insteadOf rules intending to rewrite
+ # submodule URLs. We must explicitly do this rewrite before calling
+ # 'git clone', since 'git clone' will not consult the super-repo
+ # config and thus never see any url.*.insteadOf rules placed therein.
+ url=$(git config --rewrite-url "$url")
+
git-clone -n "$url" "$path" ||
die "Clone of '$url' into submodule path '$path' failed"
}
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index bafc46c..9c56de2 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -209,7 +209,7 @@ test_expect_success 'update --init' '
'
-test_expect_failure 'update --init with url.*.insteadOf' '
+test_expect_success 'update --init with url.*.insteadOf' '
rm -rf init &&
git config -f .gitmodules submodule.example.url "http://example.com/init2" &&
--
1.6.0.rc1.34.g0fe8c
^ permalink raw reply related
* [PATCH 1/5 v2] Add testcase for 'git submodule' with url.*.insteadOf set in the super-repo
From: Johan Herland @ 2008-08-03 23:04 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <200808040100.02944.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(-)
The previous patch was whitespace-damaged. Sorry. Trying again.
...Johan
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
* Re: git-svn and svn:externals, was Re: Hackontest ideas?
From: Johannes Schindelin @ 2008-08-03 23:24 UTC (permalink / raw)
To: Eric Wong; +Cc: Jakub Narebski, Petr Baudis, git
In-Reply-To: <20080803224852.GC3006@untitled>
Hi,
On Sun, 3 Aug 2008, Eric Wong wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > 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.
I was talking about the svn -> git direction.
And Git does not peg revisions because of the cost of traversing history
to DTRT.
Git pegs revisions of submodules, because it is the right thing to do.
Subversion just got it wrong to begin with. After all, we are going
through a lot to make defined revisions, and we do not want to throw that
out by allowing an unversioned submodule.
So, importing a svn:external with git-svn has to undo that error somehow
(which might be helped by the linearity of subversion, but might be tricky
because of possible clock skews between the two subversion repositories).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 0/5] Fix 'url.*.insteadOf' for submodule URLs
From: Johannes Schindelin @ 2008-08-03 23:27 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Junio C Hamano
In-Reply-To: <200808040057.00221.johan@herland.net>
Hi,
On Mon, 4 Aug 2008, Johan Herland wrote:
> 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'.
If I suggested it, but forgot the "--global" flag to "git config", I
apologize.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn and svn:externals, was Re: Hackontest ideas?
From: Eric Wong @ 2008-08-03 23:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.0808040113150.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sun, 3 Aug 2008, Eric Wong wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > 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.
>
> I was talking about the svn -> git direction.
Likewise.
> And Git does not peg revisions because of the cost of traversing history
> to DTRT.
I was saying SVN uses peg revisions because of the cost.
Also, there may be a misunderstanding as to what peg revisions are (in SVN)
and how they relate to git.
Here's an example svn:external definition with a peg revision:
-r 1234 http://foo/bar.c@5233
"@5233" is the peg revision, and (as I understand it, just a hint) and
"-r 1234" is the actual revision we want from SVN (and what git-svn
should fetch). Confusing? Yes.
> Git pegs revisions of submodules, because it is the right thing to do.
> Subversion just got it wrong to begin with. After all, we are going
> through a lot to make defined revisions, and we do not want to throw that
> out by allowing an unversioned submodule.
Yes, most repositories I've seen don't even use "-r 1234" (which has
always been supported by SVN). This is the problem git will have to
deal with.
> So, importing a svn:external with git-svn has to undo that error somehow
> (which might be helped by the linearity of subversion, but might be tricky
> because of possible clock skews between the two subversion repositories).
Yes. This is why I'm leaning towards /not/ using git submodules for this
because svn:externals are rarely defined with -r <revno>.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 0/5] Fix 'url.*.insteadOf' for submodule URLs
From: Johan Herland @ 2008-08-03 23:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0808040126170.9611@pacific.mpi-cbg.de.mpi-cbg.de>
On Monday 04 August 2008, Johannes Schindelin wrote:
> On Mon, 4 Aug 2008, Johan Herland wrote:
> > 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'.
>
> If I suggested it, but forgot the "--global" flag to "git config", I
> apologize.
Does this mean that you don't agree with the rationale for this patch? I.e.
that submodule URLs should not be rewritten according to the rules in the
super-repo (but instead require such rules to be set in the user's global
config)?
There are (at least) two reasons for why I think this should work without
having to use '--global':
1. Consistency: Other git commands in the supermodule does _not_ require the
URL rewriting rule to reside in the global config. Why should 'git
submodule' be different.
2. I believe there are valid use cases for adding URL rewriting rules to the
repo config instead of the global config. You may want to check out Fred's
version of project X (including submodules), without making your other
clones of project X start cloning/fetching from Fred.
Puzzled,
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH 0/5] Fix 'url.*.insteadOf' for submodule URLs
From: Junio C Hamano @ 2008-08-03 23:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johan Herland, git
In-Reply-To: <alpine.DEB.1.00.0808040126170.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 4 Aug 2008, Johan Herland wrote:
>
>> 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'.
>
> If I suggested it, but forgot the "--global" flag to "git config", I
> apologize.
That's a nice way to say that the patchset is unnecessary ;-).
^ permalink raw reply
* Re: [PATCH] git-svn: Abort with an error if 'fetch' parameter is invalid.
From: Eric Wong @ 2008-08-04 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Avery Pennarun
In-Reply-To: <1217451235-9609-1-git-send-email-apenwarr@gmail.com>
Avery Pennarun <apenwarr@stasis.open.versabanq.com> wrote:
> Previously, if a config entry looked like this:
>
> svn-remote.svn.fetch=:refs/heads/whatever
>
> git-svn would silently do nothing if you asked it to "git svn fetch", and
> give a strange error if asked to "git svn dcommit". What it really wants is
> a line that looks like this:
>
> svn-remote.svn.fetch=:refs/remotes/whatever
>
> So we should simply abort if we get the wrong thing.
>
> On the other hand, there's actually no good reason for git-svn to enforce
> using the refs/remotes namespace, but the code seems to have hardcoded this
> in several places and I'm not brave enough to try to fix it all right now.
Fully agreed (as I've stated in the past, too). I just haven't had
time to fix it.
> Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Thanks Avery,
Acked-by: Eric Wong <normalperson@yhbt.net>
> ---
>
> I just spent altogether too much time tracking down this problem when
> migrating my git-svn settings from one repo to another.
>
> git-svn.perl | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/git-svn.perl b/git-svn.perl
> index cf6dbbc..cc35f50 100755
> --- a/git-svn.perl
> +++ b/git-svn.perl
> @@ -1420,8 +1420,12 @@ sub read_all_remotes {
> svn.useSvmProps/) };
> $use_svm_props = $use_svm_props eq 'true' if $use_svm_props;
> foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
> - if (m!^(.+)\.fetch=\s*(.*)\s*:\s*refs/remotes/(.+)\s*$!) {
> - my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
> + if (m!^(.+)\.fetch=\s*(.*)\s*:\s*(.+)\s*$!) {
> + my ($remote, $local_ref, $_remote_ref) = ($1, $2, $3);
> + die("svn-remote.$remote: remote ref '$_remote_ref' "
> + . "must start with 'refs/remotes/'\n")
> + unless $_remote_ref =~ m{^refs/remotes/(.+)};
> + my $remote_ref = $1;
> $local_ref =~ s{^/}{};
> $r->{$remote}->{fetch}->{$local_ref} = $remote_ref;
> $r->{$remote}->{svm} = {} if $use_svm_props;
> --
> 1.6.0.rc0.42.g186458.dirty
>
>
^ permalink raw reply
* Re: [PATCH] git-svn: Abort with an error if 'fetch' parameter is invalid.
From: Junio C Hamano @ 2008-08-04 0:21 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Avery Pennarun
In-Reply-To: <20080804000140.GA13019@untitled>
Eric Wong <normalperson@yhbt.net> writes:
>> Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
>
> Thanks Avery,
> Acked-by: Eric Wong <normalperson@yhbt.net>
I do not seem to find the original message in mbox nor list archive, by
the way...
^ permalink raw reply
* Re: [PATCH] Use line buffering for standard output
From: Junio C Hamano @ 2008-08-04 0:24 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: Linus Torvalds, git
In-Reply-To: <87hca1ogto.fsf@cup.kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> 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));
I think this with s/stdout/NULL/ would be a reasonable thing to do.
^ permalink raw reply
* [PATCH] Flush output in start_async
From: Anders Melchiorsen @ 2008-08-04 0:30 UTC (permalink / raw)
To: gitster; +Cc: git, Anders Melchiorsen
In-Reply-To: <7vej557hlq.fsf@gitster.siamese.dyndns.org>
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..6af83c5 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 stdio before fork() to avoid cloning buffers */
+ fflush(NULL);
+
async->pid = fork();
if (async->pid < 0) {
error("fork (async) failed: %s", strerror(errno));
--
1.5.6.4
^ permalink raw reply related
* Re: [PATCH] git-svn: Abort with an error if 'fetch' parameter is invalid.
From: Eric Wong @ 2008-08-04 0:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Avery Pennarun
In-Reply-To: <7viquh7hpq.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> >> Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
> >
> > Thanks Avery,
> > Acked-by: Eric Wong <normalperson@yhbt.net>
>
> I do not seem to find the original message in mbox nor list archive, by
> the way...
Could've been Avery's original From: line not being spam filter
friendly.
Here you go (with From: line fixed)
>From 574c237f4561cf0293e7f44ab604bb701d1931f3 Mon Sep 17 00:00:00 2001
From: Avery Pennarun <apenwarr@gmail.com>
Date: Wed, 30 Jul 2008 16:53:55 -0400
Subject: [PATCH] git-svn: Abort with an error if 'fetch' parameter is invalid.
Previously, if a config entry looked like this:
svn-remote.svn.fetch=:refs/heads/whatever
git-svn would silently do nothing if you asked it to "git svn fetch", and
give a strange error if asked to "git svn dcommit". What it really wants is
a line that looks like this:
svn-remote.svn.fetch=:refs/remotes/whatever
So we should simply abort if we get the wrong thing.
On the other hand, there's actually no good reason for git-svn to enforce
using the refs/remotes namespace, but the code seems to have hardcoded this
in several places and I'm not brave enough to try to fix it all right now.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
---
git-svn.perl | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 0a346f8..1c39f45 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1423,8 +1423,12 @@ sub read_all_remotes {
svn.useSvmProps/) };
$use_svm_props = $use_svm_props eq 'true' if $use_svm_props;
foreach (grep { s/^svn-remote\.// } command(qw/config -l/)) {
- if (m!^(.+)\.fetch=\s*(.*)\s*:\s*refs/remotes/(.+)\s*$!) {
- my ($remote, $local_ref, $remote_ref) = ($1, $2, $3);
+ if (m!^(.+)\.fetch=\s*(.*)\s*:\s*(.+)\s*$!) {
+ my ($remote, $local_ref, $_remote_ref) = ($1, $2, $3);
+ die("svn-remote.$remote: remote ref '$_remote_ref' "
+ . "must start with 'refs/remotes/'\n")
+ unless $_remote_ref =~ m{^refs/remotes/(.+)};
+ my $remote_ref = $1;
$local_ref =~ s{^/}{};
$r->{$remote}->{fetch}->{$local_ref} = $remote_ref;
$r->{$remote}->{svm} = {} if $use_svm_props;
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Eric Wong @ 2008-08-04 0:48 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: Junio C Hamano, git
In-Reply-To: <200807311243.35219.litvinov2004@gmail.com>
Alexander Litvinov <litvinov2004@gmail.com> wrote:
> Make git-svn works with crlf (or any other) file content convertion enabled.
>
> When we modify file content SVN cant apply its delta to it. To fix this
> situation I take full file content from SVN as next revision. This is
> dump and slow but it works.
> + my $ctx = SVN::Client->new();
> + $ctx->cat($fh, $url, $rev);
> }
I know you've already (at least for now) pulled this patch but I won't
accept anything that opens a second connection to the server.
I've seen this in some svn:// servers intermittently, but I've seen
git-svn get its connection terminated whenever it opens a second
connection (it happens with parent-following). git-svn used to do
this more frequently, but most of those cases got fixed (but
one remains with parent-following).
Additionally, git-svnimport and older versions of git-svn used the
equivalent of $ctx->cat without deltas from the SVN::Ra object, so you
should be able todo something functionally equivalent w/o opening a new
socket.
As far as crlf issues with git-svn go, I'm blissfully ignorant of the
complexities behind what git (or svn for that matter) does with crlf
conversions[1].
I'll be alright with any changes to git-svn that don't modify existing
behavior for crlf-ignorant users such as myself. I'll trust Junio and
other folks on the list to know and do what makes the most sense here.
[1] I would have much rather preferred git didn't implement or care
about crlf filters at all, but maybe I'm just in a small minority.
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 0/5] Fix 'url.*.insteadOf' for submodule URLs
From: Junio C Hamano @ 2008-08-04 2:06 UTC (permalink / raw)
To: Johan Herland; +Cc: Johannes Schindelin, git
In-Reply-To: <200808040147.16797.johan@herland.net>
Johan Herland <johan@herland.net> writes:
> 1. Consistency: Other git commands in the supermodule does _not_ require the
> URL rewriting rule to reside in the global config. Why should 'git
> submodule' be different.
When it comes to "submodules", I do not think such consistency argument
makes much sense. "git submodule" command crosses module boundary, normal
commands don't. They are naturally different and they should be.
Your kind of consistency means breaking the separation between module
boundary, doesn't it?
Having said that...
> 2. I believe there are valid use cases for adding URL rewriting rules to the
> repo config instead of the global config. You may want to check out Fred's
> version of project X (including submodules), without making your other
> clones of project X start cloning/fetching from Fred.
I think you are referring to the example given in an earlier thread to
peek what your neighbor did between you two, without affecting other
people.
Personally I think it is partly showing the shortcoming of the current
"git submodule" that minimally supports the workflow to follow what the
canonical repository does, and partly showing that it is an abuse of that
interface to rewrite config file to temporarily switch to peek somewhere
else in such a workflow.
Let's step back and think what we would do if there is no submodule
involved. That is, you usually follow origin, but you temporarily want to
peek at what Fred did. How would you do this?
$ git fetch $fred $branch_fred_wants_you_to_review
$ git checkout FETCH_HEAD ;# this detaches HEAD.
And you take a look around. Perhaps you like the change and decide to
merge that to your branch. Perhaps you create your own branch on top of
that state, build a few fix-up commits, and give the result back to Fred.
Shouldn't peeking what Fred did in the whole submodule hierarchy be
essentially the same thing? That is,
$ git submodule for-each-submodule sh -c '
git fetch "$fred/$1" $branch_fred_wants_you_to_review &&
git checkout FETCH_HEAD
' -
where "for-each-submodule" would iterate over the submodules in the
current superproject that you are interested in (that is, you actually
have corresponding repositories there), and runs any given command with
the path to the submodule in that directory.
Hmm?
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Eric Wong @ 2008-08-04 2:09 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <1217701021.8296.35.camel@heerbeest>
Jan Nieuwenhuizen <janneke-list@xs4all.nl> wrote:
> On za, 2008-08-02 at 10:36 -0700, Junio C Hamano wrote:
>
> > > You forgot to document your option. (And possibly write a testcase.)
> >
> > I am not sure if this is generic enough to be in git-svn.perl itself, or
> > perhaps there should be a hook make_log_entry() would call in the form of
> > some Perl scriptlet given by the user to munge $log_entry{log}, which
> > would be very specific to each project.
>
> If you're not sure, please make up your mind. I agree it's quite a hack
> but now it's in the archives for others to find. Doing this in a single
> regexp is a bit tricky and asking a user to write a perl snippet is even
> worse, imho. Especially if would turn out that stripping changelog bits
> is the only thing that the hook is getting used for, in the end. I have
> gotten more careful to provide generic solutions to specific problems in
> anticipation of possible future desires.
>
> I could imagine that leaving git-svn alone and adding a hook to git-log
> would be more useful, though.
NACK on modifying git-svn to support more changelog formats.
A better idea would be to write a generic script that takes "git log",
"git svn log" or even plain "svn log" output and filters it
independently.
This way existing projects don't have to be re-imported (a bad idea to
modify things SVN feeds us anyways), and plain svn users can benefit,
too.
This filter should be reusable for both plain svn and git-svn:
svn log | changelog-filter --input=svn --style=gnu
git svn log | changelog-filter --input=svn --style=gnu
git log --pretty=raw | changelog-filter --input=git-raw --style=gnu
However, I would support a generic --log-filter parameter in git-svn
that would have git-svn filter its output through any given command
before piping it to less.
git config svn.logFilter "changelog-filter --input=svn --style=gnu"
git svn log
or...
git svn log --log-filter="changelog-filter --input=svn --style=yak"
git svn log --log-filter="svn-log-to-LaTeX"
git svn log --log-filter="svn-log-to-HTML"
git svn log --log-filter="svn-log-to-XML"
git svn log --log-filter="svn-log-to-JSON"
git svn log --log-filter="svn-log-to-PNG" > log.png
git svn log --log-filter="svn-log-to-theora" > log.ogg
The possibilities are endless :)
--
Eric Wong
^ permalink raw reply
* [PATCH 0/1] : [GITWEB] : Git link on project list page
From: warthog19 @ 2008-08-04 2:00 UTC (permalink / raw)
To: git
This is a quick port of the git link patch that's present on kernel.org's gitweb, project list page.
- John 'Warthog9' Hawley
^ permalink raw reply
* [PATCH 1/1] Add "git" link to the end of project line on the project_list page.
From: warthog19 @ 2008-08-04 2:00 UTC (permalink / raw)
To: git; +Cc: John 'Warthog9' Hawley, John 'Warthog9' Hawley
In-Reply-To: <1217815217-11329-1-git-send-email-warthog19@eaglescrag.net>
[-- Attachment #1: Type: text/plain, Size: 44 bytes --]
This is a multi-part message in MIME format.
[-- Attachment #2: Type: text/plain, Size: 390 bytes --]
This makes the assumption that all repositories are available from a unified location.
Using .git/cloneurl is actually a problem as that can define multiple URLs to clone from, and we are seeking a single unified URL for now.
Signed-off-by: John 'Warthog9' Hawley <warthog9@eaglescrag.net>
---
gitweb/gitweb.perl | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: 07ce8f81cc06027c9c166cf316238d7a4af17162.diff --]
[-- Type: text/x-patch; name="07ce8f81cc06027c9c166cf316238d7a4af17162.diff", Size: 1619 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 90cd99b..c33f4ed 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -108,6 +108,14 @@ our $mimetypes_file = undef;
# could be even 'utf-8' for the old behavior)
our $fallback_encoding = 'latin1';
+# enable / disable a final link on the project list page
+# that will be the location of that actuall git url
+# it will output this in the format:
+# git://hostname/path/to/tree.git
+# disabled = blank or undef
+# enable = url to prefix before filling in the trailing path to the git repo
+our $projectlist_gitlinkurl = undef;
+
# rename detection options for git-diff and git-diff-tree
# - default is '-M', with the cost proportional to
# (number of removed files) * (number of new files).
@@ -3661,8 +3669,11 @@ sub git_project_list_body {
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"shortlog")}, "shortlog") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"log")}, "log") . " | " .
$cgi->a({-href => href(project=>$pr->{'path'}, action=>"tree")}, "tree") .
- ($pr->{'forks'} ? " | " . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '') .
- "</td>\n" .
+ ($pr->{'forks'} ? " | " . $cgi->a({-href => href(project=>$pr->{'path'}, action=>"forks")}, "forks") : '');
+ if( $projectlist_gitlinkurl != undef && $projectlist_gitlinkurl ne "" ){
+ print " | ". $cgi->a({-href => "git://projectlist_gitlinkurl/".esc_html($pr->{'path'})}, "git");
+ }
+ print "</td>\n" .
"</tr>\n";
}
if (defined $extra) {
^ permalink raw reply related
* Re: [PATCH 1/1] Add "git" link to the end of project line on the project_list page.
From: Petr Baudis @ 2008-08-04 2:26 UTC (permalink / raw)
To: warthog19; +Cc: git, John 'Warthog9' Hawley
In-Reply-To: <1217815217-11329-2-git-send-email-warthog19@eaglescrag.net>
On Sun, Aug 03, 2008 at 07:00:17PM -0700, warthog19@eaglescrag.net wrote:
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 90cd99b..c33f4ed 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -108,6 +108,14 @@ our $mimetypes_file = undef;
> # could be even 'utf-8' for the old behavior)
> our $fallback_encoding = 'latin1';
>
> +# enable / disable a final link on the project list page
> +# that will be the location of that actuall git url
> +# it will output this in the format:
> +# git://hostname/path/to/tree.git
> +# disabled = blank or undef
> +# enable = url to prefix before filling in the trailing path to the git repo
> +our $projectlist_gitlinkurl = undef;
> +
> # rename detection options for git-diff and git-diff-tree
> # - default is '-M', with the cost proportional to
> # (number of removed files) * (number of new files).
Note that I will soon submit a generic patch that lets you extend
the link lists with custom entries - you could easily use that for
the git links (I'm personally not convinced how useful they really are
on the project list page), I will use them for the graphiclog, edit and
fork links at repo.or.cz.
> + print " | ". $cgi->a({-href => "git://projectlist_gitlinkurl/".esc_html($pr->{'path'})}, "git");
You meant $projectlist_gitlinkurl.
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [PATCH 1/1] Add "git" link to the end of project line on the project_list page.
From: J.H. @ 2008-08-04 2:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080804022656.GA32184@machine.or.cz>
On Mon, 2008-08-04 at 04:26 +0200, Petr Baudis wrote:
> On Sun, Aug 03, 2008 at 07:00:17PM -0700, warthog19@eaglescrag.net wrote:
> > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > index 90cd99b..c33f4ed 100755
> > --- a/gitweb/gitweb.perl
> > +++ b/gitweb/gitweb.perl
> > @@ -108,6 +108,14 @@ our $mimetypes_file = undef;
> > # could be even 'utf-8' for the old behavior)
> > our $fallback_encoding = 'latin1';
> >
> > +# enable / disable a final link on the project list page
> > +# that will be the location of that actuall git url
> > +# it will output this in the format:
> > +# git://hostname/path/to/tree.git
> > +# disabled = blank or undef
> > +# enable = url to prefix before filling in the trailing path to the git repo
> > +our $projectlist_gitlinkurl = undef;
> > +
> > # rename detection options for git-diff and git-diff-tree
> > # - default is '-M', with the cost proportional to
> > # (number of removed files) * (number of new files).
>
> Note that I will soon submit a generic patch that lets you extend
> the link lists with custom entries - you could easily use that for
> the git links (I'm personally not convinced how useful they really are
> on the project list page), I will use them for the graphiclog, edit and
> fork links at repo.or.cz.
I've found them useful, and there were requests out on the mailing list
for this to be added, thus the patching. It's not on by default, so
it's impact should be minimal unless people specifically want the link.
>
> > + print " | ". $cgi->a({-href => "git://projectlist_gitlinkurl/".esc_html($pr->{'path'})}, "git");
>
> You meant $projectlist_gitlinkurl.
grrr - I've fixed that same bug twice now, had problems with something
and must have reverted the wrong thing, I'll fix it and re-submit.
When you do the more generic patch to extend the links I'll flip this
over to that code, unless you think it's worth holding off and waiting
for that change to go in first?
- John 'Warthog9' Hawley
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Junio C Hamano @ 2008-08-04 2:45 UTC (permalink / raw)
To: Eric Wong; +Cc: Jan Nieuwenhuizen, Petr Baudis, git
In-Reply-To: <20080804020931.GA4109@untitled>
Eric Wong <normalperson@yhbt.net> writes:
>> I could imagine that leaving git-svn alone and adding a hook to git-log
>> would be more useful, though.
>
> NACK on modifying git-svn to support more changelog formats.
Honestly, I am neutral about this one. I think it all depends on the
motivation behind the desire to rewrite the log.
If the project that was hosted in Subversion wants to switch (perhaps
gradually) to git, _and_ if the project also wants to adopt a workflow
that does not do the GNU style changelog in the commit log but use a
one-line summary friendly format, then sanitizing the commit log while
importing via git-svn would make sense. Even though filter-branch after
conversion would be another possibility, that option is only available if
you are converting away from Subversion, never to return.
On the other extreme, if the Subversion side will always be the canonical
one, _or_ if the project does not want to change its commit log format,
then I think it makes perfect sense to limit the commit log munging to the
absolute minimum (but even in such a case, the user can just run git-svn
without activating the log munging option --- so I do not think it is such
a big deal to add or reject an option like this).
> A better idea would be to write a generic script that takes "git log",
> "git svn log" or even plain "svn log" output and filters it
> independently.
That's an independent topic. If such a filter supports a feature like our
shortlog command has, people whose history is still trapped in Subversion
would benefit from it.
^ permalink raw reply
* Re: [PATCH] git-p4: chdir now properly sets PWD environment variable in msysGit
From: Han-Wen Nienhuys @ 2008-08-04 3:06 UTC (permalink / raw)
To: git
In-Reply-To: <bad7471c0808011250v569ffaaby9e20a5ba1f971927@mail.gmail.com>
Robert Blum escreveu:
> 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
> +if os.name == 'nt':
> + def os_chdir(dir):
> + os.environ['PWD']=dir
> + os.chdir(dir)
> +else:
> + os_chdir = os.chdir
> +
Stylistic:
I think the naming is a bit ugly (os_); I would write
def chdir(d):
if os.name == 'nt': ..
os.chdir(dir)
for the rest: looks good to me.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] git-svn now work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-08-04 3:10 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: git
In-Reply-To: <37fcd2780808010536v63b2ed2ak31c6d85f2822dc20@mail.gmail.com>
> 2. You do not really need it if the SVN repository has correct eol
> settings, because all files that have svn:eol-style set to either 'native'
> or 'LF' will have LF. Those that do not have svn:eol-style or have it to
> another value should not be subject to CRLF conversion at all.
>
> So, I believe all files received from SVN should be stored as is. Import is
> not about creating new commits, it is about getting history from another
> repository as it is.
I understand the idea now. Some of my files in svn repo are missing eol style
property at all. Will fix this :-)
Thanks for help !
^ permalink raw reply
* Re: [PATCH 1/1] Add "git" link to the end of project line on the project_list page.
From: Petr Baudis @ 2008-08-04 3:20 UTC (permalink / raw)
To: J.H.; +Cc: git
In-Reply-To: <1217817517.32240.46.camel@localhost.localdomain>
On Sun, Aug 03, 2008 at 07:38:37PM -0700, J.H. wrote:
> On Mon, 2008-08-04 at 04:26 +0200, Petr Baudis wrote:
> > On Sun, Aug 03, 2008 at 07:00:17PM -0700, warthog19@eaglescrag.net wrote:
> > > diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> > > index 90cd99b..c33f4ed 100755
> > > --- a/gitweb/gitweb.perl
> > > +++ b/gitweb/gitweb.perl
> > > @@ -108,6 +108,14 @@ our $mimetypes_file = undef;
> > > # could be even 'utf-8' for the old behavior)
> > > our $fallback_encoding = 'latin1';
> > >
> > > +# enable / disable a final link on the project list page
> > > +# that will be the location of that actuall git url
> > > +# it will output this in the format:
> > > +# git://hostname/path/to/tree.git
> > > +# disabled = blank or undef
> > > +# enable = url to prefix before filling in the trailing path to the git repo
> > > +our $projectlist_gitlinkurl = undef;
> > > +
> > > # rename detection options for git-diff and git-diff-tree
> > > # - default is '-M', with the cost proportional to
> > > # (number of removed files) * (number of new files).
By the way, you should add this to gitweb/README too (though I've never
been too fond of listing the options twice myself; my strategy to avoid
it is to just add as much stuff possible to the $features hash ;-).
> > > + if( $projectlist_gitlinkurl != undef && $projectlist_gitlinkurl ne "" ){
Coding style conformant and equivalent but simpler variant would be
if ($projectlist_gitlinkurl) {
right?
> > > + print " | ". $cgi->a({-href => "git://projectlist_gitlinkurl/".esc_html($pr->{'path'})}, "git");
> >
> > You meant $projectlist_gitlinkurl.
>
> grrr - I've fixed that same bug twice now, had problems with something
> and must have reverted the wrong thing, I'll fix it and re-submit.
>
> When you do the more generic patch to extend the links I'll flip this
> over to that code, unless you think it's worth holding off and waiting
> for that change to go in first?
It's a new feature so it probably won't make it to 1.6.0 - so let's see
if I manage to submit mine before 1.6.0. ;-)
--
Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC. -- Bill Gates
^ permalink raw reply
* Re: [RFC 2/2] Add Git-aware CGI for Git-aware smart HTTP transport
From: Shawn O. Pearce @ 2008-08-04 3:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, H. Peter Anvin
In-Reply-To: <7vwsix7nhw.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> 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.
This is a very valid concern. I started to worry about it myself
last night, but decided it was late enough and just wanted to start
the discussion on the list, extending JH's thread even further.
> Perhaps "#" comment line in info/refs that is ignored on the reading side
> but update-server-info never generates on its own?
This is a good idea. I think anyone who consumes info/refs does
so with the understanding that "#" comment lines exist, and should
be skipped, but this is not something that has been heavily tested
in the wild yet.
My concern here goes back to the remark you made above. What if a
server owner mirrors a smart server by a non-Git aware device like
wget? They will now have a copy of the info/refs content which will
suggest we have Git smarts on the backend, but really it isn't there.
Perhaps the smart server detection is something like:
Smart Server Detection
----------------------
To detect a smart (Git-aware) server a client sends an
empty POST request to info/refs; if a 200 OK response is
received with the proper content type then the server can
be assumed to be Git-aware, and the result contains the
current info/refs data for that repository.
C: POST /repository.git/info/refs HTTP/1.0
C: Content-Length: 0
S: HTTP/1.0 200 OK
S: Content-Type: application/x-git-refs
S:
S: 95dcfa3633004da0049d3d0fa03f80589cbcaf31 refs/heads/maint
Then clients should just attempt this POST first before issuing
a GET info/refs. Non Git-aware servers will issue an error code,
and the client can retry with a standard GET request, and assume
the server isn't a newer style.
--
Shawn.
^ 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