git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Rafael Santiago <voidbrainvoid@tutanota.com>
To: "brian m. carlson" <sandals@crustytoothpaste.net>
Cc: Rafael Santiago via GitGitGadget <gitgitgadget@gmail.com>,
	Git <git@vger.kernel.org>
Subject: Re: [PATCH] Give support for hooks based on platform
Date: Mon, 23 Aug 2021 03:07:49 +0200 (CEST)	[thread overview]
Message-ID: <MhkY8ud--3-2@tutanota.com> (raw)
In-Reply-To: <YSLKrX/QTZtxBGDz@camp.crustytoothpaste.net>

Well, you are taking into consideration that every git user that needs to
automate some stuff during a scm event will do it from a shell
(I meant true shell or a mocked up one such as cygwin, msys, etc)
and it is true, by design.

However, not all git users (out unix) uses git from "bash-like"
environments. I know people that prefers using it from a well-cooked
IDE by clicking and dragging things or even from command prompt when
on Windows. Those people are not able to handle some scm event
automation as unix users because git hook in its essence presupposes
the existence/necessity of a powerful shell (okay, it is possible to
put a shebang and call a batch file on windows, maybe, but it is a
little clumsy, in my opinion). On Windows, users can do a bunch of stuff
just by using the ready to go powershell, but open an if/else on a bash
script to run a cygwin instance by calling powershell from there is not a
good and clean solution for this type of user. Presupposing shell for git,
limitates the idea behind the scm event handling with hooks, because
currently it is strongly dependent from shell to work on every git
supported platform.

The idea of having hooks being executed by platform would be the first
step to give support to execute commands on scm events without
obligating users out of a unix have a shell interpreter to access
native stuff. Currently, this commit does not implement it but would be
possible to do and in a  less noisy way for all unix-like stuff. I am not sure
but currently a _windows hook out from cygwin would result on a spawn
error, would not?

Git hooks are useful features but would be more useful if it breaked up
the shell jail. It could make git much more integrated with the current
platform.  Being possible to make it powerful as it is on a unix even on
a total different platform as Windows, let's say.

For sure, this commit are not a "panacea" but intends to start making
git-hooks more independent from 3rd party software to work on as expected,
on every platform that a git-repo is expected to be handled.

I hope I was clearer from this time.

Rafael Santiago
--
22 de ago. de 2021 19:07 por sandals@crustytoothpaste.net:

> On 2021-08-21 at 23:11:27, Rafael Santiago wrote:
>
>> In my opinion "binary hooks" (hooks that execute specific binaries not
>> present in the system as a default tool) should be versioned and built
>> as a support tool into the repository or in the worst case downloaded
>> from somewhere, even because versioning binaries into git repos is
>> considered a bad practice that could make bloated repos.
>>
>
> Yes, I agree binary hooks should not be checked into the repository.
>
>> The point is that in many cases a dependency with a script language is
>> created only to make the hook actions portable from a platform to
>> other, but what this script in its essence does is a thing that could
>> be done with basic tools delivered with the current operating system.
>>
>
> Then, in general, it can be done in a shell script containing an if-then
> statement per platform using the native tools, so I'm not seeing the
> particular reason that this series is necessary if the hooks being
> executed aren't binaries.  All systems on which Git runs must contain a
> POSIX-compatible shell.
>
> Can you explain the rationale for your proposal in more detail so that
> we can understand why this change is necessary?  Typically this is done
> in the commit message, but I don't think I understand why you want to do
> this.
>
>> There is no problem on using cygwin on windows, you should use
>> standard hook and do all the effort to make it unique for cygwin
>> environments and true unix boxes (in other words: you would continue
>> doing what you are doing, because it attends yours requirements).
>> Notice that everything that have been working will stay working as
>> before. Anyway, if cygwin becomes a point of incompatibility at some
>> point, you could use the "_windows" version by coding your "cygwin
>> script" there.
>>
>
> Right, my point is that your commit message proposes using "windows" for
> Cygwin.  The patch doesn't, but your commit message says that every
> version of Windows is considered "windows".
> -- 
> brian m. carlson (he/him or they/them)
> Toronto, Ontario, CA
>


  reply	other threads:[~2021-08-23  1:07 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-21 20:00 [PATCH] Give support for hooks based on platform Rafael Santiago via GitGitGadget
2021-08-21 21:50 ` brian m. carlson
2021-08-21 23:11   ` Rafael Santiago
2021-08-22 22:07     ` brian m. carlson
2021-08-23  1:07       ` Rafael Santiago [this message]
2021-08-23 16:23       ` Jeff King
2021-08-23 17:59         ` Junio C Hamano
2021-08-23 18:32           ` Jeff King
2021-08-23 16:35       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=MhkY8ud--3-2@tutanota.com \
    --to=voidbrainvoid@tutanota.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=sandals@crustytoothpaste.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).