gitdir work with worktrees, respect core.hooksPath, etc
-Since v2.9.0, Git knows about the config variable core.hookspath
-that allows overriding the path to the directory containing the
-Git hooks.
+Since v2.9.0, Git knows about the config variable
-hooks-path-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/361
Range-diff vs v2:
1: c101422936 < -: -- respect core.hooksPath, falling back to
.git/hooks
-: -- > 1: 65c2fa33e1 Fix gitdir e.g. to respect core.hooksPath
--
gitgitgadget
Hi Pratyush,
On Fri, 4 Oct 2019, Pratyush Yadav wrote:
> On 01/10/19 07:38PM, Johannes Schindelin wrote:
> >
> > On Tue, 1 Oct 2019, Pratyush Yadav wrote:
> >
> > > On 30/09/19 11:42AM, Johannes Schindelin wrote:
> > > > On Fri, 27 Sep 2019, Pratyush Yadav wrote:
> > > > > On 27/09/19 08:10AM, Be
On 01/10/19 07:38PM, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 1 Oct 2019, Pratyush Yadav wrote:
>
> > On 30/09/19 11:42AM, Johannes Schindelin wrote:
> > > On Fri, 27 Sep 2019, Pratyush Yadav wrote:
> > > > On 27/09/19 08:10AM, Bert Wesarg wrote:
> > > > > On Fri, Sep 27, 2019 at 12:40 AM Pra
Hi,
On Tue, 1 Oct 2019, Pratyush Yadav wrote:
> On 30/09/19 11:42AM, Johannes Schindelin wrote:
> > On Fri, 27 Sep 2019, Pratyush Yadav wrote:
> > > On 27/09/19 08:10AM, Bert Wesarg wrote:
> > > > On Fri, Sep 27, 2019 at 12:40 AM Pratyush Yadav
> > > > wrote:
> > > > > gitdir is used in a lot o
On 30/09/19 11:42AM, Johannes Schindelin wrote:
> On Fri, 27 Sep 2019, Pratyush Yadav wrote:
> > On 27/09/19 08:10AM, Bert Wesarg wrote:
> > > On Fri, Sep 27, 2019 at 12:40 AM Pratyush Yadav
> > > wrote:
> > > > gitdir is used in a lot of places, and I think all those would
> > > > also
> > > >
From: Johannes Schindelin
Since v2.9.0, Git knows about the config variable core.hookspath
that allows overriding the path to the directory containing the
Git hooks.
Since v2.10.0, the `--git-path` option respects that config
variable, too, so we may just as well use that command.
For Git
many spawned processes.
Johannes Schindelin (1):
respect core.hooksPath, falling back to .git/hooks
git-gui.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
base-commit: 60c60b627e81bf84e1cb01729d2ae882178f079d
Published-As:
https://github.com/gitgitgadget/git/releases/tag
nnes Schindelin
> > > >
> > > > Since v2.9.0, Git knows about the config variable core.hookspath
> > > > that allows overriding the path to the directory containing the
> > > > Git hooks.
> > > >
> > > > Since
2.9.0, Git knows about the config variable core.hookspath
> > > that allows overriding the path to the directory containing the
> > > Git hooks.
> > >
> > > Since v2.10.0, the `--git-path` option respects that config
> > > variable, too, so we may just as
overriding the path to the directory containing the
> > Git hooks.
> >
> > Since v2.10.0, the `--git-path` option respects that config
> > variable, too, so we may just as well use that command.
> >
> > For Git versions older than v2.5.0 (which was the first version
Hi,
On 26/09/19 02:17PM, Johannes Schindelin via GitGitGadget wrote:
> From: Johannes Schindelin
>
> Since v2.9.0, Git knows about the config variable core.hookspath
> that allows overriding the path to the directory containing the
> Git hooks.
>
> Since v2.10.0, th
From: Johannes Schindelin
Since v2.9.0, Git knows about the config variable core.hookspath
that allows overriding the path to the directory containing the
Git hooks.
Since v2.10.0, the `--git-path` option respects that config
variable, too, so we may just as well use that command.
For Git
This is yet another patch from Git for Windows.
Johannes Schindelin (1):
respect core.hooksPath, falling back to .git/hooks
git-gui.sh | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
base-commit: 60c60b627e81bf84e1cb01729d2ae882178f079d
Published-As:
https://github.com
On Tuesday, December 18, 2018 2:56:43 PM MST Johannes Schindelin wrote:
> Sounds like you need https://github.com/git-for-windows/git/pull/1757
> (we do not currently have a responsive maintainer for Git GUI,
> unfortunately, otherwise this patch would have made it into an official
> Git version al
Hi Ivan,
On Tue, 18 Dec 2018, Иван Могиш wrote:
> Hello.
> There is a little difference in behavior when you are committing to
> the worktree from CLI or some git client (tortoisegit/sourcetree) and
> embedded git gui.
>
> If you configure git hooks in your repository and t
Hello.
There is a little difference in behavior when you are committing to
the worktree from CLI or some git client (tortoisegit/sourcetree) and
embedded git gui.
If you configure git hooks in your repository and then add a worktree
(via git worktree add), hooks from main repository works well
On Fri, Dec 15, 2017 at 12:48:07PM -0800, Satyakiran Duggina wrote:
> To give the code pullers a chance to review, can we not have a
> `trusted-hooks: default` and `trusted-SHA: ` field in .git/.
> I'm assuming githooks/ are source tracked here.
>
> When developer tries to execute `git commit`, g
Thanks, Bryan.
To give the code pullers a chance to review, can we not have a
`trusted-hooks: default` and `trusted-SHA: ` field in .git/.
I'm assuming githooks/ are source tracked here.
When developer tries to execute `git commit`, git can ask developer to
change `trusted-hooks` field to true or
On Fri, Dec 15, 2017 at 11:12 AM, Satyakiran Duggina
wrote:
> I see that `git init` creates a .git directory and hooks are to be
> placed in that directory and these hooks are not tracked by version
> control. To achieve tracked hooks, either each developer has to copy
> the hooks or use tools lik
I see that `git init` creates a .git directory and hooks are to be
placed in that directory and these hooks are not tracked by version
control. To achieve tracked hooks, either each developer has to copy
the hooks or use tools like overcommit, pre-commit, husky etc.
I'm wondering why hooks are not
So once upon a time we compared Gits security model with a
web browser. A web browser lets you execute 3rd party code
(e.g. javascript) and it is supposedly safe to look at malicious sites.
Currently Git only promises to have the clone/fetch operation safe,
not the "here is a zip of my whole repo"
fic/repo.path
.gitconfig-fancy-log-pager
The main difference is that the profile inclusion is done by path rather
than riding along with the repository directory if it gets moved. In
practice I doubt that matters much, and I think the security model for
include.gitdir is a lot simpler.
>
Hi,
On Tue, Oct 3, 2017 at 1:45 AM, Jonathan Nieder wrote:
> Proposed fix: because of case (1), I would like a way to tell Git to
> stop trusting any files in .git. That is:
>
> 1. Introduce a (configurable) list of "safe" configuration items that
> can be set in .git/config and don't resp
"include" is not in "safe" category, but a value that
begins with "~/.config/git/" are excempt???
> 3. Likewise for hooks: my ~/.config/git/hooks/ directory would
> contain hooks for repositories to make use of. Repositories could
> symlink to hoo
ot seem so dated:
1. I put my repository in a zip file and ask a Git expert to help me
recover data from it, or
2. My repository is in a shared directory on NFS. Unless the
administrator setting that up is very careful, it is likely that
the least privileged user with write ac
ong the lines:
Since v2.9.0, Git knows about the config variable core.hookspath
that allows overriding the path to the directory containing the
Git hooks.
Since v2.10.0, the `--git-path` option respects that config
variable, too, so we may just as well use t
Dear Philip,
the previous mail contains a patch against the master of
http://repo.or.cz/git-gui.git
Could you please review it? I am not a TCL developer, so please take
extra care!
Thanks,
Philipp
signature.asc
Description: OpenPGP digital signature
Signed-off-by: Philipp Gortan
---
The following patch tries to fix git-gui to respect the core.hooksPath config
variable, falling back to the old behavior.
git-gui.sh | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/git-gui.sh b/git-gui.sh
index 5bc21b8..a5335b1 100755
---
On Thu, Dec 15, 2016 at 09:14:30AM -0500, Jeff King wrote:
> On Thu, Dec 15, 2016 at 02:57:18PM +0100, Chiel ten Brinke wrote:
>
> > Would patches introducing new git hooks, e.g. for post-fetch, be
> > eligible for acceptance?
>
> The general guidelines for addin
On Thu, Dec 15, 2016 at 02:57:18PM +0100, Chiel ten Brinke wrote:
> Would patches introducing new git hooks, e.g. for post-fetch, be
> eligible for acceptance?
The general guidelines for adding hooks is laid out here:
http://public-inbox.org/git/7vbq7ibxhh@gitster.siamese.dynd
Would patches introducing new git hooks, e.g. for post-fetch, be
eligible for acceptance?
If a more detailed explanation about a specific use case is required,
I'd be happy to provide it.
Btw, the link in the README
http://news.gmane.org/gmane.comp.version-control.git/ is dead.
Chiel
Ævar Arnfjörð Bjarmason writes:
> I think it's fair enough to say that if we had this facility this
> would be good enough:
>
> * Your hooks are executed in glob() order, local .git first, then
> /etc/git/...
>
> * If it's a hook like pre-commit that can reject something the first
> hook to fa
On 2016-04-26 12:09 PM, Ævar Arnfjörð Bjarmason wrote:
Basically you can look at patches to a project on a spectrum of:
1. You hacked something up locally
2. It's in someone's *.git repo as a POC
3. It's a third-party patch series used by a bunch of people
4. In an official release but
On Tue, Apr 26, 2016 at 6:09 PM, Ævar Arnfjörð Bjarmason
wrote:
> On Tue, Apr 26, 2016 at 3:40 PM, Marc Branchaud wrote:
>> On 2016-04-26 06:58 AM, Ævar Arnfjörð Bjarmason wrote:
>>>
>>> Makes sense to have an experimental.* config tree for git for stuff like
>>> this.
>>
>> I disagree.
>>
>> *
On Tue, Apr 26, 2016 at 3:40 PM, Marc Branchaud wrote:
> On 2016-04-26 06:58 AM, Ævar Arnfjörð Bjarmason wrote:
>>
>> Makes sense to have an experimental.* config tree for git for stuff like
>> this.
>
> I disagree.
>
> * If the point is to express some kind of warning to users, I think the
> com
On 2016-04-26 06:58 AM, Ævar Arnfjörð Bjarmason wrote:
>
> Makes sense to have an experimental.* config tree for git for stuff like this.
I disagree.
* If the point is to express some kind of warning to users, I think the
community has been much better served by leaving experimental settings
und
On Mon, Apr 25, 2016 at 7:45 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> The reason for supporting the *.d directories was that I spotted a lot
>> of hooks people had hacked up at work using the pee(1) command[1] to
>> run sequences of other unrelated hook commands.
>
> IIRC,
Ævar Arnfjörð Bjarmason writes:
> The reason for supporting the *.d directories was that I spotted a lot
> of hooks people had hacked up at work using the pee(1) command[1] to
> run sequences of other unrelated hook commands.
IIRC, we wanted to do this several years ago but after discussion
deci
On Sat, Apr 23, 2016 at 1:33 AM, Ævar Arnfjörð Bjarmason
wrote:
> Change the hardcoded lookup for .git/hooks/* to optionally lookup in
> $(git config core.hooksDirectory)/* instead if that config key is set.
I think this'll do for my use-case, but I started with a rather more
ambi
Federico Fissore writes:
> Hello everyone
>
> In file commit-msg.sample, grep test is reversed. It greps
> '^Signed-off-by: '
> while it should grep
> 'Signed-off-by: '
>
> If you run the sample against attached file, it won't complain. Remove
> the ^ and it will work as expected
I think the tes
Hello everyone
In file commit-msg.sample, grep test is reversed. It greps
'^Signed-off-by: '
while it should grep
'Signed-off-by: '
If you run the sample against attached file, it won't complain. Remove
the ^ and it will work as expected
Regards
Federico
Commit message
Signed-of
I've noticed that not all hooks have all of the environment variables
set when they are run, and it is not clear from the manual pages which
hooks have which variables set on the command line. Specifically, they
don't all have GIT_DIR set, I haven't taken the time to verify exactly
which variables
mkdir new && cd new
$ git init src && git init --bare dst
$ cd src
$ echo "(date;cat) >pushlog" >.git/hooks/pre-push
$ chmod +x .git/hooks/pre-push
$ git commit -m 'initial' --allow-empty
$ git tag -m 'initial' initial
Push o
> I do not offhand know (I am on a bus with terrible connection so I
> won't bother checking the source now) if we send "this ref has to
> point at that object" even for STATUS_UPTODATE cases, to cause your
> remote to trigger the receive hook in the frist place, but if that
> is the case, then the
"Chris O'Kelly" writes:
[administrivia: people read from top to bottom; please do not top
post]
> On Wed, Apr 15, 2015 at 1:08 AM, Junio C Hamano wrote:
>> "Chris O'Kelly" writes:
>>
>>> A brief background of my use case:
>>> I am wanting to write a pre-push hook to prevent tags being pushed t
Unfortunately in this case we don't have control over the hooks at the
receiving end - we want to prevent tags from being pushed by all users
to these repo's.
On Wed, Apr 15, 2015 at 1:08 AM, Junio C Hamano wrote:
> "Chris O'Kelly" writes:
>
>> A brief background of my use case:
>> I am wanting
"Chris O'Kelly" writes:
> A brief background of my use case:
> I am wanting to write a pre-push hook to prevent tags being pushed to
> our production servers. The production servers in our case are --bare
> endpoints, and when we push a tag at them, they always checkout the
> commit that tag is a
Hello,
Just a brief note about a feature I would find incredibly useful, were
it available.
A brief background of my use case:
I am wanting to write a pre-push hook to prevent tags being pushed to
our production servers. The production servers in our case are --bare
endpoints, and when we push a t
On Mon, Apr 28, 2014 at 09:43:10AM -0700, Junio C Hamano wrote:
> Yes, I'd love to see something along that line in the longer term,
> showing all the objects as just regular objects under the hood, with
> implementation details hidden in the object layer (just like there
> is no distinction betwe
Jeff King writes:
> On Sat, Apr 26, 2014 at 10:24:50AM -0700, Junio C Hamano wrote:
>
>> Suvorov Ivan writes:
>>
>> > I want to extend the functionality of git due to the possibility of
>> > separation of the user repository into 2 parts - one part will be
>> > stored as usual, under version co
On Sat, Apr 26, 2014 at 10:24:50AM -0700, Junio C Hamano wrote:
> Suvorov Ivan writes:
>
> > I want to extend the functionality of git due to the possibility of
> > separation of the user repository into 2 parts - one part will be
> > stored as usual, under version control git, and the second pa
Suvorov Ivan writes:
> I want to extend the functionality of git due to the possibility of
> separation of the user repository into 2 parts - one part will be
> stored as usual, under version control git, and the second part will
> be stored in another location such as an FTP-server.
Sounds like
Hello.
I want to extend the functionality of git due to the possibility of separation
of the user repository into 2 parts - one part will be stored as usual, under
version control git, and the second part will be stored in another location
such as an FTP-server.
This will be done in order to be
> http://stackoverflow.com/questions/22585091/git-hooks-pre-push-script-does-not-receive-input-via-stdin
>>
>> Is this a bug in git? Or am I just a shell noob?
>>
>> Thanks in advance,
>>
>> David
>
> I assume that you have the right version of Git ?
> You can
On 2014-03-23 01.44, David Cowden wrote:
> http://stackoverflow.com/questions/22585091/git-hooks-pre-push-script-does-not-receive-input-via-stdin
>
> Is this a bug in git? Or am I just a shell noob?
>
> Thanks in advance,
>
> David
I assume that you have the right ver
http://stackoverflow.com/questions/22585091/git-hooks-pre-push-script-does-not-receive-input-via-stdin
Is this a bug in git? Or am I just a shell noob?
Thanks in advance,
David
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message
> 2013/10/26 Bryan Turner :
> > No, the .git/hooks directory in your clone is created from your local
> > templates, installed with your Git distribution, not the remote hooks.
> > On Linux distributions, these templates are often in someplace like
> > /usr/share/git
Very helpful :) thanks !
2013/10/26 Bryan Turner :
> No, the .git/hooks directory in your clone is created from your local
> templates, installed with your Git distribution, not the remote hooks.
> On Linux distributions, these templates are often in someplace like
> /usr/share/git-co
No, the .git/hooks directory in your clone is created from your local
templates, installed with your Git distribution, not the remote hooks.
On Linux distributions, these templates are often in someplace like
/usr/share/git-core/templates (for normal packages), and on Windows
with msysgit they are
But when someone do a "clone" he don't have .git/hooks directory
downloaded to his local computer ? I thought so ...
2013/10/26 Junio C Hamano :
> Olivier Revollat writes:
>
>> I was wondering : What if I had a "malicious" GIT repository who can
>
Olivier Revollat writes:
> I was wondering : What if I had a "malicious" GIT repository who can
> "inject" code via git hooks mechanism : someone clone my repo and
> some malicious code is executed when a certain GIT hook is triggered
> (for example on commit
I was wondering : What if I had a "malicious" GIT repository who can
"inject" code via git hooks mechanism : someone clone my repo and
some malicious code is executed when a certain GIT hook is triggered
(for example on commit ("prepare-commit-msg' hook)) ? What if I
63 matches
Mail list logo
