Thank you for your quick and thoughtful reply! I knew that a git-pull is a fetch followed by a merge. But, I had not seen arguments for always splitting the process up. For newbies, I always considered 'git pull' to be simpler when getting them up to speed. In this case, you are certainly correct that it is the safer strategy. I had also looked for a pre-merge or post-fetch hook, but could find none. I will present the article you mention to the group. Thank you.
I had already written a sort of "porcelain level" script. It lives at a relevant top-level in the repo with a name equivalent to "SaferGitPull.bash". The devs buy in to the general procedures, so I'm pretty sure they will use it most of the time. But.... one is most likely to forget when in a hurry after a bunch of time-sensitive changes. So, I was hoping to derail the pull/fetch/merge process altogether. I didn't realize that git would go looking for an 'X' in 'git X' in plain old paths. Nice! I will also present this to the devs to see if they would prefer that sort of solution. Would it be dangerous to name the wrapper fetch (or pull)? Would git look for 'fetch' or 'pull' in /usr/local/bin before looking elsewhere? Does it follow the user's PATH? In this case, preventing a fetch is reasonable: there is not much point bothering to download the data if you aren't ready to use it. It might also be relevant to know that the devs are using all manner of machines (personal, shared, virtual, Linux, Mac, etc.) all over the place on multiple continents. Their development environment is an entire replica of our website, utilizing Docker, complete with their own database servers, databases and even a miniature compute cluster. So, most will have to implement whatever solution is used in whatever operating system they are using. I will think further about the feature request if I cannot make do in other ways. Thank you also for that information. On Thursday, September 27, 2018 at 12:28:24 PM UTC-4, Konstantin Khomoutov wrote: > > On Thu, Sep 27, 2018 at 08:52:48AM -0700, 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? > > Well, I think you might have been derailed a bit by your research ;-) > > The thing is, `git pull`, is `git fetch` followed by `git merge` with > some magic thrown in. The magic here is the reason many seasoned Git > users suggest to not use `git pull` ever, or at least not before one > have became a seasoned Git user onself - to know what exactly happens > when they run `git pull`, and what to do if that thing fails. > > Hence an approach you might try to adopt is to write your own high-level > (or "porcelain-level", as Git devs would call it) script/program which > your devs would call instead of `git pull`. That command would mimic the > behaviour of `git pull` to the necessary degree - read the current > branch's configuration to figure out what upstream repo+branch combo it > is linked to, then `git fetch` what is necessary, then run your checks > then merge - if the checks pass. > Note that on *nix systems installing such a script program is as easy as > dropping it under any directory on the user's $PATH - so that if you put > a file named "foo" under, say, /usr/local/bin, then running `git foo` > will make the Git front-end program to find that /usr/local/bin/foo and > execute it. > > I do understand making this thing is an administrative burden but I'd > argue it's a lesser burden than supporting a fork of Git with your > custom patches or convincing the Git devs to implement such a feature. > > Still, if you anyway want to proceed with getting in contact with the > Git devs, please follow the procedure described in [2]. > > 1. https://longair.net/blog/2009/04/16/git-fetch-and-merge/ > 2. > https://gist.github.com/tfnico/4441562#writing-an-email-to-the-developers-list > > > -- 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 git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
