Re: [git-users] Re: pre-pull hook?
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 can't reply intelligently at the moment, so I must wait. I will return to this as soon as I can. Thanks! On Tuesday, October 2, 2018 at 5:11:33 PM UTC-4, Philip Oakley wrote: > > > 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 Git's expectation > of managing files to actually do the 'control'. > > > > [I've used the term 'table' to represent the database artefacts , and > I've quoted 'control' because , being decentralised, Git is more about > validation and verification, along with normally being able to > 'checkout' previous versions into the file system (but not your database > ;-). `git status` is the part that detects the changes.] > > > > An alternate route is to have a glance at how Git for Windows does > it's 'git status' command by using the compat folder in the source > https://github.com/git/git/tree/master/compat to massage the opening and > closing of files and determine if they have changed. > > > > Assuming you can get a few fellow hackers, all you need to do (famous > last words) is tweak those routines such that when they see your magic > database directories, it does the local comparison and status checks, so > that the database looks to all intents and purposes as if it is a > directory (or symlink). > > > > > > It maybe a step too far, but could be a good project. Maybe even try > suggesting it as a project for Outreachy [see Git dev mailing list] > > https://public-inbox.org/git/CAP8UFD0XS3vsB1n_Jm=4TrdXqc8zU9+3LBU5CFn5TDYhYgf=2...@mail.gmail.com/ > > > > > > > Hoping I haven't totally misunderstood what's required.. > > -- > > Philip > > > > On 02/10/2018 17:02, B. Lachele Foley wrote: > >> 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 doing > and don't want checks first, then use fetch. During normal work, or for > new people, use pull and let it check the basics for you. > >> > >> * It happens first, before the fetch. Did I forget about the 50 > files I changed? I would rather get those committed/reverted/removed > first. This is especially nice to new folks. > >> > >> > >> A huge part of our project is written by students. The project is > large and complex and requires considerable scientific and computing > savvy. Most incoming students know only a little about either the > specific science or the specific computing needed by the project. We > need all the safety nets we can get. We all try not to break things, > but we're all human. > >> > >> I wish I could show the source code that prompted this request. We > keep it hidden because we're running full-tilt just to get things > working, and there is no extra time to be certain we won't be opening > ourselves to mischief if we open the sources. But, you can see the > development version of the product here: dev.glycam.org Maybe one > day we can open that code. > >> > >> See dev.glycam.org/cb to get a superficial idea of the scientific > complexity involved. The rules for the chemical behaviors of those > monosaccharide buttons are in the database. We do it that way so that > the scientists can update the rules without having to learn > Django/Python/C++/CSS/HTML/SVG/dot/etc. But, the coders might also > update the table for a given monosaccharide. Those changes need to be > able to be merged. We're using git (coupled with Django's 'fixtures' > and UUIDs) to help us with that. But, git can't manage the data until > they're in the repo. > >> > >> Some of the source is open: https://github.com/GLYCAM-Web - the > 'dev-X' branches are the most up to date. Eventually, parts of that > code will depend on and/or originate from database tables, or so we hope. > >> > >> Anyhow, thanks for listening and for all the comments. > >> > >> > >> 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 - so that if you > put > >> a file named "foo" under, say, /usr/local/bin, then running `git foo` > >>
Re: [git-users] Re: pre-pull hook?
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 Git's expectation of managing files to actually do the 'control'. > > [I've used the term 'table' to represent the database artefacts , and I've quoted 'control' because , being decentralised, Git is more about validation and verification, along with normally being able to 'checkout' previous versions into the file system (but not your database ;-). `git status` is the part that detects the changes.] > > An alternate route is to have a glance at how Git for Windows does it's 'git status' command by using the compat folder in the source https://github.com/git/git/tree/master/compat to massage the opening and closing of files and determine if they have changed. > > Assuming you can get a few fellow hackers, all you need to do (famous last words) is tweak those routines such that when they see your magic database directories, it does the local comparison and status checks, so that the database looks to all intents and purposes as if it is a directory (or symlink). > > > It maybe a step too far, but could be a good project. Maybe even try suggesting it as a project for Outreachy [see Git dev mailing list] https://public-inbox.org/git/CAP8UFD0XS3vsB1n_Jm=4TrdXqc8zU9+3LBU5CFn5TDYhYgf=2...@mail.gmail.com/ > > > Hoping I haven't totally misunderstood what's required.. > -- > Philip > > On 02/10/2018 17:02, B. Lachele Foley wrote: >> 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 doing and don't want checks first, then use fetch. During normal work, or for new people, use pull and let it check the basics for you. >> >> * It happens first, before the fetch. Did I forget about the 50 files I changed? I would rather get those committed/reverted/removed first. This is especially nice to new folks. >> >> >> A huge part of our project is written by students. The project is large and complex and requires considerable scientific and computing savvy. Most incoming students know only a little about either the specific science or the specific computing needed by the project. We need all the safety nets we can get. We all try not to break things, but we're all human. >> >> I wish I could show the source code that prompted this request. We keep it hidden because we're running full-tilt just to get things working, and there is no extra time to be certain we won't be opening ourselves to mischief if we open the sources. But, you can see the development version of the product here: dev.glycam.org Maybe one day we can open that code. >> >> See dev.glycam.org/cb to get a superficial idea of the scientific complexity involved. The rules for the chemical behaviors of those monosaccharide buttons are in the database. We do it that way so that the scientists can update the rules without having to learn Django/Python/C++/CSS/HTML/SVG/dot/etc. But, the coders might also update the table for a given monosaccharide. Those changes need to be able to be merged. We're using git (coupled with Django's 'fixtures' and UUIDs) to help us with that. But, git can't manage the data until they're in the repo. >> >> Some of the source is open: https://github.com/GLYCAM-Web - the 'dev-X' branches are the most up to date. Eventually, parts of that code will depend on and/or originate from database tables, or so we hope. >> >> Anyhow, thanks for listening and for all the comments. >> >> >> 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 - 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. " >> >> >> >> >> On Monday, October 1, 2018 at 11:21:01 AM UTC-4, B. Lachele Foley wrote: >> >> 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.
Re: [git-users] Re: pre-pull hook?
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 - 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. "
Sorry for confusion: the script should be named after the "git-"
pattern in order for it to work as the `git whatever` command:
~$ echo $PATH
/home/kostix/bin:/usr/local/bin:/usr/bin:/bin
~$ cat >${PATH%%:*}/git-hello
#!/bin/sh
echo hello
~$ chmod +x ${PATH%%:*}/git-hello
~$ git hello
hello
~$
--
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.
[git-users] Re: pre-pull hook?
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 doing and don't want checks first, then use fetch. During normal work, or for new people, use pull and let it check the basics for you. * It happens first, before the fetch. Did I forget about the 50 files I changed? I would rather get those committed/reverted/removed first. This is especially nice to new folks. A huge part of our project is written by students. The project is large and complex and requires considerable scientific and computing savvy. Most incoming students know only a little about either the specific science or the specific computing needed by the project. We need all the safety nets we can get. We all try not to break things, but we're all human. I wish I could show the source code that prompted this request. We keep it hidden because we're running full-tilt just to get things working, and there is no extra time to be certain we won't be opening ourselves to mischief if we open the sources. But, you can see the development version of the product here: dev.glycam.org Maybe one day we can open that code. See dev.glycam.org/cb to get a superficial idea of the scientific complexity involved. The rules for the chemical behaviors of those monosaccharide buttons are in the database. We do it that way so that the scientists can update the rules without having to learn Django/Python/C++/CSS/HTML/SVG/dot/etc. But, the coders might also update the table for a given monosaccharide. Those changes need to be able to be merged. We're using git (coupled with Django's 'fixtures' and UUIDs) to help us with that. But, git can't manage the data until they're in the repo. Some of the source is open: https://github.com/GLYCAM-Web - the 'dev-X' branches are the most up to date. Eventually, parts of that code will depend on and/or originate from database tables, or so we hope. Anyhow, thanks for listening and for all the comments. 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 - 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. " On Monday, October 1, 2018 at 11:21:01 AM UTC-4, B. Lachele Foley wrote: > > 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,
[git-users] Re: pre-pull hook?
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 git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
