* [PATCH 2/5] bash: removed unnecessary checks for long options with argument
From: SZEDER Gábor @ 2009-01-16 16:01 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
__gitcomp takes care of it since 5447aac7 (bash: fix long option with
argument double completion, 2008-03-05)
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 4292b23..c35f86d 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -643,7 +643,6 @@ _git_branch ()
done
case "${COMP_WORDS[COMP_CWORD]}" in
- --*=*) COMPREPLY=() ;;
--*)
__gitcomp "
--color --no-color --verbose --abbrev= --no-abbrev
@@ -1692,7 +1691,6 @@ _git ()
if [ -z "$command" ]; then
case "${COMP_WORDS[COMP_CWORD]}" in
- --*=*) COMPREPLY=() ;;
--*) __gitcomp "
--paginate
--no-pager
--
1.6.1.198.geb475f
^ permalink raw reply related
* [PATCH 3/5] bash: add missing format-patch command line options
From: SZEDER Gábor @ 2009-01-16 16:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index c35f86d..fc16aaa 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -838,6 +838,8 @@ _git_format_patch ()
--not --all
--cover-letter
--no-prefix --src-prefix= --dst-prefix=
+ --inline --suffix= --ignore-if-in-upstream
+ --subject-prefix=
"
return
;;
--
1.6.1.198.geb475f
^ permalink raw reply related
* [PATCH 5/5] bash: refactor 'git log --pretty=<format>' options
From: SZEDER Gábor @ 2009-01-16 16:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, SZEDER Gábor
Both 'git log' and 'show' have the same '--pretty=<format>' option
with the same formats. So refactor these formats into a common
variable.
While at it, also add 'format:' to the list.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 3a26d2b..b5b40c2 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -947,6 +947,8 @@ _git_ls_tree ()
__git_complete_file
}
+__git_log_pretty_formats="oneline short medium full fuller email raw format:"
+
_git_log ()
{
__git_has_doubledash && return
@@ -954,8 +956,7 @@ _git_log ()
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--pretty=*)
- __gitcomp "
- oneline short medium full fuller email raw
+ __gitcomp "$__git_log_pretty_formats
" "" "${cur##--pretty=}"
return
;;
@@ -1487,8 +1488,7 @@ _git_show ()
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--pretty=*)
- __gitcomp "
- oneline short medium full fuller email raw
+ __gitcomp "$__git_log_pretty_formats
" "" "${cur##--pretty=}"
return
;;
--
1.6.1.198.geb475f
^ permalink raw reply related
* Re: [PATCH 2/5] bash: removed unnecessary checks for long options with argument
From: SZEDER Gábor @ 2009-01-16 16:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1232121717-10145-1-git-send-email-szeder@ira.uka.de>
Oh, I have run 'git format-patch master.. && rm
patches-i-dont-want-to-submit-yet' and haven't noticed that
'format-patch' autonumbered the patches. So, there are only three
patches: 2, 3, 5.
Gábor
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Boyd Stephen Smith Jr. @ 2009-01-16 16:11 UTC (permalink / raw)
To: Santi Béjar
Cc: Johannes Schindelin, Junio C Hamano, Teemu Likonen, Thomas Rast,
git
In-Reply-To: <adf1fd3d0901160102y32a08e26q96728495fc0b6fcf@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1058 bytes --]
On Friday 2009 January 16 03:02:33 Santi Béjar wrote:
> 2009/1/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> Hi,
>>
>> On Fri, 16 Jan 2009, Santi Béjar wrote:
>>> If everything works as I think (it's late night :-) with the above two
>>> lines:
>>>
>>> matrix[a,b,c]
>>> matrix{d,b,c}
>>>
>>> the word diff would be
>>>
>>> matrix<RED>[<GREEN>{<RED>a<GREEN>d<RESET>,b,c<RED>]<GREEN>}<RED>
>
>So, I see, it is a matter of finding the right regexp.
>
>But the only use case for me is of this kind, and I think for the
>others too. So maybe an easier way to specify it could be worth. But
>I'll write an alias as this is the only regexp I would use, apart from
>the default word diff.
I think that the C/C++ language word-diff driver would work here, and there
should be a shortcut for that.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] git-am: Make it easier to see which patch failed
From: Johannes Schindelin @ 2009-01-16 16:27 UTC (permalink / raw)
To: Jonas Flodén; +Cc: git
In-Reply-To: <636ecac0901160634r586c72a0r9bb63c6f019f5bff@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 341 bytes --]
Hi,
On Fri, 16 Jan 2009, Jonas Flodén wrote:
> Johannes Schindelin wrote:
> > Maybe
> >
> > - echo Patch failed at $msgnum.
> > + echo Patch failed at $msgnum($FIRSTLINE).
>
> How about this instead. Though the line could get very long.
> This makes the line stand out a little more.
Fine by me!
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Fix gitdir detection when in subdir of gitdir
From: Johannes Schindelin @ 2009-01-16 16:29 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: git
In-Reply-To: <1232120253-1551-1-git-send-email-szeder@ira.uka.de>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 524 bytes --]
Hi,
On Fri, 16 Jan 2009, SZEDER Gábor wrote:
> I'm not sure about setting an absolut path instead of a relative one
> (hence the RFC), although I think it should not make any difference.
> Of course I could have count the number of chdir("..") calls and then
> construct a "../../..", but that would have been more intrusive than
> this two-liner.
IIRC the absolute paths were shot down already... for performance reasons.
So we try very hard to keep relative paths instead of absolute ones.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Fix gitdir detection when in subdir of gitdir
From: Johannes Sixt @ 2009-01-16 16:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: SZEDER Gábor, git
In-Reply-To: <alpine.DEB.1.00.0901161729070.3586@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
> Hi,
>
> On Fri, 16 Jan 2009, SZEDER Gábor wrote:
>
>> I'm not sure about setting an absolut path instead of a relative one
>> (hence the RFC), although I think it should not make any difference.
>> Of course I could have count the number of chdir("..") calls and then
>> construct a "../../..", but that would have been more intrusive than
>> this two-liner.
>
> IIRC the absolute paths were shot down already... for performance reasons.
>
> So we try very hard to keep relative paths instead of absolute ones.
This is a different matter.
The question is basically: How should git behave if $PWD is inside a bare
repository? And if you are inside .git/refs, than for git this looks as if
it were a bare repository.
The current behavior is that we chdir() up into .git, but do not set a
prefix. Nor do we chdir() back where we started after the discovery.
Gábor's patch needs a better justification which misbehavior it tries to
fix, and the spot that it changes:
if (is_git_directory(".")) {
inside_git_dir = 1;
if (!work_tree_env)
inside_work_tree = 0;
setenv(GIT_DIR_ENVIRONMENT, ".", 1);
check_repository_format_gently(nongit_ok);
return NULL;
}
needs a comment why it does what it does (and that this if-branch is only
about bare repositories).
-- Hannes
^ permalink raw reply
* Confusing text in git-prune.txt
From: Adeodato Simó @ 2009-01-16 16:50 UTC (permalink / raw)
To: git
From git-prune.txt:
[...] prunes all unpacked objects unreachable from any of
these head objects from the object database. In addition,
it prunes the unpacked objects that are also found in packs by
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
running git-prune-packed.
How can "unpacked objects" be "found in packs"? Maybe the first
"unpacked" should be "unreachable". But if that's the case, wouldn't
this be better:
[...] prunes from the object database all objects unreachable from
any of these heads. Prunning already-packed objects is done with
the help of git-prune-packed.
Thoughts? Or am I reading the original text wrong?
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
I promise you. Once I enter into an exclusive relationship, I sleep with
very few people.
-- Denny Crane
^ permalink raw reply
* Re: [RFC PATCH] Fix gitdir detection when in subdir of gitdir
From: Johannes Sixt @ 2009-01-16 16:50 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: SZEDER Gábor, git
In-Reply-To: <4970BA2B.7090807@viscovery.net>
Johannes Sixt schrieb:
> Gábor's patch needs a better justification which misbehavior it tries to
> fix, and the spot that it changes:
I actually meant: "which use-case the patch tries to help". Because the
current behavior can hardly be classified as bug. ("You have no business
cd-ing around in .git." ;)
-- Hannes
^ permalink raw reply
* Re: Confusing text in git-prune.txt
From: Johannes Sixt @ 2009-01-16 16:56 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git
In-Reply-To: <20090116165013.GA14196@chistera.yi.org>
Adeodato Simó schrieb:
> From git-prune.txt:
>
> [...] prunes all unpacked objects unreachable from any of
> these head objects from the object database. In addition,
> it prunes the unpacked objects that are also found in packs by
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> running git-prune-packed.
>
> How can "unpacked objects" be "found in packs"?
An object can exist more than once in the database. prune-packed removes
the loose (unpacked) instance of the object if it also available in a pack.
-- Hannes
^ permalink raw reply
* Re: Confusing text in git-prune.txt
From: Adeodato Simó @ 2009-01-16 17:02 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4970BC25.7020007@viscovery.net>
* Johannes Sixt [Fri, 16 Jan 2009 17:56:05 +0100]:
> Adeodato Simó schrieb:
> > From git-prune.txt:
> > [...] prunes all unpacked objects unreachable from any of
> > these head objects from the object database. In addition,
> > it prunes the unpacked objects that are also found in packs by
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > running git-prune-packed.
> > How can "unpacked objects" be "found in packs"?
> An object can exist more than once in the database. prune-packed removes
> the loose (unpacked) instance of the object if it also available in a pack.
Ah, thanks, that explains everything.
I read the manpage for git-prune-unpacked, but I didn't manage to figure
it out. It may have helped if instead of saying:
git-prune-packed - Remove extra objects that are already in pack files
it would have said:
git-prune-packed - Remove loose objects that are already in pack files
^^^^^
By stating that those objects are "extra", we're losing the information
of where are they. And by reading that synopsis, one can already infer
they are "extra".
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Radiohead - Bodysnatchers
^ permalink raw reply
* Re: [PATCH 5/5] bash: refactor 'git log --pretty=<format>' options
From: Shawn O. Pearce @ 2009-01-16 17:18 UTC (permalink / raw)
To: SZEDER Gábor, Junio C Hamano; +Cc: git
In-Reply-To: <1232121735-10239-1-git-send-email-szeder@ira.uka.de>
SZEDER Gábor <szeder@ira.uka.de> wrote:
> Both 'git log' and 'show' have the same '--pretty=<format>' option
> with the same formats. So refactor these formats into a common
> variable.
>
> While at it, also add 'format:' to the list.
>
> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
For all 3 patches in the series:
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Thanks.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH] Fix gitdir detection when in subdir of gitdir
From: SZEDER Gábor @ 2009-01-16 17:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git
In-Reply-To: <4970BAE5.8080006@viscovery.net>
On Fri, Jan 16, 2009 at 05:50:45PM +0100, Johannes Sixt wrote:
> Johannes Sixt schrieb:
> > Gábor's patch needs a better justification which misbehavior it tries to
> > fix, and the spot that it changes:
>
> I actually meant: "which use-case the patch tries to help". Because the
> current behavior can hardly be classified as bug. ("You have no business
> cd-ing around in .git." ;)
I agree that fiddling around in '.git' is a quite rare use case.
I did it while I was working on bash completion support for the
upcoming 'git sequencer' to see where it stores its temporary files
and what is in those files. And I got errors from the completion
script after each executed command, which quickly made me upset enough
to look after it.
I thought it worths fixing, but it's even better if it's not a bug,
because then I don't have to fix my fix (;
Regards,
Gábor
^ permalink raw reply
* Re: [PATCH 1/2] Move run_hook() from builtin-commit.c into run-command.c (libgit)
From: Stephan Beyer @ 2009-01-16 17:25 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Paolo Bonzini, Miklos Vajna, Shawn O. Pearce,
Daniel Barkalow, Christian Couder, gitster
In-Reply-To: <alpine.DEB.1.00.0901151637590.3586@pacific.mpi-cbg.de>
Hi,
> > - ret = start_command(&hook);
> > - if (ret) {
> > - warning("Could not spawn %s", argv[0]);
> > - return ret;
> > - }
> > - ret = finish_command(&hook);
> > - if (ret == -ERR_RUN_COMMAND_WAITPID_SIGNAL)
> > - warning("%s exited due to uncaught signal", argv[0]);
>
> What are the side effects of replacing this with "ret =
> run_command(&hook);"? This has to be discussed and defended in the commit
> message.
This is a very good point.
The consequences are that two warnings are missing, but these are
warnings that are useful enough to be included for all those hooks,
imho.
Thanks!
> Lots of improvements possible (I agree; _after_ this patch):
[...]
> - use ALLOC_GROW instead of having a fixed size argv,
Agreed.
> - use an strbuf for the index file
Is that useful in some way?
Currently it would only adds code to generate strbufs at the caller
side. And in the case the caller has a strbuf for the index file, it
can simply use the .buf member.
> - checking executability of argv[0] before filling argv,
Agreed.
Patch series v2 will follow.
Thanks,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Stephan Beyer @ 2009-01-16 17:26 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Johan Herland, git, Jay Soffian, Wincent Colaiuta,
Johannes Schindelin, Junio C Hamano, Johannes Sixt,
Anders Melchiorsen
In-Reply-To: <bd6139dc0901160512x284bcd00x5d4c088e1771d86e@mail.gmail.com>
Hi,
Sverre Rabbelier wrote:
> On Fri, Jan 16, 2009 at 10:50, Johan Herland <johan@herland.net> wrote:
> > we should consider something like
> > pick e8902c1 Foo
> > halt
>
> I very much like this suggestion, Stephan, is this somewhat similar to
> how git sequencer will do things?
Yes, it is
pick e8902c1 # Foo
pause
in sequencer currently. Of course, "pause" could be renamed to "halt",
"stop" or whatever you like. But I think everyone likes something
different.
And
edit e8902c1 # Foo
is simply a shortcut for the pick-pause above.
(Or "e e8902c1" instead of edit, which works, too.)
I usually prefer typing "cw edit<ESC>" over "o pause<ESC>" into vim
in such cases.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [RFC PATCH] Fix gitdir detection when in subdir of gitdir
From: Junio C Hamano @ 2009-01-16 18:07 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, SZEDER Gábor, git
In-Reply-To: <4970BAE5.8080006@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Johannes Sixt schrieb:
>> Gábor's patch needs a better justification which misbehavior it tries to
>> fix, and the spot that it changes:
>
> I actually meant: "which use-case the patch tries to help". Because the
> current behavior can hardly be classified as bug. ("You have no business
> cd-ing around in .git." ;)
Thanks.
I think (1) the solution (almost) makes sense, (2) the patch needs to be
explained a lot better as you mentioned in your two messages, and (3) if
it does not affect any other case than when you are in a subdirectory of
the .git/ directory, then you are doing something funny anyway and
performance issue Dscho mentions, if any, is not a concern.
My "(almost)" in (1) above is because the patch uses this new behaviour
even when you are inside the .git/ directory itself (or at the root of a
bare repository), which is a very common case that we do not have to nor
want to change the behaviour. It also invalidates the precondition of (3)
above.
Dscho, what performance issues do you have in mind, by the way?
^ permalink raw reply
* Re: [PATCH take 3 0/4] color-words improvements
From: Thomas Rast @ 2009-01-16 19:04 UTC (permalink / raw)
To: Santi Béjar
Cc: Johannes Schindelin, Junio C Hamano, Boyd Stephen Smith Jr.,
Teemu Likonen, git
In-Reply-To: <adf1fd3d0901160401s7a363076x1bcd8e90db4f56a1@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 630 bytes --]
Santi Béjar wrote:
> Hi,
>
> can you both provide a public repository to be able to test the
> lastest version without having to search and apply them?
I set up a clone at
git://repo.or.cz/git/trast.git
The respective topics are js/word-diff-p1 and tr/word-diff-p2. For
your testing convenience, there are master/next branches that merge
tr/word-diff-p2 to Junio's master/next. I *think* I should have
gathered all squashes from Dscho, too.
The tip commit has some tweaks to the builtin regexes that aren't in
any mailed version yet; I'll resend RSN.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH v2 2/5] Move run_hook() from builtin-commit.c into run-command.c (libgit)
From: Stephan Beyer @ 2009-01-16 19:09 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Paolo Bonzini, Miklos Vajna, Shawn O. Pearce,
Daniel Barkalow, Christian Couder, gitster, Stephan Beyer
In-Reply-To: <1232133002-21725-1-git-send-email-s-beyer@gmx.net>
A function that runs a hook is used in several Git commands.
builtin-commit.c has the one that is most general for cases without
piping. The one in builtin-gc.c prints some useful warnings.
This patch moves a merged version of these variants into libgit and
lets the other builtins use this libified run_hook().
The run_hook() function used in receive-pack.c feeds the standard
input of the pre-receive or post-receive hooks. This function is
renamed to run_receive_hook() because the libified run_hook() cannot
handle this.
Mentored-by: Daniel Barkalow <barkalow@iabervon.org>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
A quick comparison to v1:
- builtin-checkout.c/post_checkout_hook() makes use of
run_hook() now.
- The lost warnings Dscho pointed at are in the libified
run_hook() now.
builtin-checkout.c | 22 +++++-----------------
builtin-commit.c | 34 ----------------------------------
builtin-gc.c | 30 +-----------------------------
builtin-merge.c | 31 +------------------------------
builtin-receive-pack.c | 6 +++---
run-command.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
run-command.h | 2 ++
7 files changed, 57 insertions(+), 113 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 149343e..275176d 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -38,25 +38,13 @@ struct checkout_opts {
static int post_checkout_hook(struct commit *old, struct commit *new,
int changed)
{
- struct child_process proc;
- const char *name = git_path("hooks/post-checkout");
- const char *argv[5];
-
- if (access(name, X_OK) < 0)
- return 0;
-
- memset(&proc, 0, sizeof(proc));
- argv[0] = name;
- argv[1] = sha1_to_hex(old ? old->object.sha1 : null_sha1);
- argv[2] = sha1_to_hex(new ? new->object.sha1 : null_sha1);
+ return run_hook(NULL, "post-checkout",
+ sha1_to_hex(old ? old->object.sha1 : null_sha1),
+ sha1_to_hex(new ? new->object.sha1 : null_sha1),
+ changed ? "1" : "0", NULL);
/* "new" can be NULL when checking out from the index before
a commit exists. */
- argv[3] = changed ? "1" : "0";
- argv[4] = NULL;
- proc.argv = argv;
- proc.no_stdin = 1;
- proc.stdout_to_stderr = 1;
- return run_command(&proc);
+
}
static int update_some(const unsigned char *sha1, const char *base, int baselen,
diff --git a/builtin-commit.c b/builtin-commit.c
index e88b78f..6f8d9fb 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -361,40 +361,6 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int
return s.commitable;
}
-static int run_hook(const char *index_file, const char *name, ...)
-{
- struct child_process hook;
- const char *argv[10], *env[2];
- char index[PATH_MAX];
- va_list args;
- int i;
-
- va_start(args, name);
- argv[0] = git_path("hooks/%s", name);
- i = 0;
- do {
- if (++i >= ARRAY_SIZE(argv))
- die ("run_hook(): too many arguments");
- argv[i] = va_arg(args, const char *);
- } while (argv[i]);
- va_end(args);
-
- snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", index_file);
- env[0] = index;
- env[1] = NULL;
-
- if (access(argv[0], X_OK) < 0)
- return 0;
-
- memset(&hook, 0, sizeof(hook));
- hook.argv = argv;
- hook.no_stdin = 1;
- hook.stdout_to_stderr = 1;
- hook.env = env;
-
- return run_command(&hook);
-}
-
static int is_a_merge(const unsigned char *sha1)
{
struct commit *commit = lookup_commit(sha1);
diff --git a/builtin-gc.c b/builtin-gc.c
index f8eae4a..a201438 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -144,34 +144,6 @@ static int too_many_packs(void)
return gc_auto_pack_limit <= cnt;
}
-static int run_hook(void)
-{
- const char *argv[2];
- struct child_process hook;
- int ret;
-
- argv[0] = git_path("hooks/pre-auto-gc");
- argv[1] = NULL;
-
- if (access(argv[0], X_OK) < 0)
- return 0;
-
- memset(&hook, 0, sizeof(hook));
- hook.argv = argv;
- hook.no_stdin = 1;
- hook.stdout_to_stderr = 1;
-
- ret = start_command(&hook);
- if (ret) {
- warning("Could not spawn %s", argv[0]);
- return ret;
- }
- ret = finish_command(&hook);
- if (ret == -ERR_RUN_COMMAND_WAITPID_SIGNAL)
- warning("%s exited due to uncaught signal", argv[0]);
- return ret;
-}
-
static int need_to_gc(void)
{
/*
@@ -194,7 +166,7 @@ static int need_to_gc(void)
else if (!too_many_loose_objects())
return 0;
- if (run_hook())
+ if (run_hook(NULL, "pre-auto-gc", NULL))
return 0;
return 1;
}
diff --git a/builtin-merge.c b/builtin-merge.c
index cf86975..e4555b0 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -300,35 +300,6 @@ static void squash_message(void)
strbuf_release(&out);
}
-static int run_hook(const char *name)
-{
- struct child_process hook;
- const char *argv[3], *env[2];
- char index[PATH_MAX];
-
- argv[0] = git_path("hooks/%s", name);
- if (access(argv[0], X_OK) < 0)
- return 0;
-
- snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", get_index_file());
- env[0] = index;
- env[1] = NULL;
-
- if (squash)
- argv[1] = "1";
- else
- argv[1] = "0";
- argv[2] = NULL;
-
- memset(&hook, 0, sizeof(hook));
- hook.argv = argv;
- hook.no_stdin = 1;
- hook.stdout_to_stderr = 1;
- hook.env = env;
-
- return run_command(&hook);
-}
-
static void finish(const unsigned char *new_head, const char *msg)
{
struct strbuf reflog_message = STRBUF_INIT;
@@ -374,7 +345,7 @@ static void finish(const unsigned char *new_head, const char *msg)
}
/* Run a post-merge hook */
- run_hook("post-merge");
+ run_hook(NULL, "post-merge", squash ? "1" : "0", NULL);
strbuf_release(&reflog_message);
}
diff --git a/builtin-receive-pack.c b/builtin-receive-pack.c
index db67c31..6564a97 100644
--- a/builtin-receive-pack.c
+++ b/builtin-receive-pack.c
@@ -136,7 +136,7 @@ static int hook_status(int code, const char *hook_name)
}
}
-static int run_hook(const char *hook_name)
+static int run_receive_hook(const char *hook_name)
{
static char buf[sizeof(commands->old_sha1) * 2 + PATH_MAX + 4];
struct command *cmd;
@@ -358,7 +358,7 @@ static void execute_commands(const char *unpacker_error)
return;
}
- if (run_hook(pre_receive_hook)) {
+ if (run_receive_hook(pre_receive_hook)) {
while (cmd) {
cmd->error_string = "pre-receive hook declined";
cmd = cmd->next;
@@ -627,7 +627,7 @@ int cmd_receive_pack(int argc, const char **argv, const char *prefix)
unlink(pack_lockfile);
if (report_status)
report(unpack_status);
- run_hook(post_receive_hook);
+ run_receive_hook(post_receive_hook);
run_update_post_hook(commands);
}
return 0;
diff --git a/run-command.c b/run-command.c
index c90cdc5..49810a8 100644
--- a/run-command.c
+++ b/run-command.c
@@ -342,3 +342,48 @@ int finish_async(struct async *async)
#endif
return ret;
}
+
+int run_hook(const char *index_file, const char *name, ...)
+{
+ struct child_process hook;
+ const char *argv[10], *env[2];
+ char index[PATH_MAX];
+ va_list args;
+ int ret;
+ int i;
+
+ va_start(args, name);
+ argv[0] = git_path("hooks/%s", name);
+ i = 0;
+ do {
+ if (++i >= ARRAY_SIZE(argv))
+ die("run_hook(): too many arguments");
+ argv[i] = va_arg(args, const char *);
+ } while (argv[i]);
+ va_end(args);
+
+ if (access(argv[0], X_OK) < 0)
+ return 0;
+
+ memset(&hook, 0, sizeof(hook));
+ hook.argv = argv;
+ hook.no_stdin = 1;
+ hook.stdout_to_stderr = 1;
+ if (index_file) {
+ snprintf(index, sizeof(index), "GIT_INDEX_FILE=%s", index_file);
+ env[0] = index;
+ env[1] = NULL;
+ hook.env = env;
+ }
+
+ ret = start_command(&hook);
+ if (ret) {
+ warning("Could not spawn %s", argv[0]);
+ return ret;
+ }
+ ret = finish_command(&hook);
+ if (ret == -ERR_RUN_COMMAND_WAITPID_SIGNAL)
+ warning("%s exited due to uncaught signal", argv[0]);
+
+ return ret;
+}
diff --git a/run-command.h b/run-command.h
index a8b0c20..0211e1d 100644
--- a/run-command.h
+++ b/run-command.h
@@ -49,6 +49,8 @@ int start_command(struct child_process *);
int finish_command(struct child_process *);
int run_command(struct child_process *);
+extern int run_hook(const char *index_file, const char *name, ...);
+
#define RUN_COMMAND_NO_STDIN 1
#define RUN_GIT_CMD 2 /*If this is to be git sub-command */
#define RUN_COMMAND_STDOUT_TO_STDERR 4
--
1.6.1.160.gecdb
^ permalink raw reply related
* [PATCH v2 4/5] run_hook(): check the executability of the hook before filling argv
From: Stephan Beyer @ 2009-01-16 19:10 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Paolo Bonzini, Miklos Vajna, Shawn O. Pearce,
Daniel Barkalow, Christian Couder, gitster, Stephan Beyer
In-Reply-To: <1232133002-21725-3-git-send-email-s-beyer@gmx.net>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
I hope this does not need any more words.
Thanks to Dscho for the hint: it also saves a "free(argv)"
and some { } for patch 5/5. :-)
run-command.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/run-command.c b/run-command.c
index 49810a8..fc54c07 100644
--- a/run-command.c
+++ b/run-command.c
@@ -352,6 +352,9 @@ int run_hook(const char *index_file, const char *name, ...)
int ret;
int i;
+ if (access(git_path("hooks/%s", name), X_OK) < 0)
+ return 0;
+
va_start(args, name);
argv[0] = git_path("hooks/%s", name);
i = 0;
@@ -362,9 +365,6 @@ int run_hook(const char *index_file, const char *name, ...)
} while (argv[i]);
va_end(args);
- if (access(argv[0], X_OK) < 0)
- return 0;
-
memset(&hook, 0, sizeof(hook));
hook.argv = argv;
hook.no_stdin = 1;
--
1.6.1.160.gecdb
^ permalink raw reply related
* [PATCH v2 1/5] checkout: don't crash on file checkout before running post-checkout hook
From: Stephan Beyer @ 2009-01-16 19:09 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Paolo Bonzini, Miklos Vajna, Shawn O. Pearce,
Daniel Barkalow, Christian Couder, gitster, Stephan Beyer
In-Reply-To: <20090116172521.GD28177@leksak.fem-net>
In the case of
git init
echo exit >.git/hooks/post-checkout
chmod +x .git/hooks/post-checkout
touch foo
git add foo
rm foo
git checkout -- foo
git-checkout resulted in a Segmentation fault, because there is no new
branch set for the post-checkout hook.
This patch makes use of the null SHA as it is set for the old branch.
While at it, I removed the xstrdup() around the sha1_to_hex(...) calls
in builtin-checkout.c/post_checkout_hook() because sha1_to_hex()
uses four buffers for the hex-dumped SHA and we only need two.
(Duplicating one buffer is only needed if we need more than four.)
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
I checked if all run_hook()-like functions in the code are
addressed with my patch and found that the one in builtin-checkout.c
isn't. Then I stumbled over this rare-case bug.
builtin-checkout.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index b5dd9c0..149343e 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -47,8 +47,10 @@ static int post_checkout_hook(struct commit *old, struct commit *new,
memset(&proc, 0, sizeof(proc));
argv[0] = name;
- argv[1] = xstrdup(sha1_to_hex(old ? old->object.sha1 : null_sha1));
- argv[2] = xstrdup(sha1_to_hex(new->object.sha1));
+ argv[1] = sha1_to_hex(old ? old->object.sha1 : null_sha1);
+ argv[2] = sha1_to_hex(new ? new->object.sha1 : null_sha1);
+ /* "new" can be NULL when checking out from the index before
+ a commit exists. */
argv[3] = changed ? "1" : "0";
argv[4] = NULL;
proc.argv = argv;
--
1.6.1.160.gecdb
^ permalink raw reply related
* [PATCH v2 3/5] api-run-command.txt: talk about run_hook()
From: Stephan Beyer @ 2009-01-16 19:10 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Paolo Bonzini, Miklos Vajna, Shawn O. Pearce,
Daniel Barkalow, Christian Couder, gitster, Stephan Beyer
In-Reply-To: <1232133002-21725-2-git-send-email-s-beyer@gmx.net>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Jakub, thanks for your notes.
I still rephrased it some more.
Documentation/technical/api-run-command.txt | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt
index 82e9e83..13e7b63 100644
--- a/Documentation/technical/api-run-command.txt
+++ b/Documentation/technical/api-run-command.txt
@@ -52,6 +52,21 @@ Functions
Wait for the completion of an asynchronous function that was
started with start_async().
+`run_hook`::
+
+ Run a hook.
+ The first argument is a pathname to an index file, or NULL
+ if the hook uses the default index file or no index is needed.
+ The second argument is the name of the hook.
+ The further arguments (up to 9) correspond to the hook arguments.
+ The last argument has to be NULL to terminate the arguments list.
+ If the hook does not exist or is not executable, the return
+ value will be zero.
+ If it is executable, the hook will be executed and the exit
+ status of the hook is returned.
+ On execution, .stdout_to_stderr and .no_stdin will be set.
+ (See below.)
+
Data structures
---------------
--
1.6.1.160.gecdb
^ permalink raw reply related
* [PATCH 5/5] run_hook(): allow more than 9 hook arguments
From: Stephan Beyer @ 2009-01-16 19:10 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Paolo Bonzini, Miklos Vajna, Shawn O. Pearce,
Daniel Barkalow, Christian Couder, gitster, Stephan Beyer
In-Reply-To: <1232133002-21725-4-git-send-email-s-beyer@gmx.net>
This is accomplished using the ALLOC_GROW macro.
5 cells are initially allocated for the argv array, allowing
four actual arguments without reallocating memory.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
I was a little unsure if it looks better to
initialize i = 0, alloc = 0
and do:
ALLOC_GROW(argv, i + 1, alloc);
argv[i++] = git_path("hooks/%s", name);
instead of the xmalloc().
Do some people care about details like that?
Documentation/technical/api-run-command.txt | 2 +-
run-command.c | 16 ++++++++--------
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/technical/api-run-command.txt b/Documentation/technical/api-run-command.txt
index 13e7b63..2efe7a4 100644
--- a/Documentation/technical/api-run-command.txt
+++ b/Documentation/technical/api-run-command.txt
@@ -58,7 +58,7 @@ Functions
The first argument is a pathname to an index file, or NULL
if the hook uses the default index file or no index is needed.
The second argument is the name of the hook.
- The further arguments (up to 9) correspond to the hook arguments.
+ The further arguments correspond to the hook arguments.
The last argument has to be NULL to terminate the arguments list.
If the hook does not exist or is not executable, the return
value will be zero.
diff --git a/run-command.c b/run-command.c
index fc54c07..22abd09 100644
--- a/run-command.c
+++ b/run-command.c
@@ -346,23 +346,22 @@ int finish_async(struct async *async)
int run_hook(const char *index_file, const char *name, ...)
{
struct child_process hook;
- const char *argv[10], *env[2];
+ const char **argv, *env[2];
char index[PATH_MAX];
va_list args;
int ret;
- int i;
+ size_t i = 1, alloc = 5;
if (access(git_path("hooks/%s", name), X_OK) < 0)
return 0;
va_start(args, name);
+ argv = xmalloc(alloc * sizeof(const char *));
argv[0] = git_path("hooks/%s", name);
- i = 0;
- do {
- if (++i >= ARRAY_SIZE(argv))
- die("run_hook(): too many arguments");
- argv[i] = va_arg(args, const char *);
- } while (argv[i]);
+ while (argv[i-1]) {
+ ALLOC_GROW(argv, i + 1, alloc);
+ argv[i++] = va_arg(args, const char *);
+ }
va_end(args);
memset(&hook, 0, sizeof(hook));
@@ -377,6 +376,7 @@ int run_hook(const char *index_file, const char *name, ...)
}
ret = start_command(&hook);
+ free(argv);
if (ret) {
warning("Could not spawn %s", argv[0]);
return ret;
--
1.6.1.160.gecdb
^ permalink raw reply related
* [PATCH] builtin-commit.c: do not remove COMMIT_EDITMSG
From: Stephan Beyer @ 2009-01-16 19:40 UTC (permalink / raw)
To: git; +Cc: krh, gitster, Stephan Beyer
git-commit tries to remove the file ./COMMIT_EDITMSG instead of
$GIT_DIR/COMMIT_EDITMSG after commit preparation (e.g. running
hooks, launching editor).
This behavior exists since f5bbc3225c4b07 "Port git commit to C".
Some test cases (e.g. t/t7502-commit.sh) rely on the existence of
$GIT_DIR/COMMIT_EDITMSG after committing and, I guess, many people
are used to it. So it is best not to remove it.
This patch just removes the removal of COMMIT_EDITMSG.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
builtin-commit.c | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index e88b78f..977ea09 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -624,7 +624,6 @@ static int prepare_to_commit(const char *index_file, const char *prefix)
if (!commitable && !in_merge && !allow_empty &&
!(amend && is_a_merge(head_sha1))) {
run_status(stdout, index_file, prefix, 0);
- unlink(commit_editmsg);
return 0;
}
--
1.6.1.160.gecdb
^ permalink raw reply related
* mergetool ignore
From: Caleb Cushing @ 2009-01-16 20:19 UTC (permalink / raw)
To: git
is there any way to tell git to ignore merging certain files? I've got
files that have the same name in each directory. but I can't merge
them with an editor... it'd be easier to be able to ignore them with
git mergetool... and handle them manually.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ 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