* Re: Merging commits together into a super-commit
From: Junio C Hamano @ 2007-05-12 19:27 UTC (permalink / raw)
To: Yann Dirson
Cc: Carl Worth, Petr Baudis, J. Bruce Fields, Linus Torvalds,
Johannes Sixt, git
In-Reply-To: <20070512144145.GF16903@nan92-1-81-57-214-146.fbx.proxad.net>
Yann Dirson <ydirson@altern.org> writes:
> On Sat, May 12, 2007 at 04:02:28PM +0200, Karl Hasselström wrote:
>> ...
>> What we should do is delete all stgit metadata when the last patch
>> goes away.
>
> This supposes there is no valuable branch-level metadata. Currently
> we have the description - something which could arguably be moved to
> the git level as well. Otherwise that sounds reasonable to me.
Will it be something like
[branch "master"]
description = "My primary development line"
if so I think that is a reasonable thing to do, from git-core's
point of view. Obviously, gitk, tig, gitweb and friends can use
this, too.
Are there other per-branch information StGIT wants to keep on an
active branch that might benefit the core as well?
>> And we shouldn't have "stg init", either. Initing should be done
>> automatically when needed.
>
> Good idea as well, that would make stg more accessible to the average
> plain-git user.
Yes, I wished for this often myself.
^ permalink raw reply
* Re: [PATCH] git-archive: don't die when repository uses subprojects
From: Junio C Hamano @ 2007-05-12 19:27 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <11789025212823-git-send-email-hjemli@gmail.com>
Thanks.
^ permalink raw reply
* Re: [PATCH 1/3] Move remote parsing into a library file out of builtin-push.
From: Junio C Hamano @ 2007-05-12 19:27 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705121144130.18541@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> +static int handle_config(const char *key, const char *value)
> +{
> + const char *name;
> + const char *subkey;
> + struct remote *remote;
> + if (!prefixcmp(key, "branch.") && current_branch &&
> + !strncmp(key + 7, current_branch, current_branch_len) &&
> + !strcmp(key + 7 + current_branch_len, ".remote")) {
> + free(default_remote_name);
> + default_remote_name = xstrdup(value);
> + }
> + if (prefixcmp(key, "remote."))
> + return 0;
> + name = key + 7;
> + subkey = strrchr(name, '.');
> + if (!subkey)
> + return error("Config with no key for remote %s", name);
> + remote = make_remote(name, subkey - name);
> + if (!strcmp(subkey, ".url")) {
> + add_uri(remote, xstrdup(value));
> + } else if (!strcmp(subkey, ".push")) {
> + add_push_refspec(remote, xstrdup(value));
> + } else if (!strcmp(subkey, ".receivepack")) {
> + if (!remote->receivepack)
> + remote->receivepack = xstrdup(value);
> + else
> + error("more than one receivepack given, using the first");
> + }
> + return 0;
> +}
You forgot to update this part? With your comments on not
erroring out, which made sense to me, how about this?
diff --git a/remote.c b/remote.c
index dbcc74e..b032e81 100644
--- a/remote.c
+++ b/remote.c
@@ -150,7 +150,26 @@ static int handle_config(const char *key, const char *value)
subkey = strrchr(name, '.');
if (!subkey)
return error("Config with no key for remote %s", name);
+ if (*subkey == '/') {
+ warning("Config remote shorthand cannot begin with '/': %s", name);
+ return 0;
+ }
remote = make_remote(name, subkey - name);
+ if (!value) {
+ /* if we ever have a boolean variable, e.g. "remote.*.disabled"
+ * [remote "frotz"]
+ * disabled
+ * is a valid way to set it to true; we get NULL in value so
+ * we need to handle it here.
+ *
+ * if (!strcmp(subkey, ".disabled")) {
+ * val = git_config_bool(key, value);
+ * return 0;
+ * } else
+ *
+ */
+ return 0; /* ignore unknown booleans */
+ }
if (!strcmp(subkey, ".url")) {
add_uri(remote, xstrdup(value));
} else if (!strcmp(subkey, ".push")) {
^ permalink raw reply related
* Re: [PATCH] Updated documentation of hooks in git-receive-pack.
From: Junio C Hamano @ 2007-05-12 19:27 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20070512171113.GA8100@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
> Added documentation of pre-receive and post-receive hooks and updated
> documentation of update and post-update hooks.
>
> Signed-off-by: Jan Hudec <bulb@ucw.cz>
Thanks, much appreciated. Domain ucw.cz sounds familiar; are
you close by to Pasky?
> +[[pre-receive]]
> +pre-receive
>...
> +This hook executes once for the receive operation. It takes no
> +arguments, but for each ref to be updated it receives on standard
> +input a line of the format:
> +
> + <old-value> SP <new-value> SP <ref-name> NL
> +
> +where `<old-value>` is the old object name stored in the ref,
> +`<new-value>` is the new object name to be stored in the ref and
> +`<ref-name>` is the full name of the ref.
s/NL/LF/
When creating a new ref, `<old-value>` is 40 `0`.
> +If the hook exits with non-zero status, none of the refs will be
> +updated. If the hook returs zero, updating of individual refs can
> +still be prevented by the <<update,'update'>> hook.
s/returs/exits with/
> +The standard output of this hook is sent to `stderr`, so if you
> +want to report something to the `git-send-pack` on the other end,
> +you can simply `echo` your messages.
I think "sent to stderr" is a implementation detail between
receive-pack and hook scripts. I would just keep the "if you
want to..." part.
> +[[post-receive]]
> +post-receive
> +------------
> +
> +This hook is invoked by `git-receive-pack` on the remote repository,
> +which happens when a `git push` is done on a local repository.
> +It executes on the remote repository once after all the refs have
> +been updated.
> +
> +This hook executes once for the receive operation. It takes no
> +arguments, but for each ref that was updated it receives on standard
> +input a line of the format:
> +
> + <old-value> SP <new-value> SP <ref-name> NL
> +
> +on stdin, where `<old-value>` is the old object name stored in the
> +ref, `<new-value>` is the new object name to be stored in the ref and
> +`<ref-name>` is the full name of the ref.
Maybe
It takes no arguments, but gets the same information as
the `pre-receive` hook does on its standard input.
to avoid the duplicated description.
> +This hook cannot affect the outcome of `git-receive-pack`, as it's
> +called after the real work is done.
> +
> +This superceedes the [[post-update]] hook in that it actually get's
> +both old and new values of all the refs.
s/superceedes/supersedes/
> +The standard output of this hook is sent to `stderr`, so if you
> +want to report something to the `git-send-pack` on the other end,
> +you can simply `echo` your messages.
Ditto.
> +[[post-update]]
> post-update
> -----------
>
> @@ -146,7 +214,8 @@ the outcome of `git-receive-pack`.
>
> The 'post-update' hook can tell what are the heads that were pushed,
> but it does not know what their original and updated values are,
> -so it is a poor place to do log old..new.
> +so it is a poor place to do log old..new. See
> +<<post-receive,'post-receive'>> hook above for a better one.
Instead of just passing 'a better one' judgement without
rationale, it is more helpful to explain why the newer ones are
recommended, so that the reader can agree to it.
In general, `post-receive` hook is preferred when the hook needs
to decide its acion on the status of the entire set of refs
being updated, as this hook is called once per ref, with
information only on a single ref at a time.
^ permalink raw reply
* [PATCH] cvsserver: Complete rewrite of the configuration parser
From: Frank Lichtenheld @ 2007-05-12 19:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff, Frank Lichtenheld
In-Reply-To: <7v8xbvj5mx.fsf@arte.twinsun.com>
Move the configuration parsing to a separate GITCVS::config
module. Simplifies using the configuration in the rest of
the code.
Restrict parsed configuration variables to
^gitcvs\.((ext|pserver)\.)?
since we don't use anything else anyway. This also
reduces the risk of getting confused with arbitrary
variables (especially arbitrary subsection names).
Also fixes a bug where the config parser got confused
if a section had a subsection and a variable with the
same name.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
---
git-cvsserver.perl | 187 ++++++++++++++++++++++++++++++++++++++++++++--------
1 files changed, 158 insertions(+), 29 deletions(-)
Maybe a bit overkill if one only wants to solve the problem Junio discovered
but I believe it's still worthwile.
Has a lot of overlap with perl/Git.pm though...
Not extensively tested but it at least passes the test cases and creates a useful
log which should take care of the two main code paths (get_gitcvs and
get_gitcvs_bool).
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 3e7bf5b..e51ffd0 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -174,27 +174,17 @@ sub req_Root
return 0;
}
- my @gitvars = `git-config -l`;
- if ($?) {
- print "E problems executing git-config on the server -- this is not a git repository or the PATH is not set correctly.\n";
- print "E \n";
- print "error 1 - problem executing git-config\n";
- return 0;
- }
- foreach my $line ( @gitvars )
- {
- next unless ( $line =~ /^(.*?)\.(.*?)(?:\.(.*?))?=(.*)$/ );
- unless ($3) {
- $cfg->{$1}{$2} = $4;
- } else {
- $cfg->{$1}{$2}{$3} = $4;
- }
+ $cfg = GITCVS::config->new();
+
+ unless ($cfg) {
+ print "E problems executing git-config on the server -- ".
+ "this is not a git repository or the PATH is not set correctly.\n";
+ print "E \n";
+ print "error 1 - problem executing git-config\n";
+ return 0;
}
- unless ( ($cfg->{gitcvs}{$state->{method}}{enabled}
- and $cfg->{gitcvs}{$state->{method}}{enabled} =~ /^\s*(1|true|yes)\s*$/i)
- or ($cfg->{gitcvs}{enabled}
- and $cfg->{gitcvs}{enabled} =~ /^\s*(1|true|yes)\s*$/i) )
+ unless ( $cfg->get_gitcvs_bool($state->{method},'enabled') )
{
print "E GITCVS emulation needs to be enabled on this repo\n";
print "E the repo config file needs a [gitcvs] section added, and the parameter 'enabled' set to 1\n";
@@ -203,7 +193,7 @@ sub req_Root
return 0;
}
- my $logfile = $cfg->{gitcvs}{$state->{method}}{logfile} || $cfg->{gitcvs}{logfile};
+ my $logfile = $cfg->get_gitcvs($state->{method},'logfile');
if ( $logfile )
{
$log->setfile($logfile);
@@ -1967,7 +1957,7 @@ sub kopts_from_path
# what attributes apply to this path.
# Until then, take the setting from the config file
- unless ( defined ( $cfg->{gitcvs}{allbinary} ) and $cfg->{gitcvs}{allbinary} =~ /^\s*(1|true|yes)\s*$/i )
+ unless ( $cfg->get_gitcvs_bool('allbinary') )
{
# Return "" to give no special treatment to any path
return "";
@@ -1978,6 +1968,147 @@ sub kopts_from_path
}
}
+package GITCVS::config;
+
+####
+#### Copyright 2007 Frank Lichtenheld <frank@lichtenheld.de>.
+####
+
+use strict;
+use warnings;
+
+=head1 NAME
+
+GITCVS::config -- interface to the git configuration files
+
+=head1 DESCRIPTION
+
+Parses the output of "git-config -l" once and then allows to access that
+information
+
+=head1 METHODS
+
+=cut
+
+=head2 new
+
+Creates a new object and retrieves the config information.
+If retrieving the configuration fails, returns undef.
+
+=cut
+sub new
+{
+ my $class = shift;
+
+ my $self = {};
+
+ bless $self, $class;
+
+ $self->update() or return;
+
+ return $self;
+}
+
+=head2 update
+
+Update the config information. Is called by new on creation.
+Currently limits itself to the variables actually used by
+git-cvsserver since the output of git-config -l is not actually
+completly maschine-parsable. Multi-valued variables are not
+supported, the last value found is used.
+
+=cut
+sub update
+{
+ my $self = shift;
+
+ my @gitvars = `git-config -l`;
+ return if $?;
+ foreach my $line ( @gitvars )
+ {
+ next unless ( $line =~ /^((gitcvs)\.(?:(ext|pserver)\.)?([\w-]+))=(.*)$/ );
+ $self->{cfg}{$1} = $5;
+ }
+
+ return $self;
+}
+
+=head2 get
+
+Retrieve a configuration value. Give the key as array.
+
+=cut
+sub get {
+ my $self = shift;
+ my @key = @_;
+
+ unless (($#key == 1)
+ || ($#key == 2)) {
+ return;
+ }
+
+ $key[0] = lc $key[0];
+ $key[-1] = lc $key[-1];
+
+ my $key = join('.',@key);
+ if (exists $self->{cfg}{$key}) {
+ return $self->{cfg}{$key};
+ }
+ return;
+}
+
+=head2 get_bool
+
+Retrieve a configuration value. Give the key as array.
+Normalizes the value to either undef, 0, or 1.
+
+=cut
+sub get_bool {
+ my $self = shift;
+ my $value = $self->get(@_);
+
+ return unless defined($value);
+ return 1 if $value =~ /^\s*(1|true|yes)\s*$/i;
+ return 0;
+}
+
+=head2 get_gitcvs
+
+Like get(), but automatically assumes gitcvs as section.
+If given two paramters, tries with second one alone
+if the first query gave no result.
+
+=cut
+sub get_gitcvs {
+ my $self = shift;
+ my @key = @_;
+
+ my $value = $self->get('gitcvs',@key);
+ if (!defined($value) && ($#key == 1)) {
+ $value = $self->get('gitcvs',$key[1]);
+ }
+
+ return $value;
+}
+
+=head2 get_gitcvs_bool
+
+What get_bool is to get that
+is get_gitcvs_bool to get_gitcvs.
+
+=cut
+sub get_gitcvs_bool {
+ my $self = shift;
+ my @key = @_;
+
+ my $value = $self->get_bool('gitcvs',@key);
+ if (!defined($value) && ($#key == 1)) {
+ $value = $self->get_bool('gitcvs',$key[1]);
+ }
+
+ return $value;
+}
+
package GITCVS::log;
####
@@ -2189,14 +2320,12 @@ sub new
die "Git repo '$self->{git_path}' doesn't exist" unless ( -d $self->{git_path} );
- $self->{dbdriver} = $cfg->{gitcvs}{$state->{method}}{dbdriver} ||
- $cfg->{gitcvs}{dbdriver} || "SQLite";
- $self->{dbname} = $cfg->{gitcvs}{$state->{method}}{dbname} ||
- $cfg->{gitcvs}{dbname} || "%Ggitcvs.%m.sqlite";
- $self->{dbuser} = $cfg->{gitcvs}{$state->{method}}{dbuser} ||
- $cfg->{gitcvs}{dbuser} || "";
- $self->{dbpass} = $cfg->{gitcvs}{$state->{method}}{dbpass} ||
- $cfg->{gitcvs}{dbpass} || "";
+ $self->{dbdriver} = $cfg->get_gitcvs($state->{method},'dbdriver') ||
+ "SQLite";
+ $self->{dbname} = $cfg->get_gitcvs($state->{method},'dbname') ||
+ "%Ggitcvs.%m.sqlite";
+ $self->{dbuser} = $cfg->get_gitcvs($state->{method},'dbuser') || "";
+ $self->{dbpass} = $cfg->get_gitcvs($state->{method},'dbpass') || "";
my %mapping = ( m => $module,
a => $state->{method},
u => getlogin || getpwuid($<) || $<,
--
1.5.1.4
^ permalink raw reply related
* Re: [BUG?] Detaching head at checked out point does not work.
From: Junio C Hamano @ 2007-05-12 19:35 UTC (permalink / raw)
To: Jan Hudec; +Cc: git
In-Reply-To: <20070512191833.GA8983@efreet.light.src>
Jan Hudec <bulb@ucw.cz> writes:
> On Sat, May 12, 2007 at 11:26:53 -0700, Junio C Hamano wrote:
>> Jan Hudec <bulb@ucw.cz> writes:
>>
>> > I can correctly detach head by saying:
>> >
>> > git checkout master^0
>> >
>> > (or git checkout master^{} or git checkout refs/heads/master), but NONE of
>> > these work, if I currently have master checked out. Shouldn't it detach
>> > anyway?
>>
>> Yes, and it does as far as I know.
>>
>> Do you have 3e0318a3?
>
> It does not seem to be in 1.5.1.4, so no, I don't.
As that commit is directly on top of v1.5.1, I think it may not
hurt to cherry-pick that single commit to 'maint' for 1.5.1.5,
although some may argue that it is not strictly a bugfix but a
new feature.
^ permalink raw reply
* Re: [PATCH] t9400: Use the repository config and nothing else.
From: Frank Lichtenheld @ 2007-05-12 19:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcqi2c1g.fsf@assigned-by-dhcp.cox.net>
On Sat, May 12, 2007 at 10:21:15AM -0700, Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
> When you prepare gitcvs.enabled config in the cloned gitcvs.git
> repository, you do not want to have GIT_CONFIG=.git/config in
> the environment. As you give GIT_DIR to these two commands, not
> having GIT_CONFIG would make them do the right thing.
Yeah, which was the reason I unset it in the first place. But
if your concern is not to use other config files it should still
set GIT_CONFIG explicetly for these cases and leave it to the
default for all calls inside the non-bare repository, right?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH 0/3] Remotes library, take 4
From: Daniel Barkalow @ 2007-05-12 19:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfy61zvtx.fsf@assigned-by-dhcp.cox.net>
On Sat, 12 May 2007, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > Updated for recent review. If remote section name starts with '/', it is
> > ignored (like in 1.5.0). If a remote section option has no value, it is
> > also ignored (so it doesn't crash, and to be forward-compatible if we
> > introduce a boolean option later).
> >
> > The struct refspec field and associated variables are spelled "dst".
> >
> > Part 3 is unchanged.
>
> It cannot be left unchanged as it is affected by the dest stuff.
>
> I'll push out a fixed-up one on 'pu' soonish. Let's stabilize
> this a bit without too many resends.
Yeah, I think we agree on how it should be now, and I'm just confusing
myself regenerating patches. Although, possibly, the comment about NULL
value should go into documentation for config_fn_t instead, since it's of
more general applicability than just this.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] cvsserver: Complete rewrite of the configuration parser
From: Junio C Hamano @ 2007-05-12 19:59 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git, Martin Langhoff, Petr Baudis
In-Reply-To: <11789982521112-git-send-email-frank@lichtenheld.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> Maybe a bit overkill if one only wants to solve the problem Junio discovered
> but I believe it's still worthwile.
>
> Has a lot of overlap with perl/Git.pm though...
>
> Not extensively tested but it at least passes the test cases and creates a useful
> log which should take care of the two main code paths (get_gitcvs and
> get_gitcvs_bool).
I agree that the general direction should be to do something
like this in perl/Git.pm (Pasky CC'ed). As there are some
things that current Git.pm config interface does not offer an
easy access to what you would want to do, we need to enumerate
what you need, decide if they are of general interest and design
what to put in Git.pm and what to implement in GITCVS::config as
a special-purpose feature.
perl/Git.pm currently gives us only this:
- grab all values for a named variable, in an array;
- return canonicalized value for a named boolean variable;
GITCVS::config wants to read *everything* from config and
returns a 'config' instance you can:
- enumerate keys (you do not have this, but it is easy to add);
- retrieve a value for a key (either one- or two-level);
- retrieve a canonicalized bool value for a key (either one- or
two-level);
- treat a request for "gitcvs.method.option" variable to fall
back on "gitcvs.option" if the former is not given;
- the same for boolean variant.
I think the best abstraction is to have the "read everything"
interface in perl/Git.pm side, make the current Git::config()
and Git::config_bool() interface to use it (without issuing
extra 'git config --get-all'). I am not sure it is common for
Git.pm users to want the behaviour of "section.method.option"
falling back to "section.option", but if it is common enough, it
probably is a good idea to have:
sub config_fallback {
my ($self, $section, $specific, $var) = @_;
my $cfg = $self->config();
if (exists $cfg{"$section.$specific.$var"}) {
return $cfg{"$section.$specific.$var"};
}
if (exists $cfg{"$section.$var"}) {
return $cfg{"$section.$var"};
}
return undef;
}
on perl/Git.pm side.
But all of this is post 1.5.2 material; we would want to have a
minimal fixup on 'master' before 1.5.2, independent of this
rewrite.
^ permalink raw reply
* Re: how to set up e-mail notification?
From: Oliver Kullmann @ 2007-05-12 20:11 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705120232320.30969@beast.quantumfyre.co.uk>
>
> There's one in the standard git source tree:
> contrib/hooks/post-receive-email
>
> never used it myself ...
>
Thanks! That script looks quite complicated, so as a quick
solution I just added to hooks/post-receive the line
mutt -s "Git push Repository-Name -- $USER" e-mail-addresses
so that at least the users see that something happened, and
I'll investigate contrib/hooks/post-receive-email.
Oliver
^ permalink raw reply
* Re: [PATCH] Updated documentation of hooks in git-receive-pack.
From: Jan Hudec @ 2007-05-12 20:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz09yh8n.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 3371 bytes --]
On Sat, May 12, 2007 at 12:27:52 -0700, Junio C Hamano wrote:
> Jan Hudec <bulb@ucw.cz> writes:
>
> > Added documentation of pre-receive and post-receive hooks and updated
> > documentation of update and post-update hooks.
> >
> > Signed-off-by: Jan Hudec <bulb@ucw.cz>
>
> Thanks, much appreciated. Domain ucw.cz sounds familiar; are
> you close by to Pasky?
Studied the same faculty.
> [...]
> > +The standard output of this hook is sent to `stderr`, so if you
> > +want to report something to the `git-send-pack` on the other end,
> > +you can simply `echo` your messages.
>
> I think "sent to stderr" is a implementation detail between
> receive-pack and hook scripts. I would just keep the "if you
> want to..." part.
It's actually original wording from description of 'update'. I think just
leaving out the stderr thing is not right, because it's important that both
stdout and stderr go to the same place. I'll change it to:
Both standard output and error output are forwarded to `git-send-pack` on
the other end, so you can simply `echo` messages for the user.
> > +[[post-receive]]
> > +post-receive
> > +------------
> > +
> > +This hook is invoked by `git-receive-pack` on the remote repository,
> > +which happens when a `git push` is done on a local repository.
> > +It executes on the remote repository once after all the refs have
> > +been updated.
> > +
> > +This hook executes once for the receive operation. It takes no
> > +arguments, but for each ref that was updated it receives on standard
> > +input a line of the format:
> > +
> > + <old-value> SP <new-value> SP <ref-name> NL
> > +
> > +on stdin, where `<old-value>` is the old object name stored in the
> > +ref, `<new-value>` is the new object name to be stored in the ref and
> > +`<ref-name>` is the full name of the ref.
>
> Maybe
>
> It takes no arguments, but gets the same information as
> the `pre-receive` hook does on its standard input.
>
> to avoid the duplicated description.
Makes sense.
> > +[[post-update]]
> > post-update
> > -----------
> >
> > @@ -146,7 +214,8 @@ the outcome of `git-receive-pack`.
> >
> > The 'post-update' hook can tell what are the heads that were pushed,
> > but it does not know what their original and updated values are,
> > -so it is a poor place to do log old..new.
> > +so it is a poor place to do log old..new. See
> > +<<post-receive,'post-receive'>> hook above for a better one.
>
> Instead of just passing 'a better one' judgement without
> rationale, it is more helpful to explain why the newer ones are
> recommended, so that the reader can agree to it.
>
> In general, `post-receive` hook is preferred when the hook needs
> to decide its acion on the status of the entire set of refs
> being updated, as this hook is called once per ref, with
> information only on a single ref at a time.
Yes, it's probably better. Though in this case the post-update hook should be
really obsoleted. It takes names of all updated refs on command-line, which
is unlikely to fail on linux, but might fail on Windows where the
command-line lenght is much more limited. But for now I'll just mention that
the other hook does have the information this one does not.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [BUG?] Detaching head at checked out point does not work.
From: Jan Hudec @ 2007-05-12 20:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd515ygw5.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]
On Sat, May 12, 2007 at 12:35:22 -0700, Junio C Hamano wrote:
> Jan Hudec <bulb@ucw.cz> writes:
>
> > On Sat, May 12, 2007 at 11:26:53 -0700, Junio C Hamano wrote:
> >> Jan Hudec <bulb@ucw.cz> writes:
> >>
> >> > I can correctly detach head by saying:
> >> >
> >> > git checkout master^0
> >> >
> >> > (or git checkout master^{} or git checkout refs/heads/master), but NONE of
> >> > these work, if I currently have master checked out. Shouldn't it detach
> >> > anyway?
> >>
> >> Yes, and it does as far as I know.
> >>
> >> Do you have 3e0318a3?
> >
> > It does not seem to be in 1.5.1.4, so no, I don't.
>
> As that commit is directly on top of v1.5.1, I think it may not
> hurt to cherry-pick that single commit to 'maint' for 1.5.1.5,
> although some may argue that it is not strictly a bugfix but a
> new feature.
I would not call it a new feature, since it worked if I had something else
than master checked out. It is not a regression though and given that 1.5.2
is getting closer I'm not sure it's worth bothering.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] format-patch stuff
From: Junio C Hamano @ 2007-05-12 20:24 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0705121109520.18541@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> It would be nice if git-format-patch would generate a [PATCH 0/n] message
> at the start of the series if some option were given. This would, of
> course, have to be editted afterwards to include actual information, but
> it would at least be pre-generated in series and with the configured
> headers and such.
It would be helpful for git-send-email users. I've done that by
hand by copying 0001-*.txt to 0000-*.txt and editing as needed
by hand.
> Shouldn't the format.headers configuration automatically apply the correct
> line termination? Currently, you need to know to put in \r\n at the end of
> each one, and the example isn't even right (only puts \n).
Sorry, I do not follow. Where does that "\r\n" come from? If
you are talking about RFC 2822 line ending conventions, I think
that is a job for MUA (including git-send-email). Remember,
MUA's are not the only consumer of format-patch output.
Although "2.3. Body" says "CR and LF MUST only occur together as
CRLF", the body of the text we output from format-patch is a
straight text with LF termination and let the MUA handle that
SMTP specific conversion. I do not think there is reason to
treat the header part any differently.
^ permalink raw reply
* [PATCH] Updated documentation of hooks in git-receive-pack.
From: Jan Hudec @ 2007-05-12 20:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20070512201309.GB8983@efreet.light.src>
Added documentation of pre-receive and post-receive hooks and updated
documentation of update and post-update hooks.
Signed-off-by: Jan Hudec <bulb@ucw.cz>
---
Resubmitting the patch including the changes based on review.
Documentation/hooks.txt | 90 +++++++++++++++++++++++++++++++++++++++++------
1 files changed, 79 insertions(+), 11 deletions(-)
diff --git a/Documentation/hooks.txt b/Documentation/hooks.txt
index b083290..db23dc4 100644
--- a/Documentation/hooks.txt
+++ b/Documentation/hooks.txt
@@ -90,6 +90,38 @@ parameter, and is invoked after a commit is made.
This hook is meant primarily for notification, and cannot affect
the outcome of `git-commit`.
+[[pre-receive]]
+pre-receive
+-----------
+
+This hook is invoked by `git-receive-pack` on the remote repository,
+which happens when a `git push` is done on a local repository.
+Just before starting to update refs on the remote repository, the
+pre-receive hook is invoked. Its exit status determines the success
+or failure of the update.
+
+This hook executes once for the receive operation. It takes no
+arguments, but for each ref to be updated it receives on standard
+input a line of the format:
+
+ <old-value> SP <new-value> SP <ref-name> NL
+
+where `<old-value>` is the old object name stored in the ref,
+`<new-value>` is the new object name to be stored in the ref and
+`<ref-name>` is the full name of the ref. When creating a new ref,
+the `<old-value>` is 40 `0`.
+
+If the hook exits with non-zero status, none of the refs will be
+updated. If the hook exits with zero, updating of individual refs can
+still be prevented by the <<update,'update'>> hook.
+
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
+
+There is no default 'pre-receive' hook.
+
+[[update]]
update
------
@@ -108,7 +140,8 @@ three parameters:
A zero exit from the update hook allows the ref to be updated.
Exiting with a non-zero status prevents `git-receive-pack`
-from updating the ref.
+from updating that ref. When creating a new ref,
+<old-value> is 40 `0`.
This hook can be used to prevent 'forced' update on certain refs by
making sure that the object name is a commit object that is a
@@ -117,19 +150,51 @@ That is, to enforce a "fast forward only" policy.
It could also be used to log the old..new status. However, it
does not know the entire set of branches, so it would end up
-firing one e-mail per ref when used naively, though.
+firing one e-mail per ref when used naively, though. The
+<<post-receive,'post-receive'>> hook is more suited to that.
Another use suggested on the mailing list is to use this hook to
implement access control which is finer grained than the one
based on filesystem group.
-The standard output of this hook is sent to `stderr`, so if you
-want to report something to the `git-send-pack` on the other end,
-you can simply `echo` your messages.
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
+
+The default 'update' hook, when enabled--and with
+`hooks.allowunannotated` config option turned on--prevents
+unannotated tags to be pushed.
+
+[[post-receive]]
+post-receive
+------------
+
+This hook is invoked by `git-receive-pack` on the remote repository,
+which happens when a `git push` is done on a local repository.
+It executes on the remote repository once after all the refs have
+been updated.
+
+This hook executes once for the receive operation. It takes no
+arguments, but receives the same input as the
+<<pre-receive,'pre-receive'>> hook.
+
+This hook cannot affect the outcome of `git-receive-pack`, as it's
+called after the real work is done.
+
+This supersedes the <<post-update,'post-update'>> hook in that it
+get's both old and new values of all the refs in addition to their
+names.
+
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
-The default 'update' hook, when enabled, demonstrates how to
-send out a notification e-mail.
+The default 'post-receive' hook is empty, but there is
+a script `post-receive-email` provided in the `contrib/hooks`
+directory in git distribution, which implements sending commit
+emails.
+[[post-update]]
post-update
-----------
@@ -146,7 +211,10 @@ the outcome of `git-receive-pack`.
The 'post-update' hook can tell what are the heads that were pushed,
but it does not know what their original and updated values are,
-so it is a poor place to do log old..new.
+so it is a poor place to do log old..new. The
+<<post-receive,'post-receive'>> hook does get both original and
+updated values of the refs. You might consider it instead if you need
+them.
When enabled, the default 'post-update' hook runs
`git-update-server-info` to keep the information used by dumb
@@ -154,6 +222,6 @@ transports (e.g., HTTP) up-to-date. If you are publishing
a git repository that is accessible via HTTP, you should
probably enable this hook.
-The standard output of this hook is sent to `/dev/null`; if you
-want to report something to the `git-send-pack` on the other end,
-you can redirect your output to your `stderr`.
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
--
1.5.1.4
^ permalink raw reply related
* Re: [PATCH] Document subproject feature
From: Junio C Hamano @ 2007-05-12 20:42 UTC (permalink / raw)
To: Amos Waterland; +Cc: git
In-Reply-To: <20070512005844.GA24184@us.ibm.com>
apw@us.ibm.com (Amos Waterland) writes:
> Add a section to the user manual about the new subproject support.
> Show how to make a subproject.
>
> Signed-off-by: Amos Waterland <apw@us.ibm.com>
I like the idea of having new things described in the
user manual for the new release, but with a few reservations...
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 13db969..27d601f 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -1,4 +1,4 @@
> -Git User's Manual (for version 1.5.1 or newer)
> +Git User's Manual (for version 1.5.2 or newer)
> ______________________________________________
Another option is to leave this as is, and make a note on the
subproject and gitattributes section that they apply only to
1.5.2 or later. I am debating myself which one is better.
> +[[subprojects]]
> +Subprojects
> +-----------
> +
> +Some large development efforts, such as embedded Linux distributions,
> +are composed of a set of large projects, each with its own development
> +team, but all of which are combined to produce the project as a whole.
> +For example, there might be a firmware project, a hypervisor project,
> +a kernel project, and a userspace project. Note that while each
> +project is conceptually independent, there are many cases in which a
> +change to the hypervisor necessitates a change to the kernel, for
> +example.
>
> +In this case it is nice to be able to reason about the state of the
> +entire project, but also not inconvenience each development team with
> +checking out a gigantic repository that represents the entire project.
The above makes it sound as if the primary use case is to
artificially split a project that is otherwise a coherent whole,
only because split makes each piece smaller and more manageable
to handle. While that use case is also in scope, I do not think
that is the primary one. The above description sends a wrong
message, IMHO.
The intent of the current design of the subproject support is
more to keep track of 'subprojects' that are _not_ under your
control. For example, an embeddd Linux appliance developer does
not control the kernel project, nor glibc, nor busybox. He just
integrates the work by these other projects, which do not
particularly care during their own development about how _he_ is
fitting things together.
The developer however is in total control of how to fit these
pieces together, along with his own userspace, to build his
product. He uses the subproject feature to bind these external
projects into his own project, and freeze the HEAD version for
these subprojects to match the appliance's own needs ("we will
use this version of kernel together with that version of the
out-of-tree driver"). The "embedded distribution" example you
gave matches this use case better.
^ permalink raw reply
* Re: [StGIT PATCH v2] Document patch syntax.
From: Karl Hasselström @ 2007-05-12 20:43 UTC (permalink / raw)
To: Yann Dirson; +Cc: Catalin Marinas, git
In-Reply-To: <20070512185919.26101.3956.stgit@gandelf.nowhere.earth>
On 2007-05-12 20:59:30 +0200, Yann Dirson wrote:
> Acked-by: Karl Hasselstr?m <kha@treskal.com>
Your mail headers say
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
but the body contains
Acked-by: Karl Hasselstr=F6m <kha@treskal.com>
which is QP-encoded latin1, not utf8. (It's an illegal utf8 byte
sequence, which is why it showed up as a question mark in my MUA.)
> +Patches in the current stack are just refered to by their name. Some
s/refered/referred/. I missed this the first time -- sorry.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH 0/3] Fix assorted white space damage
From: Junio C Hamano @ 2007-05-12 20:45 UTC (permalink / raw)
To: Marco Costalba; +Cc: Git Mailing List
In-Reply-To: <e5bfff550705120409v629425aesc910927c26871323@mail.gmail.com>
Allow me to chuck these at this moment. Could you redo this as
the first thing after v1.5.2 final, please?
^ permalink raw reply
* suggestions for gitweb
From: Michael Niedermayer @ 2007-05-12 20:55 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2194 bytes --]
Hi
As we are switching from svn to git, we also have to switch from viewvc to
gitweb (or similar) and so ive thought id submit a short list of things
ive noticed in gitweb which i belive could be improved ...
* gitweb uses many terms which are new to a non git user, and while
devlopers who work on ffmpeg will very likely very quickly have
figured out the meaning of all of them. i think simple users who just
want to browse the ffmpeg code will have their problems, so i belive
a small help text linked to from all pages which contains a short
definition of all the git(web) specific terms would be very helpfull
something like
blob - file at a specific revission/date
tree - directory at a specific revission/date
(short) log - project wide commit log
history - short log equivalent for a file or directory
...
* The color of adjacent blame "hunks" is so similar that its
indistinguishable on my notebook TFT when iam looking at it from slightly
above
* The blame page shows the SHA1 for each hunk and IMHO thats the last thing
i would want to see first, id be much more interrested in by whom and
when a given change was done, iam wondering in which case the SHA1 would
be usefull? copy-paste onto your command line git tools but then why
use gitweb at all, 'git blame' would make more sense IMHO and a simple
click would reveal the sha1 with more info anyway ...
* i either cant find the long history for a file or there is none ("history"
is like "short log" and "log" is not file specific) a "long history" link
in addition to "history" would be nice
* on the history page there are "blob", "commitdiff" and "diff to current"
the obvious missing one is "diff to previous" which would be the diff to
the previous blob of this file
* the history/log pages could contain some statistics for the commits like
the number of files changed and lines added/removed
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] cvsserver: Complete rewrite of the configuration parser
From: Frank Lichtenheld @ 2007-05-12 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Martin Langhoff
In-Reply-To: <7v4pmhyfre.fsf@assigned-by-dhcp.cox.net>
On Sat, May 12, 2007 at 12:59:49PM -0700, Junio C Hamano wrote:
> But all of this is post 1.5.2 material; we would want to have a
> minimal fixup on 'master' before 1.5.2, independent of this
> rewrite.
Fair enough. So far I see three very minimal solutions, but I can't
decide which one is the least ugly:
(For all we can begin by limiting the used variables to
^gitcvs.((ext|pserver).)? )
1) Drop variables named gitcvs.ext and gitcvs.pserver manually
2) Use the complete variable name as key to the hash instead of
using a hash of hashes of hashes
{ "diff.color => "auto",
"diff.color.whitespace" => "blue reverse" }
3) Make the second level always a hash, instead of using a string
directly, so that Junio's example would look like this
{ diff => { color => { value => "auto",
whitespace => "blue reverse" } } }
Opinions?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* [PATCH] Make git compile with SUNs forte12 compiler
From: Thomas Glanzmann @ 2007-05-12 21:35 UTC (permalink / raw)
To: git; +Cc: Thomas Glanzmann
This patch moves two inline functions from a header file to the corresponding c
file. Otherwise forte12 refuses to compile git with the following error:
LINK git-convert-objects
ld: fatal: symbol `tree_entry_extract' is multiply-defined:
(file libgit.a(sha1_name.o) type=FUNC; file libgit.a(tree.o) type=FUNC);
ld: fatal: symbol `tree_entry_extract' is multiply-defined:
(file libgit.a(sha1_name.o) type=FUNC; file libgit.a(tree-walk.o) type=FUNC);
ld: fatal: File processing errors. No output written to git-convert-objects
gmake[1]: *** [git-convert-objects] Error 1
Signed-off-by: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
---
tree-walk.c | 14 ++++++++++++++
tree-walk.h | 13 +------------
2 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/tree-walk.c b/tree-walk.c
index cbb24eb..ef57951 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -2,6 +2,20 @@
#include "tree-walk.h"
#include "tree.h"
+inline int tree_entry_len(const char *name, const unsigned char *sha1)
+{
+ return (char *)sha1 - (char *)name - 1;
+}
+
+inline const unsigned char *tree_entry_extract(struct tree_desc *desc,
+ const char **pathp, unsigned int *modep)
+{
+ *pathp = desc->entry.path;
+ *modep = canon_mode(desc->entry.mode);
+ return desc->entry.sha1;
+}
+
+
static const char *get_mode(const char *str, unsigned int *modep)
{
unsigned char c;
diff --git a/tree-walk.h b/tree-walk.h
index 43458cf..984f19e 100644
--- a/tree-walk.h
+++ b/tree-walk.h
@@ -13,21 +13,10 @@ struct tree_desc {
unsigned int size;
};
-static inline const unsigned char *tree_entry_extract(struct tree_desc *desc, const char **pathp, unsigned int *modep)
-{
- *pathp = desc->entry.path;
- *modep = canon_mode(desc->entry.mode);
- return desc->entry.sha1;
-}
-
-static inline int tree_entry_len(const char *name, const unsigned char *sha1)
-{
- return (char *)sha1 - (char *)name - 1;
-}
-
void update_tree_entry(struct tree_desc *);
void init_tree_desc(struct tree_desc *desc, const void *buf, unsigned long size);
const unsigned char *tree_entry_extract(struct tree_desc *, const char **, unsigned int *);
+int tree_entry_len(const char *name, const unsigned char *sha1);
/* Helper function that does both of the above and returns true for success */
int tree_entry(struct tree_desc *, struct name_entry *);
--
1.5.1.3
^ permalink raw reply related
* Re: Possible bug in git-svn
From: Eric Wong @ 2007-05-12 21:40 UTC (permalink / raw)
To: Martin Eisenhardt; +Cc: Adam Roben, Git Mailing List
In-Reply-To: <200705121824.14190.list-receive@mneisen.org>
Martin Eisenhardt <list-receive@mneisen.org> wrote:
> Hello Eric,
> hello list,
>
> I came across what might just possibly be a bug in git-svn. My apologies if
> this was already handled somewhere on the list but I was not able to find
> this exact problem mentioned before.
>
> Let's say I run a SVN repository at svn+ssh://svn@example.com/repos and have
> it set up as described at
>
> http://svnbook.red-bean.com/nightly/en/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks
>
> In essence, there is only one user "svn" with access to the repository, and
> every developer has his/her public key in ~svn/.ssh/authorized_keys with a
> line like
>
> command="svnserve -t --tunnel-user=harry -r /svn/" TYPE1 KEY1
> harry@example.com
>
> This is desirable to limit the developers access to the repository; no shell,
> access restricted to svn's home directory.
>
> Now let's assume that within this repository, there are several projects, so
> we have f.e. the following structure:
>
> +-proj1-+-trunk
> | +-branches
> | +-tags
> |
> +-proj2-+-trunk
> | +-branches
> | +-tags
> +-[more projects]
>
> I have no problem setting up a local .git tracking such a project using
>
> $ git-svn init svn+ssh://svn@example.com/repos/proj1/trunk
> $ git-svn fetch
>
> After having made local changes and commited them to git, I want to push them
> to the remote subversion repository:
>
> $ # do some work
> $ git-commit -a
> $ git-svn dcommit
>
> The last command gives me (invariably):
>
> Couldn't find a repository: No repository found
> in 'svn+ssh://example.com/repos/proj1/trunk' at at /home/mneisen/bin/git-svn
> line 403
>
> What is odd is that git-svn uses the URL-prefix svn+ssh://example.com/[...]
> instead of the correct svn+ssh://svn@example.com/[...], i.e., git-svn drops
> the user name.
>
> This behavior is surprisingly inconsistent as git-svn uses the correct user
> name while fetching and stores it correctly in .git/config.
Ouch. This is laziness on my part exposed by a patch Adam made to
cleanup the git-svn-id lines. dcommit reads the git-svn-id: line in the
last SVN commit instead of .git/config.
> The server log contains the following lines:
>
> May 12 18:18:50 [sshd] Accepted keyboard-interactive/pam for mneisen from
> 217.229.32.249 port 37685 ssh2
> May 12 18:18:50 [sshd(pam_unix)] session opened for user mneisen by (uid=0)
> May 12 18:18:51 [sshd(pam_unix)] session closed for user mneisen
>
> which supports my suspicion that git-svn drops the user name for dcommit and
> uses the current account name instead.
>
> A git repository on the same machine as the subversion repository is able to
> track the SVN repository, so it seems that my problems are directly related
> to the combination of git-svn and the svn+ssh transport of subversion.
>
> If this an error on my part, please advise me how to solve it.
Thanks for the bug report. I haven't tested the patch below, so
let me know if it works:
>From 58af622c222514dc3da938ce6309e1ac927a9574 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sat, 12 May 2007 14:36:20 -0700
Subject: [PATCH] git-svn: don't drop the username from URLs when dcommit is run
We no longer store usernames in URLs stored in git-svn-id lines
for dcommit, so we shouldn't rely on those URLs when connecting
to the remote repository to commit.
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 3c4f490..d74e6d3 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -393,7 +393,7 @@ sub cmd_dcommit {
} else {
my %ed_opts = ( r => $last_rev,
log => get_commit_entry($d)->{log},
- ra => Git::SVN::Ra->new($url),
+ ra => Git::SVN::Ra->new($gs->full_url),
tree_a => "$d~1",
tree_b => $d,
editor_cb => sub {
--
Eric Wong
^ permalink raw reply related
* Re: [RFC] format-patch stuff
From: Frank Lichtenheld @ 2007-05-12 21:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Daniel Barkalow, git
In-Reply-To: <7vy7jtx01y.fsf@assigned-by-dhcp.cox.net>
On Sat, May 12, 2007 at 01:24:25PM -0700, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > It would be nice if git-format-patch would generate a [PATCH 0/n] message
> > at the start of the series if some option were given. This would, of
> > course, have to be editted afterwards to include actual information, but
> > it would at least be pre-generated in series and with the configured
> > headers and such.
>
> It would be helpful for git-send-email users. I've done that by
> hand by copying 0001-*.txt to 0000-*.txt and editing as needed
> by hand.
But git-send-email users can already use --compose which serves
exactly this use case, doesn't it?
I would have thought such an option would be useful exactly for
git-send-email non-users ;)
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* [PATCH] Minor fixup to documentation of hooks in git-receive-pack.
From: Jan Hudec @ 2007-05-12 21:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd515wyue.fsf@assigned-by-dhcp.cox.net>
Small additional changes to the cbb84e5d174cf33fd4dcf3136de50a886ff9a2e2
commit, which introduced documentation to pre-receive and post-receive:
- Mention that stdout and stderr are equivalent.
- Add one cross-section link and fix one other.
- Fix information on advantages of post-receive over post-update.
Signed-off-by: Jan Hudec <bulb@ucw.cz>
---
Ok, here are incremental corrections:
- IMHO mentioning that stdout and stderr are equal is useful, because when
writing the script you often redirect stdout and than need stderr for the
messages.
- There was an error in one of the links (used [[]] instead of <<>>)
- The paragraph in post-update was incorrect -- post-update is actually
called just once with all refs as arguments, it just does not get the
values (which it could get from reflog, if it's turned on, but it does not
have to be).
Regards,
Jan
Documentation/hooks.txt | 37 ++++++++++++++++++++-----------------
1 files changed, 20 insertions(+), 17 deletions(-)
diff --git a/Documentation/hooks.txt b/Documentation/hooks.txt
index 80ba670..aabb975 100644
--- a/Documentation/hooks.txt
+++ b/Documentation/hooks.txt
@@ -115,8 +115,9 @@ If the hook exits with non-zero status, none of the refs will be
updated. If the hook exits with zero, updating of individual refs can
still be prevented by the <<update,'update'>> hook.
-If you want to report something to the `git-send-pack` on the other end,
-you can simply `echo` your messages.
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
[[update]]
update
@@ -153,9 +154,9 @@ Another use suggested on the mailing list is to use this hook to
implement access control which is finer grained than the one
based on filesystem group.
-The standard output of this hook is sent to `stderr`, so if you
-want to report something to the `git-send-pack` on the other end,
-you can simply `echo` your messages.
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
The default 'update' hook, when enabled--and with
`hooks.allowunannotated` config option turned on--prevents
@@ -171,17 +172,20 @@ It executes on the remote repository once after all the refs have
been updated.
This hook executes once for the receive operation. It takes no
-arguments, but gets the same information as the `pre-receive`
+arguments, but gets the same information as the
+<<pre-receive,'pre-receive'>>
hook does on its standard input.
This hook does not affect the outcome of `git-receive-pack`, as it
is called after the real work is done.
-This supersedes the [[post-update]] hook in that it actually get's
-both old and new values of all the refs.
+This supersedes the <<post-update,'post-update'>> hook in that it get's
+both old and new values of all the refs in addition to their
+names.
-If you want to report something to the `git-send-pack` on the
-other end, you can simply `echo` your messages.
+Both standard output and standard error output are forwarded to
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
The default 'post-receive' hook is empty, but there is
a sample script `post-receive-email` provided in the `contrib/hooks`
@@ -205,12 +209,10 @@ the outcome of `git-receive-pack`.
The 'post-update' hook can tell what are the heads that were pushed,
but it does not know what their original and updated values are,
-so it is a poor place to do log old..new.
-
-In general, `post-receive` hook is preferred when the hook needs
-to decide its acion on the status of the entire set of refs
-being updated, as this hook is called once per ref, with
-information only on a single ref at a time.
+so it is a poor place to do log old..new. The
+<<post-receive,'post-receive'>> hook does get both original and
+updated values of the refs. You might consider it instead if you need
+them.
When enabled, the default 'post-update' hook runs
`git-update-server-info` to keep the information used by dumb
@@ -219,4 +221,5 @@ a git repository that is accessible via HTTP, you should
probably enable this hook.
Both standard output and standard error output are forwarded to
-`git-send-pack` on the other end.
+`git-send-pack` on the other end, so you can simply `echo` messages
+for the user.
--
1.5.1.4
^ permalink raw reply related
* Re: suggestions for gitweb
From: Junio C Hamano @ 2007-05-12 22:39 UTC (permalink / raw)
To: Michael Niedermayer; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <20070512205529.GS14859@MichaelsNB>
Michael Niedermayer <michaelni@gmx.at> writes:
> * gitweb uses many terms which are new to a non git user, and while
> devlopers who work on ffmpeg will very likely very quickly have
> figured out the meaning of all of them. i think simple users who just
> want to browse the ffmpeg code will have their problems, so i belive
> a small help text linked to from all pages which contains a short
> definition of all the git(web) specific terms would be very helpfull
> something like
> blob - file at a specific revission/date
> tree - directory at a specific revission/date
> (short) log - project wide commit log
> history - short log equivalent for a file or directory
Coming fron non-CVS camp, I think changing this to non-git terms
is very harmful than educating users who are migrating from
other systems.
> * The color of adjacent blame "hunks" is so similar that its
> indistinguishable on my notebook TFT when iam looking at it from slightly
> above
This is more or less intentional to make the difference not too
distracting. I thought it was controlled via css which
something you can use browser side tricks to suite your taste?
> * The blame page shows the SHA1 for each hunk and IMHO thats the last thing
> i would want to see first, id be much more interrested in by whom and
> when a given change was done, iam wondering in which case the SHA1 would
> be usefull? copy-paste onto your command line git tools but then why
> use gitweb at all, 'git blame' would make more sense IMHO and a simple
> click would reveal the sha1 with more info anyway ...
They serve no purpose other than showing something to click on,
and allow you to hover over (some people argued in the past
that they recognize certain commit object names, but honestly I
would not believe them). However, I do not think there are much
better alternatives. Try coming up with a different "label"
string that is of uniform length across commits, and does not
chew up too much screen real estate.
> * i either cant find the long history for a file or there is none ("history"
> is like "short log" and "log" is not file specific) a "long history" link
> in addition to "history" would be nice
Probably.
> * on the history page there are "blob", "commitdiff" and "diff to current"
> the obvious missing one is "diff to previous" which would be the diff to
> the previous blob of this file
Isn't that commitdiff, or commitdiff on that page does not limit
the diff to the blob?
> * the history/log pages could contain some statistics for the commits like
> the number of files changed and lines added/removed
Probably.
The three last items should be relatively easy, if somebody is
interested. Pasky, Jakub, what do you think?
^ permalink raw reply
* Re: [PATCH] cvsserver: Complete rewrite of the configuration parser
From: Junio C Hamano @ 2007-05-12 22:43 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: git, Martin Langhoff
In-Reply-To: <20070512213153.GC7184@planck.djpig.de>
Frank Lichtenheld <frank@lichtenheld.de> writes:
> On Sat, May 12, 2007 at 12:59:49PM -0700, Junio C Hamano wrote:
>> But all of this is post 1.5.2 material; we would want to have a
>> minimal fixup on 'master' before 1.5.2, independent of this
>> rewrite.
>
> Fair enough. So far I see three very minimal solutions, but I can't
> decide which one is the least ugly:
>
> (For all we can begin by limiting the used variables to
> ^gitcvs.((ext|pserver).)? )
That sounds sensible. And ignore anything that do not match.
> 1) Drop variables named gitcvs.ext and gitcvs.pserver manually
I do not see any need for this; gitcvs.ext or gitcvs.pserver as
variables do not exist, at least right now. The breakage was
purely that the old parser tried to parse things it does not
even know about (e.g. diff.color) without knowing the rules
there.
> 2) Use the complete variable name as key to the hash instead of
> using a hash of hashes of hashes
> { "diff.color => "auto",
> "diff.color.whitespace" => "blue reverse" }
No need for this nor the next one either. You understand only
gitcvs.<option> or gitcvs.<method>.<option>, and you know there
is no string that is common in <option> and <method>
> 3) Make the second level always a hash, instead of using a string
> directly, so that Junio's example would look like this
> { diff => { color => { value => "auto",
> whitespace => "blue reverse" } } }
>
>
> Opinions?
^ 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