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`,
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
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
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
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
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.
> 3. Likewise for hooks: my ~/.config/git/hooks/
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
acker.
Meaning, "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
>
ated:
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 access to .git
t of love. Something along 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
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
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
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
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
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
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
Æ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
On Sat, Apr 23, 2016 at 1:33 AM, Ævar Arnfjörð Bjarmason
<ava...@gmail.com> 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
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
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
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
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 only the branch:
$ GIT_TRACE_PACKET=1 git push ../dst master 21 | grep 'push'
11:07:26 packet: push
Chris O'Kelly ch...@mapcreative.com.au 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
Chris O'Kelly ch...@mapcreative.com.au 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 gits...@pobox.com wrote:
Chris O'Kelly ch...@mapcreative.com.au writes:
A brief background of my use case:
I am wanting to
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 code
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 gits...@pobox.com wrote:
Chris O'Kelly ch...@mapcreative.com.au writes:
A brief
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
Jeff King p...@peff.net writes:
On Sat, Apr 26, 2014 at 10:24:50AM -0700, Junio C Hamano wrote:
Suvorov Ivan sv...@inbox.ru 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,
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 between
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
Suvorov Ivan sv...@inbox.ru 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.
On Sat, Apr 26, 2014 at 10:24:50AM -0700, Junio C Hamano wrote:
Suvorov Ivan sv...@inbox.ru 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
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 version of Git ?
You can look
://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 look into the source of Git, to be more exact the test suite
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 to majord...@vger.kernel.org
Very helpful :) thanks !
2013/10/26 Bryan Turner btur...@atlassian.com:
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
2013/10/26 Bryan Turner btur...@atlassian.com:
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
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 email
/etc/passwd for exemple
Olivier Revollat revol...@gmail.com 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 (prepare-commit-msg' hook
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
45 matches
Mail list logo