Sorry for the sudden silence. Other duties require my attention. This
will likely remain so for a couple more weeks, but I might be able to sneak
in a peek at this before then.
I just want to be sure you all know I appreciate all the replies. I don't
mean to ignore you. It's just that I
forgot the list, and to use the right ID, doh
On 02/10/2018 21:45, Philip Oakley wrote:
> Hi,
>
> If I understand correctly, you have some database 'tables' that you
are trying to 'version control' with Git. And that because the 'tables'
are not part of a regular file system, you can't use
On Tue, Oct 02, 2018 at 09:02:26AM -0700, B. Lachele Foley wrote:
[...]
> PS: The following didn't work for us. We tested with a "hello-world"-type
> script:
>
> "Note that on *nix systems installing such a script program is as easy as
> dropping it under any directory on the user's $PATH
The more I think about it, the more I head back to a pre-pull hook. But, I
think that also having a pre-merge hook is good. I might not use a
pre-fetch hook if I have pre-pull, but see no harm having it.
Reasons for pre-pull:
* It allows a distinction from fetch. If you know what you're
Another way to look at this is:
Git already has a sort of pre-merge hook in that it will not let you merge
if there are un-committed changes in the repo.
We are trying to do the same thing. The difference is that the
un-committed changes aren't something git can see, so we will never get
