You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you want the doc checked into the repo It would be great to have a git post-commit hook check to see if the doc needs to be re-built and if so build and commit the changes.
I'm suggesting a post-commit hook because then whatever commit you make stays whole and the commit narrative for the changes you just made aren't muddied-up by the commit changes in the doc files.
I'm looking at the glge code and considering working on i it and after cloning, changing the first line of build.js to look for node in all standard locations (my node is in /usr/local/bin);
#!/usr/bin/env node
and then after building successfully -- when I run git status it shows a long list of changes to doc files that are checked in and also a bunch that are not checked in. Unless I commit these into a branch they will show up whenever I am checking what need's to be committed.
But if I have a change and I develop it into a branch and push it to github for you to consider I don't want to include the doc changes (unless they're changes that occur because of my changes) those are your responsibility to decide when to include.
Here's what git status shows after a successful clone and build:
If you want the doc checked into the repo It would be great to have a git post-commit hook check to see if the doc needs to be re-built and if so build and commit the changes.
I'm suggesting a post-commit hook because then whatever commit you make stays whole and the commit narrative for the changes you just made aren't muddied-up by the commit changes in the doc files.
I'm looking at the glge code and considering working on i it and after cloning, changing the first line of build.js to look for node in all standard locations (my node is in /usr/local/bin);
and then after building successfully -- when I run git status it shows a long list of changes to doc files that are checked in and also a bunch that are not checked in. Unless I commit these into a branch they will show up whenever I am checking what need's to be committed.
But if I have a change and I develop it into a branch and push it to github for you to consider I don't want to include the doc changes (unless they're changes that occur because of my changes) those are your responsibility to decide when to include.
Here's what git status shows after a successful clone and build:
The text was updated successfully, but these errors were encountered: