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 the "Please commit your changes or stash them before you merge." message. We are trying to do the equivalent of that - to keep people from merging if there are uncommitted changes (that should be) in the repo. But, best I know, git will not consider a MariaDB table to be a part of its 'repo'. So, we need a hook. We are fond of learning about this problem before the fetch happens, but it definitely has to happen pre-merge. On Thursday, September 27, 2018 at 11:52:48 AM UTC-4, B. Lachele Foley wrote: > > Our group could really use a pre-pull hook. Is there already a way to do > this? I wrote a little wrapper script in bash for it, but that's not ideal. > > Here is our use case: > > The code in our repo is coupled to a database. We have made it so that all > the parts of the database that are controlled by developers are git-managed > within the repo. However, it is often convenient or otherwise desirable > for the developer to edit the relevant database tables directly (in the > usual manner, by connecting to the DB server and using SQL commands,etc.). > But, if this happens, it is very important that the developer has dumped > the relevant data into the git-managed files and committed the changes > before pulling. Doing this ensures that there will be a merge conflict if, > for example, two devs have modified the same row in the same table (a > legitimate possibility for us). > > The pre-pull hook we would write would do something like this: It would > dump the relevant data to temporary files and compare them with the > git-managed versions. If there are differences, a pull would not be > allowed until the dev has made the git-managed files match the contents of > their database. > > I looked briefly at the source code for git. I think I found where I > would need to put the new code, but also found that I would need to learn > many new things before making the change. So, if I do it, there might be a > considerable wait. Therefore, part 2 of this question is: does anyone know > who to ask about implementing this feature if there is not another way to > handle the situation? > > Thanks! > > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
