* 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: [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: 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 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: 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: 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: [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
* [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: 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
* 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: [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
* Re: git svn and the post-receive hook
From: Junio C Hamano @ 2008-08-02 18:43 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <489485BC.1020607@obry.net>
Pascal Obry <pascal@obry.net> writes:
> I'd like to check for example that if a file has been added to the
> remote Subversion repository then it is properly added into a MANIFEST
> file. I'd also like to check some style rules. This would help to
> detect some problems when one has no way to add hooks on the
> Subversion repository.
Are you saying that there may be breakages that is made at the Subversion
side, and you would want to catch it?
What would you do _after_ finding out that somebody screwed up and you
have a borked history on the Subversion side already?
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".
^ permalink raw reply
* Re: git svn and the post-receive hook
From: Junio C Hamano @ 2008-08-02 18:22 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <489485BC.1020607@obry.net>
Pascal Obry <pascal@obry.net> writes:
> At the moment it seems to me that the post-receive hook is not called
> when tracking a remove Subversion repository.
>
> I think it would be nice to call the post-receive hook at the end of:
>
> $ git svn rebase
>
> Why I need this?
>
> I'd like to check ...
Wait a minute.
Isn't "git svn rebase" an operation that you do on your local repository,
slurping the update from the other end and then replaying your change on
top of it? If so, I think it falls into the same category as "post-fetch"
hook which would run after you run fetch, if such a thing existed. See:
http://thread.gmane.org/gmane.comp.version-control.git/79306/focus=79321
for the reason why we usually do not add such a hook on the local end.
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Jan Nieuwenhuizen @ 2008-08-02 18:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20080802172742.GT32184@machine.or.cz>
On za, 2008-08-02 at 19:27 +0200, Petr Baudis wrote:
> On Sat, Aug 02, 2008 at 03:42:29PM +0200, Jan Nieuwenhuizen wrote:
> > Signed-off-by: Jan Nieuwenhuizen <Jan Nieuwenhuizen janneke@gnu.org>
>
> Just your email should be within the <> brackets.
Oops :-) I have
EMAIL='Jan Nieuwenhuizen <janneke@gnu.org>'
so I should probably use GIT_EMAIL='janneke@gnu.org' or something. I'll
have a look.
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Jan Nieuwenhuizen @ 2008-08-02 18:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, git
In-Reply-To: <7vfxpnnwt5.fsf@gitster.siamese.dyndns.org>
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.
Jan.
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
http://www.xs4all.nl/~jantien | http://www.lilypond.org
^ permalink raw reply
* Re: [PATCH] git-name-rev: allow --name-only in combination with --stdin
From: Junio C Hamano @ 2008-08-02 18:12 UTC (permalink / raw)
To: Pieter de Bie; +Cc: Git Mailinglist, Johannes Schindelin
In-Reply-To: <1217510434-94979-1-git-send-email-pdebie@ai.rug.nl>
Pieter de Bie <pdebie@ai.rug.nl> writes:
> Or was there a specific reason not to allow this?
The --name-only option to the command was added in 1.5.3 cycle, but the
original focus was only to support describe. I do not see any fundamental
reason to disallow it --- we could even say this is a bug.
I've applied the "split single line processing to a separate function" and
then this patch to 'maint' as a bugfix.
^ permalink raw reply
* Re: git svn and the post-receive hook
From: Miklos Vajna @ 2008-08-02 18:03 UTC (permalink / raw)
To: Pascal Obry; +Cc: git list
In-Reply-To: <489485BC.1020607@obry.net>
[-- Attachment #1: Type: text/plain, Size: 722 bytes --]
On Sat, Aug 02, 2008 at 06:05:16PM +0200, Pascal Obry <pascal@obry.net> wrote:
> At the moment it seems to me that the post-receive hook is not called when
> tracking a remove Subversion repository.
Sure. From the "post-receive" hook documentation:
"This hook is invoked by 'git-receive-pack' on the remote repository,
which happens when a 'git-push' is done on a local repository."
And git svn will never invoke git receive-pack.
> I think it would be nice to call the post-receive hook at the end of:
>
> $ git svn rebase
What about a post-rebase hook, like there is a post-merge one?
> I have zero experience with Perl so I do not feel like hacking this myself.
git rebase is shell. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] diff: chapter and part in funcname for tex
From: Junio C Hamano @ 2008-08-02 17:59 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git
In-Reply-To: <1217678145-2630-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> 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>
>
> ---
>
> Resend, with Signed-off-by: line
>
> 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\\)\\*\\?{.*\\)$" },
Ok on idea, but NAK on implementation.
"A\?" to mean 0 or one "A" in BRE is GNU extention and we try to avoid it.
"A\{0,1\}" is equivalent and we already use the bound notation in "java"
section, so perhaps this is an Ok replacement?
{ "tex", "^\\(\\\\\\(\\(sub\\)*section\\|chapter\\|part\\)\\*\\{0,1\\}{.*\\)$" },
^ permalink raw reply
* Re: email address handling
From: Junio C Hamano @ 2008-08-02 17:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Andrew Morton, Theodore Tso, git
In-Reply-To: <alpine.LFD.1.10.0808020916370.3318@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sat, 2 Aug 2008, Johannes Schindelin wrote:
>>
>> Ah, there lies the rub (you forgot that the original complaint was about
>> a comma, and pretty=email does not handle those):
>
> Indeed.
>
> I wonder where that is_rfc2047_special() function came from. The list of
> "special" characters is totally bogus.
>
> The real RFC has comma, but it has a lot of other characters too:
>
> especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" /
> "<" / "> / "/" / "[" / "]" / "?" / "." / "="
>
> because basically the rfc2047 encoding has to be a superset of the 822
> (and later 2822) encodings.
Hmm, you're right. This has to be trickier than I originally thought it
would be ... ;-)
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Junio C Hamano @ 2008-08-02 17:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jan Nieuwenhuizen, git
In-Reply-To: <20080802172742.GT32184@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Hi!
>
> On Sat, Aug 02, 2008 at 03:42:29PM +0200, Jan Nieuwenhuizen wrote:
>> Signed-off-by: Jan Nieuwenhuizen <Jan Nieuwenhuizen janneke@gnu.org>
>
> Just your email should be within the <> brackets.
>
>> ---
>> git-svn.perl | 11 ++++++++++-
>> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> 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.
^ permalink raw reply
* Re: [PATCH] hash-object --no-filters
From: Junio C Hamano @ 2008-08-02 17:28 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Alexander Litvinov, git, Eric Wong
In-Reply-To: <20080801220932.GK7008@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> writes:
> The --no-filters option makes git hash-object to work as there were no
> input filters. This option is useful for importers such as git-svn to
> put new version of files as is even if autocrlf is set.
I think this is going in the right direction, but I have to wonder a few
things.
First, on hash-object.
(1) "hash-object --stdin" always hashes literally. We may want to be
able to say "The contents is this but pretend it came from this path
and apply the usual input rules", perhaps with "--path=" option;
(2) "hash-object temporaryfile" may want to honor the same "--path"
option;
(3) "hash-object --stdin-paths" may want to get pair of paths (i.e. two
lines per entry) to do the same.
If we want to do the above, the existing low-level interface needs to be
adjusted.
index_pipe() and index_fd() can learn to take an additional string
parameter for attribute lookup to implement (1) and (2) above. Perhaps
the string can be NULL to signal --no-filter behaviour, in which case the
HASH_OBJECT_LITERALLY change may not be necessary for this codepath.
index_path() is a healper for add_to_index() which is used for normal
addition of working tree entities, and I do not see an immediate need to
teach it about this "use this different path for attribute lookup" at
least for now.
By the way, why do we have index_pipe() and index_fd() to begin with? Is
it because users of index_pipe() do not know what the path it is hashing
and also the fd being a pipe we cannot mmap it?
If these two are the only reasons, then I wonder if we can:
- accept NULL as path and stat parameters for callers without a filename
(which automatically implies we are doing a regular blob and we hash
literally); and
- first try to mmap(), and if it fails fall back to the "read once into
strbuf" codepath to solve mmap-vs-pipe issue.
I am not sure if such a unification of these two functions is useful,
though.
^ permalink raw reply
* Re: [PATCH] git-svn.perl: Strip ChangeLog bits.
From: Petr Baudis @ 2008-08-02 17:27 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git
In-Reply-To: <1217684549.8296.10.camel@heerbeest>
Hi!
On Sat, Aug 02, 2008 at 03:42:29PM +0200, Jan Nieuwenhuizen wrote:
> Signed-off-by: Jan Nieuwenhuizen <Jan Nieuwenhuizen janneke@gnu.org>
Just your email should be within the <> brackets.
> ---
> git-svn.perl | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
You forgot to document your option. (And possibly write a testcase.)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: email address handling
From: Linus Torvalds @ 2008-08-02 17:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Andrew Morton, Theodore Tso, git
In-Reply-To: <alpine.DEB.1.00.0808021857350.9611@pacific.mpi-cbg.de.mpi-cbg.de>
On Sat, 2 Aug 2008, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 2 Aug 2008, Junio C Hamano wrote:
>
> > Linus Torvalds <torvalds@linux-foundation.org> writes:
> >
> > > I wonder where that is_rfc2047_special() function came from.
>
> It comes straight from cdd406e(CMIT_FMT_EMAIL: Q-encode Subject: and
> display-name part of From: fields.).
That's not what I meant.
I meant "what drugs induced somebody to write that function and give it
that name, since it clearly has never seen rfc2047, and has nothing to do
with it".
In other words, it sure as hell didn't come from the rfc2047 in this
universe, so it must have come from some exciting alternate alien universe
with different laws of nature and internet.
Or maybe there's just another rfc2047 that I've not heard of.
Linus
^ permalink raw reply
* Re: email address handling
From: Johannes Schindelin @ 2008-08-02 16:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Andrew Morton, Theodore Tso, git
In-Reply-To: <7vej57pe5q.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 2 Aug 2008, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > I wonder where that is_rfc2047_special() function came from.
It comes straight from cdd406e(CMIT_FMT_EMAIL: Q-encode Subject: and
display-name part of From: fields.).
Ciao,
Dscho
^ permalink raw reply
* Re: email address handling
From: Junio C Hamano @ 2008-08-02 16:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Andrew Morton, Theodore Tso, git
In-Reply-To: <7vabfvpdyk.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> On Sat, 2 Aug 2008, Johannes Schindelin wrote:
>>>
>>> Ah, there lies the rub (you forgot that the original complaint was about
>>> a comma, and pretty=email does not handle those):
>>
>> Indeed.
>>
>> I wonder where that is_rfc2047_special() function came from. The list of
>> "special" characters is totally bogus.
>
> This function is about quoting inside dq pair, so the function does not
s/is about/is NOT about/;
Sorry, I should grab coffee before continuing.
> look at the set you listed. It is about quoting non-ascii chars using the
> ?charset?Q? or ?charset?B? notation.
>
> If we want to use double quotes that should be done elsewhere, not in that
> function.
^ 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