[PATCH v3] run-command: add hint when a hook is ignored

disable this warning with `git config advice.ignoredHook false` To allow the old use-case of enabling/disabling hooks via the executable flag a new setting is introduced: advice.ignoredHook. Signed-off-by: Damien Marié <dam...@dam.io> --- Documentation/config.txt | 3 +++ ad

Re: [PATCH v2] run-command: add hint when a hook is ignored

Thanks for the help, a new patch is coming with those fixes applied. On Fri, Oct 6, 2017 at 7:53 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> I think it is easier to reason about if this were not "else if", but >> just a simple "if". > > And here

[PATCH v2] run-command: add hint when a hook is ignored

disable this warning with `git config advice.ignoredHook false` To allow the old use-case of enabling/disabling hooks via the executable flag a new setting is introduced: advice.ignoredHook. Signed-off-by: Damien Marié <dam...@dam.io> --- Documentation/config.txt | 3 ++ ad

Re: [PATCH] run-command.c: add hint when hook is not executable

On Wed, Oct 4, 2017 at 6:40 AM, Junio C Hamano <gits...@pobox.com> wrote: > Damien <dam...@dam.io> writes: > >> --- > > Please explain why this change makes sense to those who find this > commit in "git log" output six months down the line, without havin

[PATCH] run-command.c: add hint when hook is not executable

--- Documentation/config.txt | 2 ++ advice.c | 2 ++ advice.h | 1 + contrib/completion/git-completion.bash | 1 + run-command.c | 4 5 files changed, 10 insertions(+) diff --git

hooks are ignored if there are not marked as executable

red hook could be better. At least as a warning to be backward-compatible. Thanks, Damien

[PATCH v2] git-check-ref-format: clarify man for --normalize

Use of 'iff' may be confusing to people not familiar with this term. Improving the --normalize option's documentation to remove the use of 'iff', and clearly describe what happens when the condition is not met. --- Documentation/git-check-ref-format.txt | 6 +++--- 1 file changed, 3

Re: [PATCH] git-check-ref-format: fix typo in man page

me is valid then print it to standard output > and exit with a status of 0. Otherwise, exit with a non-zero status. I'll submit a revised patch shortly, following your suggestion. Cheers Damien

[PATCH] git-check-ref-format: fix typo in man page

--- Documentation/git-check-ref-format.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-check-ref-format.txt b/Documentation/git-check-ref-format.txt index 8611a99..377c85a 100644 --- a/Documentation/git-check-ref-format.txt +++

Re: Our cumbersome mailing list workflow

A bot could subscribe to the list and create branches in a public repo. (This idea feels familiar -- didn't somebody attempt this already?) Thomas Rast maintains git notes that link git commits to their gmane discussion, you can get them with [remote mailnotes] url =

Re: Summary of the problems with git pull

Felipe Contreras wrote in message 5366db742d494_18f9e4b308aa@nysa.notmuch: == git update == Another proposed solution is to have a new command: `git update`. This command would be similar to `git pull --ff-only` by default, but it could be configured to do merges instead, and when doing so

Re: `git stash pop` UX Problem

informations about a stash. So obviously not all of these would be good for inclusion into git, but maybe some of them would be somewhat worth it. When I have the time I'll try to write tests and send proper patches. -- Damien Robert -- To unsubscribe from this list: send the line unsubscribe git

Re: git-p4: exception when cloning a perforce repository

; charset=UTF-8 Content-Transfer-Encoding: 8bit Damien Gérard highlights an interesting problem. Some p4 repositories end up with symlinks that have an empty target. It is not possible to create this with current p4, but they do indeed exist. The effect in git p4 is that p4 print

Re: git-p4: exception when cloning a perforce repository

MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Damien Gérard highlights an interesting problem. Some p4 repositories end up with symlinks that have an empty target. It is not possible to create this with current p4, but they do indeed exist

Re: git-p4: exception when cloning a perforce repository

On 16 Jan 2014, at 14:08, Pete Wyckoff p...@padd.com wrote: dam...@iwi.me wrote on Wed, 15 Jan 2014 09:56 +0100: p4 fstat //depot/openssl/0.9.8j/openssl/include/openssl/bn.h@59702 ... depotFile //depot/openssl/0.9.8j/openssl/include/openssl/bn.h ... headAction edit ... headType symlink

Re: git-p4: exception when cloning a perforce repository

On 16 Jan 2014, at 15:45, Pete Wyckoff p...@padd.com wrote: Oh cool, that helps a lot. P4 is just broken here, so we can get away with being a bit sloppy in git. I'll try just pretending empty symlinks are not in the repo. Hopefully you'll have a future commit in your p4 repo that brings

Re: git-p4: exception when cloning a perforce repository

On 15 Jan 2014, at 00:24, Pete Wyckoff p...@padd.com wrote: p...@padd.com wrote on Mon, 13 Jan 2014 19:18 -0500: dam...@iwi.me wrote on Mon, 13 Jan 2014 14:37 +0100: I am trying to clone a perforce repository via git and I am having the following backtrace : {14:20}~/projects/:master

git-p4: exception when cloning a perforce repository

, Damien-- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Add a bugzilla website

/gmane.comp.version-control.git/191835/focus=192464 -- Damien Wyart -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: git-archive and submodules

you were at and I can see if I can pick up where you left off (unless you want to finish yourself). Greetings I was just wondering whether there been any progress on this topic since last year... André ? Cheers Damien -- To unsubscribe from this list: send the line unsubscribe git

Bug? ignored files overwritten by checkout

git init git commit --allow-empty -m init git checkout -b test echo foo foo git add foo git commit -am 'add foo' git checkout master echo 'Important data' foo #[1] echo foo .gitignore git checkout test If I tried a `git checkout test` after [1], I would get the error message error: The

Re: Remove old forgotten command: whatchanged

Matthieu Moy wrote in message vpqfvukdy39@anie.imag.fr: that confuses users. ... but I do agree that the doc is really confusing. It would be much better if the doc could be reduced to: This is a synonym for linkgit:git-log[1] --raw --some --other ---options. Please refer to the

Re: Remove old forgotten command: whatchanged

Junio C Hamano wrote in message 7v61vg9eht@alter.siamese.dyndns.org: The tutorial was written in fairly early days of Git's history, in order to primarily help those who want to use the plumbing command to script their own Porcelain commands. As it says at the very beginning, the

Re: [Query] Can we ignore case for commiters name in shortlog?

as damien.olivier.robert+...@gmail.com and a dummy email address robert@numenor.night-elves. I thought that putting: Damien Robert damien.olivier.robert+...@gmail.com robert@numenor.night-elves in the .mailmap would unify the two adresses, but it does not: git shortlog -se 15 Damien Robert

git rebase -p and patch equivalent commits

Hi all, I was wondering if you had any tips on the following workflow: I work on an experimental feature branch of a project. I have some patches that I implement in branch patch1 and patch2 on top of the feature branch. I test if they both work together by merging patch1 and patch2 into a build