* Re: [PATCH 1/2] clone: Add an option to set up a mirror
From: Junio C Hamano @ 2008-08-02 18:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0808011600170.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> The command line
>
> $ git clone --mirror $URL
>
> is now a short-hand for
>
> $ git clone --bare $URL
> $ (cd $(basename $URL) && git remote add --mirror origin $URL)
I think this would be a useful behaviour and I am very tempted to violate
the general policy of not taking any new options nor features after -rc1.
I however notice that there are differences bewteen the above sequence and
what your code actually does:
- The "remote add --mirror" sequence tells it to mirror everything, but
the patch still mirrors only heads;
- You are not setting up "remote.*.mirror = yes" in the configuration;
^ permalink raw reply
* Missing pieces for 1.6.0 on MinGW?
From: Junio C Hamano @ 2008-08-02 19:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Steffen Prohaska, Johannes Schindelin, git
Just a quick question before the weekend ends and -rc2 gets tagged. (I
lost track of that argv0 vs bin/git vs libexec/git-core/git-foo
discussion).
Are there any missing but necessary patches we need before 1.6.0 for
MinGW?
^ permalink raw reply
* Re: git svn and the post-receive hook
From: Pascal Obry @ 2008-08-02 19:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7vwsizl0l9.fsf@gitster.siamese.dyndns.org>
Junio,
> Are you saying that there may be breakages that is made at the Subversion
> side, and you would want to catch it?
Exactly.
> What would you do _after_ finding out that somebody screwed up and you
> have a borked history on the Subversion side already?
Notify the developer(s) about the problem(s).
> I do not think this belongs to "git svn rebase" (let alone "git rebase",
> no way --- you won't rewrite nor reject the upstream even if you find
> problems with it).
>
> I understand that you would at least want to notice the damange to the
> history that happened at the remote end, and I agree it would make sense
> to do something like:
>
> $ git command-that-updates-the-remote-tracking-branch git-svn
> $ check-history git-svn@{1}..git-svn
>
> The "command-that-updates" could be "svn fetch" or just a simple "fetch".
>
> But the "check-history" script will be very specific to your project, and
> I do not think it makes sense to make it a hook to the "command-that-updates".
Hum... Any hook is very specific to a project. That's why it is a hook
and not a built-in command.
BTW, I do not see why this would be a problem with git-svn whereas the
post-receive hook is fine for Git. In many projects rewriting history is
not permitted but post-receive is quite handy to do some checks.
post-received receive 3 parameters:
- sha before
- sha after
- refname
It is perfectly usable after a git-svn rebase.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* [PATCH v2] clone: Add an option to set up a mirror
From: Johannes Schindelin @ 2008-08-02 19:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr697l01j.fsf@gitster.siamese.dyndns.org>
The command line
$ git clone --mirror $URL
is now a short-hand for
$ git clone --bare $URL
$ (cd $(basename $URL) && git remote add --mirror origin $URL)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Interdiff to follow.
Documentation/git-clone.txt | 5 ++++-
builtin-clone.c | 24 ++++++++++++++++++++----
t/t5601-clone.sh | 10 ++++++++++
3 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 26fd1b1..0e14e73 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git clone' [--template=<template_directory>]
- [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare]
+ [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
[-o <name>] [-u <upload-pack>] [--reference <repository>]
[--depth <depth>] [--] <repository> [<directory>]
@@ -106,6 +106,9 @@ then the cloned repository will become corrupt.
used, neither remote-tracking branches nor the related
configuration variables are created.
+--mirror::
+ Set up a mirror of the remote repository. This implies --bare.
+
--origin <name>::
-o <name>::
Instead of using the remote name 'origin' to keep track
diff --git a/builtin-clone.c b/builtin-clone.c
index e086a40..ecdcefa 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -33,7 +33,7 @@ static const char * const builtin_clone_usage[] = {
NULL
};
-static int option_quiet, option_no_checkout, option_bare;
+static int option_quiet, option_no_checkout, option_bare, option_mirror;
static int option_local, option_no_hardlinks, option_shared;
static char *option_template, *option_reference, *option_depth;
static char *option_origin = NULL;
@@ -45,6 +45,8 @@ static struct option builtin_clone_options[] = {
"don't create a checkout"),
OPT_BOOLEAN(0, "bare", &option_bare, "create a bare repository"),
OPT_BOOLEAN(0, "naked", &option_bare, "create a bare repository"),
+ OPT_BOOLEAN(0, "mirror", &option_mirror,
+ "create a mirror repository (implies bare)"),
OPT_BOOLEAN('l', "local", &option_local,
"to clone from a local repository"),
OPT_BOOLEAN(0, "no-hardlinks", &option_no_hardlinks,
@@ -345,6 +347,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
char branch_top[256], key[256], value[256];
struct strbuf reflog_msg;
struct transport *transport = NULL;
+ char *src_ref_prefix = "refs/heads/";
struct refspec refspec;
@@ -359,6 +362,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (option_no_hardlinks)
use_local_hardlinks = 0;
+ if (option_mirror)
+ option_bare = 1;
+
if (option_bare) {
if (option_origin)
die("--bare and --origin %s options are incompatible.",
@@ -440,26 +446,36 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
git_config(git_default_config, NULL);
if (option_bare) {
- strcpy(branch_top, "refs/heads/");
+ if (option_mirror)
+ src_ref_prefix = "refs/";
+ strcpy(branch_top, src_ref_prefix);
git_config_set("core.bare", "true");
} else {
snprintf(branch_top, sizeof(branch_top),
"refs/remotes/%s/", option_origin);
+ }
+ if (option_mirror || !option_bare) {
/* Configure the remote */
+ if (option_mirror) {
+ snprintf(key, sizeof(key),
+ "remote.%s.mirror", option_origin);
+ git_config_set(key, "true");
+ }
+
snprintf(key, sizeof(key), "remote.%s.url", option_origin);
git_config_set(key, repo);
snprintf(key, sizeof(key), "remote.%s.fetch", option_origin);
snprintf(value, sizeof(value),
- "+refs/heads/*:%s*", branch_top);
+ "+%s*:%s*", src_ref_prefix, branch_top);
git_config_set_multivar(key, value, "^$", 0);
}
refspec.force = 0;
refspec.pattern = 1;
- refspec.src = "refs/heads/";
+ refspec.src = src_ref_prefix;
refspec.dst = branch_top;
if (path && !is_bundle)
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index d785b3d..9cd5ef4 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -70,4 +70,14 @@ test_expect_success 'clone creates intermediate directories for bare repo' '
'
+test_expect_success 'clone --mirror' '
+
+ git clone --mirror src mirror &&
+ test -f mirror/HEAD &&
+ test ! -f mirror/file &&
+ FETCH="$(cd mirror && git config remote.origin.fetch)" &&
+ test "+refs/*:refs/*" = "$FETCH"
+
+'
+
test_done
--
1.6.0.rc1.70.g91e1d
^ permalink raw reply related
* Re: [PATCH v2] clone: Add an option to set up a mirror
From: Johannes Schindelin @ 2008-08-02 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0808022126270.9611@pacific.mpi-cbg.de.mpi-cbg.de>
The interdiff:
diff --git a/builtin-clone.c b/builtin-clone.c
index a45179c..ecdcefa 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -347,6 +347,7 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
char branch_top[256], key[256], value[256];
struct strbuf reflog_msg;
struct transport *transport = NULL;
+ char *src_ref_prefix = "refs/heads/";
struct refspec refspec;
@@ -445,7 +446,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
git_config(git_default_config, NULL);
if (option_bare) {
- strcpy(branch_top, "refs/heads/");
+ if (option_mirror)
+ src_ref_prefix = "refs/";
+ strcpy(branch_top, src_ref_prefix);
git_config_set("core.bare", "true");
} else {
@@ -455,18 +458,24 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (option_mirror || !option_bare) {
/* Configure the remote */
+ if (option_mirror) {
+ snprintf(key, sizeof(key),
+ "remote.%s.mirror", option_origin);
+ git_config_set(key, "true");
+ }
+
snprintf(key, sizeof(key), "remote.%s.url", option_origin);
git_config_set(key, repo);
snprintf(key, sizeof(key), "remote.%s.fetch", option_origin);
snprintf(value, sizeof(value),
- "+refs/heads/*:%s*", branch_top);
+ "+%s*:%s*", src_ref_prefix, branch_top);
git_config_set_multivar(key, value, "^$", 0);
}
refspec.force = 0;
refspec.pattern = 1;
- refspec.src = "refs/heads/";
+ refspec.src = src_ref_prefix;
refspec.dst = branch_top;
if (path && !is_bundle)
diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh
index 4b2533f..9cd5ef4 100755
--- a/t/t5601-clone.sh
+++ b/t/t5601-clone.sh
@@ -76,7 +76,7 @@ test_expect_success 'clone --mirror' '
test -f mirror/HEAD &&
test ! -f mirror/file &&
FETCH="$(cd mirror && git config remote.origin.fetch)" &&
- test "+refs/heads/*:refs/heads/*" = "$FETCH"
+ test "+refs/*:refs/*" = "$FETCH"
'
^ permalink raw reply related
* Re: git svn and the post-receive hook
From: Junio C Hamano @ 2008-08-02 20:16 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <4894B387.4040004@obry.net>
Pascal Obry <pascal@obry.net> writes:
> BTW, I do not see why this would be a problem with git-svn whereas the
> post-receive hook is fine for Git.
You probably haven't read Miklos's response have you? post-receive is
about what happens at the remote end after you "push" there, and does not
have to do with what happens when you fetch.
The article I gave you a link earlier gives a guideline to decide when we
choose to add hook for particular step of operation (and when we choose
not to). The new call from "git svn rebase" (and presumably "git svn
fetch" which is the first step of that operation) needs to be justified.
Having said that, I would have framed your argument in a different way. I
suspect then you would not have heard the above objections if you did so:
After pushing to a remote side, there is a post-receive hook so that
some processing can happen depending on which refs changed from what
commit to what new commit. This is primarily because "push" goes to
the remote side and the user may not have any other means to trigger an
operation over there (e.g. there may not be ssh login access, just
git-shell running to accept pushes).
After fetching from somewhere else, there is no post-fetch hook. This
is not a show-stopper problem because the operation is local. You can
remember where the refs were before running a fetch, run the fetch, and
run necessary post-fetch operation. IOW, instead of "git fetch" (or
"git svn fetch") calling a custom script installed as a hook, a custom
script can call "git fetch" (or "git svn fetch") as part of what it
does.
However, fetch and push are logically the same operation --- update a
set of refs on one end to match the other end, while transferring the
necessary objects to keep the updated refs valid. We even suggest
(with satellite-mothership configuration) to push into remote when
network reachability constraints keeps you from fetching in the other
direction or vice versa. If you used fetch to update refs at the
receiving end only because you somehow cannot push in the other
direction, it is natural you would want to do the same processing after
the fetch that post-receive hook would have done if you could push in
the direction you originally wanted to.
Which suggests that we may be better off having a unified post-sync
hook, that would be called with the same arguments as existing
post-receive hook is called with, whenever fetch initiated at the local
end or a push initiated from elsewhere updates refs in the local
repository (such a hook is justified because it needs to _also_ work
at the remote side).
To keep the migration hassle to the minimum, we can reuse post-receive
hook itself for that purpose without actually introducing a new
post-sync hook. So how about calling post-receive from "git fetch" and
"git svn fetch"? This is a change in semantics, and it may break
people's existing setups (i.e. they may be relying on post-receive not
to trigger when they fetch), so we need to proceed carefully, but I
think it is in the right direction.
I actually am more than sympathetic to this cause. I think the unified
post-sync mechanism is a sensible thing to do, at least in the longer
term.
We might also need to teach push over http (which is not even a second
class citizen) to trigger post-receive if it does not already do so.
^ permalink raw reply
* Re: git svn and the post-receive hook
From: Miklos Vajna @ 2008-08-02 20:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: pascal, git list
In-Reply-To: <7vod4bdvga.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 390 bytes --]
On Sat, Aug 02, 2008 at 01:16:05PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> We might also need to teach push over http (which is not even a second
> class citizen) to trigger post-receive if it does not already do so.
That would be nice, but as far as I understand that is not possible
without ugly hacks like subversion's mod_svn or a CGI script. Or did you
refer to the later?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v2] clone: Add an option to set up a mirror
From: Junio C Hamano @ 2008-08-02 20:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0808022126270.9611@pacific.mpi-cbg.de.mpi-cbg.de>
Thanks for a quick turnaround.
^ permalink raw reply
* Re: More on git over HTTP POST
From: Shawn O. Pearce @ 2008-08-02 20:57 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <48938539.9060003@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> wrote:
> I have investigated a bit what it would take to support git protocol
> (smart transport) over HTTP POST transactions.
I have started to think about this more myself, not just for POST
put also for some form of GET that can return an efficient pack,
rather than making the client walk the object chains itself.
Have you looked at the Mecurial wire protocol? It runs over HTTP
and uses a relatively efficient means of deciding where to cut the
transfer at.
http://www.selenic.com/mercurial/wiki/index.cgi/WireProtocol
Most of their smarts are in the branches() and between() operations.
Unfortunately this documentation isn't very complete and/or there
are some simplifications that the Mecurial team took due to their
repository format not initially supporting multiple branches like
the Git format does.
> The current proxy system is broken, for a very simple reason: it doesn't
> convey information about when the channel should be turned around.
Well, over git:// (or any protocol that wraps git:// like ssh)
we assume a full-duplex channel. Some proxy systems are able to
do such a channel. HTTP however does not offer it.
> I started to hack on a variant which would embed a VFS-style interface
> in git itself, looking something like:
>
> struct transactor;
>
> struct transact_ops {
> ssize_t (*read)(struct transactor *, void *, size_t);
> ssize_t (*write)(struct transactor *, const void *, size_t);
> int (*close)(struct transactor *);
> };
No, the git:// protocol implementation in fetch-pack/upload-pack
runs more efficient than that by keeping a sliding window of stuff
that is in-flight. Its I guess two async RPCs running in parallel,
but from the client and server perspective both RPCs go into the
same computation.
HTTP POST is actually trivial if you don't want to support the new
tell-me-more extension that was added to git-push. Hell, I could
write the CGI in a few minutes I think. Its really just a small
wrapper around git-receive-pack.
What's a bitch is the efficient fetch, and getting tell-me-more to
work on push.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] bash completion: remove unused function _git_diff_tree
From: Shawn O. Pearce @ 2008-08-02 20:59 UTC (permalink / raw)
To: Lee Marlow; +Cc: git
In-Reply-To: <1217652429-58511-1-git-send-email-lee.marlow@gmail.com>
Lee Marlow <lee.marlow@gmail.com> wrote:
> completion for git diff-tree was removed in 5cfb4fe
>
> Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 30d8701..e32c1f1 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -721,11 +721,6 @@ _git_diff ()
> __git_complete_file
> }
>
> -_git_diff_tree ()
> -{
> - __gitcomp "$(__git_refs)"
> -}
> -
> _git_fetch ()
> {
> local cur="${COMP_WORDS[COMP_CWORD]}"
> --
--
Shawn.
^ permalink raw reply
* Re: [PATCH] bash completion: Add more long options for 'git log'
From: Shawn O. Pearce @ 2008-08-02 21:00 UTC (permalink / raw)
To: Lee Marlow; +Cc: git
In-Reply-To: <1217638613-57366-1-git-send-email-lee.marlow@gmail.com>
Lee Marlow <lee.marlow@gmail.com> wrote:
> Options added: --parents --children --full-history
>
> Signed-off-by: Lee Marlow <lee.marlow@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index 30d8701..7132a68 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -853,6 +853,7 @@ _git_log ()
> --stat --numstat --shortstat
> --decorate --diff-filter=
> --color-words --walk-reflogs
> + --parents --children --full-history
> "
> return
> ;;
--
Shawn.
^ permalink raw reply
* Re: More on git over HTTP POST
From: Daniel Stenberg @ 2008-08-02 21:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Git Mailing List
In-Reply-To: <20080802205702.GA24723@spearce.org>
On Sat, 2 Aug 2008, Shawn O. Pearce wrote:
> Well, over git:// (or any protocol that wraps git:// like ssh) we assume a
> full-duplex channel. Some proxy systems are able to do such a channel.
> HTTP however does not offer it.
Yes it does. The CONNECT method is used to get a full-duplex channel to a
remote site through a HTTP proxy. The downside with that is of course that
most proxies are setup to disallow CONNECT to other ports than 443 (the https
default port).
--
/ daniel.haxx.se
^ permalink raw reply
* Re: [PATCH] bash completion: Add completion for 'git grep'
From: Shawn O. Pearce @ 2008-08-02 21:05 UTC (permalink / raw)
To: Lee Marlow; +Cc: git
In-Reply-To: <1217638593-57321-1-git-send-email-lee.marlow@gmail.com>
Lee Marlow <lee.marlow@gmail.com> wrote:
> +_git_grep ()
> +{
> + __git_has_doubledash && return
> +
> + local cur="${COMP_WORDS[COMP_CWORD]}"
> + case "$cur" in
> + --*)
> + __gitcomp "
> + --cached
> + --text --ignore-case --word-regexp --invert-match
> + --full-name
> + --extended-regexp --basic-regexp --fixed-strings
> + --files-with-matches --name-only
> + --files-without-match
> + --count
> + --and --or --not --all-match
> + "
> + return
> + ;;
> + esac
> + COMPREPLY=()
> +}
Hmm. The has_doubledash test seems redundant since we don't do
anything with args that aren't --foo. Even though git-grep will
accept a tree-ish and thus completion of __git_refs here may
make sense.
I wonder if we shouldn't just add to the end something like:
__gitcomp "$(__git_refs)"
like the _git_reset function does. Then we can complete a tree-ish
for searching, as well as honor -- to stop tree-ish completion and
go back to file/directory completion.
But that is very much a user question. Do users mostly search a
file in the current working directory, or do they mostly search
a tree-ish?
--
Shawn.
^ permalink raw reply
* Re: More on git over HTTP POST
From: Shawn O. Pearce @ 2008-08-02 21:08 UTC (permalink / raw)
To: Daniel Stenberg; +Cc: Git Mailing List
In-Reply-To: <alpine.LRH.1.10.0808022257470.25900@yvahk3.pbagnpgbe.fr>
Daniel Stenberg <daniel@haxx.se> wrote:
> On Sat, 2 Aug 2008, Shawn O. Pearce wrote:
>
>> Well, over git:// (or any protocol that wraps git:// like ssh) we
>> assume a full-duplex channel. Some proxy systems are able to do such a
>> channel. HTTP however does not offer it.
>
> Yes it does. The CONNECT method is used to get a full-duplex channel to a
> remote site through a HTTP proxy. The downside with that is of course
> that most proxies are setup to disallow CONNECT to other ports than 443
> (the https default port).
Ah, yes. CONNECT. Very few servers wind up supporting it I think.
I know one very big company who cannot use or support Git because
Git over HTTP is too slow to be useful. They support other tools
like Subversion instead. :-|
Really we just need smart protocol support in half-duplex RPC like
hpa was going after. Then it doesn't matter what we serialize it
into, almost any RPC system will be useful. Of course the only
one that probably matters in practice is HTTP.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: Update German translation
From: Shawn O. Pearce @ 2008-08-02 21:10 UTC (permalink / raw)
To: Christian Stimming; +Cc: git
In-Reply-To: <200808020956.20070.stimming@tuhh.de>
Christian Stimming <stimming@tuhh.de> wrote:
> The subject says it all. Thanks for the new features.
Thanks for taking care of this. I was just about to post something
to ask translators for assitance before the 1.6 release goes final.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Junio C Hamano @ 2008-08-02 21:13 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: Petr Baudis, git
In-Reply-To: <1217701021.8296.35.camel@heerbeest>
Jan Nieuwenhuizen <janneke-list@xs4all.nl> writes:
> 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.
That's something you would say when I cannot decide the color of
bikeshed. I do not think your change falls into that category.
We could add an ad-hoc preprocessing option like this, and keep adding
more for different patterns, and at certain point we may be fed up with
millions of such options and try to introduce a more generic mechanism.
While doing so, the resulting code needs to support the ad-hoc ones that
are added earlier, forever.
We've done that in the past with other commands (cc-suppression scheme in
send-email comes to mind). It was very unpleasant.
> ... Doing this in a single
> regexp is a bit tricky and asking a user to write a perl snippet is even
> worse, imho.
What you are saying is that a built-in one, no matter what, won't be
sufficient for many projects. Unless a user writes Perl snippet to match
his project's needs, the noise at the beginning of the log won't be
stripped for him.
That's fine. I do not expect a single built-in transformation would fit
everybody's needs. I am not asking for miracles.
But you could at least keep the door open for people who are _willing_ to
write such transformation for their projects, right?
For one thing, your --cut-changelog-bits has one fixed pattern. Later
people either have to come up with different option, or modify your
pattern (potentially breaking your project). Neither is good.
Perhaps doing something like this a (admittedly slightly) better option?
It allows you to choose from a canned set, or give a series of s///
rewriting rules (or whatever you would want to have in the custom function)..
---
git-svn.perl | 34 +++++++++++++++++++++++++++++++++-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index cf6dbbc..eaf6a56 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, $_clean_log_message);
$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)",
@@ -238,6 +240,33 @@ 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 =
+(
+ 'ooo' => 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*/ /g if length ($_) < 81;
+ "\n";
+ }
+);
+
+if (defined $_clean_changelog) {
+ if (exists $canned_changelog_cleaner{$_clean_changelog}) {
+ $_clean_log_message = $canned_changelog_cleaner{$_clean_changelog};
+ } elsif ($_clean_changelog ne '') {
+ $_clean_log_message = eval "
+ sub { local(\$_) = \@_; $_clean_changelog; return \$_; }
+ ";
+ if ($@) {
+ die "$!: $_clean_changelog";
+ }
+ } else {
+ die "$_clean_changelog: unknown way to clean log message";
+ }
+}
+
usage(0) if $_help;
version() if $_version;
usage(1) unless defined $cmd;
@@ -2463,6 +2492,9 @@ sub make_log_entry {
close $un or croak $!;
$log_entry{date} = parse_svn_date($log_entry{date});
+ if ($_clean_log_message) {
+ $log_entry{log} = $_clean_log_message->($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}}
^ permalink raw reply related
* git-gui translators - please update translations if necessary
From: Shawn O. Pearce @ 2008-08-02 21:17 UTC (permalink / raw)
To: git
We're getting ready for the git 1.6 release in the not-too-distant
future, and that will ship with gitgui-0.11.
The current tip of my master branch builds as follows. There have
not been many changes in the interface so I don't think there is
much (if any) translation work for this release.
MSGFMT po/de.msg 402 translated.
MSGFMT po/fr.msg 391 translated.
MSGFMT po/hu.msg 391 translated.
MSGFMT po/it.msg 390 translated, 1 untranslated.
MSGFMT po/ja.msg 391 translated.
MSGFMT po/ru.msg 387 translated, 4 untranslated.
MSGFMT po/sv.msg 391 translated.
MSGFMT po/zh_cn.msg 367 translated, 7 fuzzy, 17 untranslated.
Thanks.
--
Shawn.
^ permalink raw reply
* Re: More on git over HTTP POST
From: Petr Baudis @ 2008-08-02 21:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Daniel Stenberg, Git Mailing List
In-Reply-To: <20080802210828.GE24723@spearce.org>
On Sat, Aug 02, 2008 at 02:08:28PM -0700, Shawn O. Pearce wrote:
> I know one very big company who cannot use or support Git because
> Git over HTTP is too slow to be useful. They support other tools
> like Subversion instead. :-|
On what projects? I'm currently using Git over HTTP (read-only) a lot
and it doesn't seem really all that impractical to me. Maybe just using
a more dumb-friendly packing scheme could help a lot?
Petr "Pasky" Baudis
^ permalink raw reply
* gitweb status for 1.6.0?
From: Junio C Hamano @ 2008-08-02 21:28 UTC (permalink / raw)
To: Jakub Narebski, Petr Baudis; +Cc: git, Shawn O. Pearce
In-Reply-To: <20080802211714.GG24723@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> We're getting ready for the git 1.6 release in the not-too-distant
> future, and that will ship with gitgui-0.11.
Thanks.
There have been a handful gitweb patches on the list recently (I think
they were all post -rc0 feature enhancements, but I may be mistaken). I'm
wondering what their status are. Does any of them matter in the current
cycle?
By the way, I've privately pinged Paul for gitk status.
^ permalink raw reply
* Re: More on git over HTTP POST
From: Shawn O. Pearce @ 2008-08-02 21:32 UTC (permalink / raw)
To: Petr Baudis; +Cc: Daniel Stenberg, Git Mailing List
In-Reply-To: <20080802212357.GU32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> On Sat, Aug 02, 2008 at 02:08:28PM -0700, Shawn O. Pearce wrote:
> > I know one very big company who cannot use or support Git because
> > Git over HTTP is too slow to be useful. They support other tools
> > like Subversion instead. :-|
>
> On what projects? I'm currently using Git over HTTP (read-only) a lot
> and it doesn't seem really all that impractical to me. Maybe just using
> a more dumb-friendly packing scheme could help a lot?
They tested by taking the SVN source code and importing it into
both Git and Hg, then cloned them both over a WAN link. Git was
22x slower. I suspect they didn't pack the Git repository at all,
so Git had to issue thousands of HTTP GET requests for the loose
objects. But I also suspect there was bias in the testing so they
didn't realize they needed to repack, and didn't care to find out.
I've probably already said too much. I'm under NDAs.
But anyway. The point I was trying to make was that there are
not just some proxy servers, but also some server platforms, that
cannot handle bidirectional communiction. E.g. servers that are
behind reverse proxies, where the reverse proxy is acting as a sort
of firewall or content cache accelerator.
--
Shawn.
^ permalink raw reply
* Re: git-gui translators - please update translations if necessary
From: Junio C Hamano @ 2008-08-02 21:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080802211714.GG24723@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> We're getting ready for the git 1.6 release in the not-too-distant
> future, and that will ship with gitgui-0.11.
>
> The current tip of my master branch builds as follows. There have
> not been many changes in the interface so I don't think there is
> much (if any) translation work for this release.
>
> MSGFMT po/de.msg 402 translated.
> MSGFMT po/fr.msg 391 translated.
> MSGFMT po/hu.msg 391 translated.
> MSGFMT po/it.msg 390 translated, 1 untranslated.
> MSGFMT po/ja.msg 391 translated.
> MSGFMT po/ru.msg 387 translated, 4 untranslated.
> MSGFMT po/sv.msg 391 translated.
> MSGFMT po/zh_cn.msg 367 translated, 7 fuzzy, 17 untranslated.
Hmm, I am confused.
Grepping po/*.po and po/git-gui.pot for POT-Creation-Date reveals that
po/de.msg is much more recent than po/git-gui.pot and all others are
translating the same POT.
Perhaps you wanted to update git-gui.pot first before sending this request
out?
^ permalink raw reply
* Re: git-gui translators - please update translations if necessary
From: Shawn O. Pearce @ 2008-08-02 21:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vod4bccx8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
>
> Grepping po/*.po and po/git-gui.pot for POT-Creation-Date reveals that
> po/de.msg is much more recent than po/git-gui.pot and all others are
> translating the same POT.
>
> Perhaps you wanted to update git-gui.pot first before sending this request
> out?
Oh. Its updated now, but msgmerge on my system is busted and won't
update the po files themselves. *sigh*
--
Shawn.
^ permalink raw reply
* Re: git-gui translators - please update translations if necessary
From: Junio C Hamano @ 2008-08-02 21:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20080802214930.GA25311@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Grepping po/*.po and po/git-gui.pot for POT-Creation-Date reveals that
>> po/de.msg is much more recent than po/git-gui.pot and all others are
>> translating the same POT.
>>
>> Perhaps you wanted to update git-gui.pot first before sending this request
>> out?
>
> Oh. Its updated now, but msgmerge on my system is busted and won't
> update the po files themselves. *sigh*
I think that's Ok. msgmerge and edit are in the translators' bailiwick.
^ permalink raw reply
* [PATCH] diff: chapter and part in funcname for tex
From: Giuseppe Bilotta @ 2008-08-02 21:56 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <7vprormh7a.fsf@gitster.siamese.dyndns.org>
This patch enhances the tex funcname by adding support for
chapter and part sectioning commands. It also matches
the starred version of the sectioning commands.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
As recommended by Junio, use \{0,1\} instead of \?
diff.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/diff.c b/diff.c
index c253015..776bce1 100644
--- a/diff.c
+++ b/diff.c
@@ -1380,7 +1380,7 @@ static struct builtin_funcname_pattern {
"^[ ]*\\(\\([ ]*"
"[A-Za-z_][A-Za-z_0-9]*\\)\\{2,\\}"
"[ ]*([^;]*\\)$" },
- { "tex", "^\\(\\\\\\(sub\\)*section{.*\\)$" },
+ { "tex", "^\\(\\\\\\(\\(sub\\)*section\\|chapter\\|part\\)\\*\\{0,1\\}{.*\\)$" },
{ "ruby", "^\\s*\\(\\(class\\|module\\|def\\)\\s.*\\)$" },
};
--
1.5.6.3
^ permalink raw reply related
* [PATCH] Fix reference to Everyday Git, which is an HTML document and not a man page.
From: Jon Jensen @ 2008-08-02 21:41 UTC (permalink / raw)
To: git; +Cc: Jon Jensen
Signed-off-by: Jon Jensen <jon@endpoint.com>
---
Documentation/git.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 44ea35e..3da5bf0 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -602,7 +602,7 @@ contributors on the git-list <git@vger.kernel.org>.
SEE ALSO
--------
linkgit:gittutorial[7], linkgit:gittutorial-2[7],
-linkgit:everyday[7], linkgit:gitcvs-migration[7],
+link:everyday.html[Everyday Git], linkgit:gitcvs-migration[7],
linkgit:gitglossary[7], linkgit:gitcore-tutorial[7],
linkgit:gitcli[7], link:user-manual.html[The Git User's Manual]
--
1.6.0.rc1.48.g2b6032
^ 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