4 ms·

The big thing missing here is a good way to do code reviews and CI/CD. This might not be important for a single user but if you're collaborating with someone it

by iveqy 6y ago

The big thing missing here is a good way to do code reviews and CI/CD. This might not be important for a single user but if you're collaborating with someone it can. For CI/CD you can get quite a long way with git hooks and for code review I would look into git appraise. that's the best one I've found but I would really like to hear if someone else has a better idea here!

krageon 6y ago
I wouldn't enjoy writing personal code without CI/CD if it grew beyond a few hundred lines. It's a lot more convenient to have a setup like that, to the point where I'd say it's essential.
tgragnato 6y ago
The old school way is to notify the ci/cd server using a post-receive hook. You can do it, but it’s not integrated in cgit, it must be set from the command line when you initialize the repo
- mnutt 6y ago
  You can automatically add hooks to new repositories using gitolite.
- aigoota 6y ago
  I still like this method, and I take advantage of pre-push, pre-commit hooks for dev tools like linters and scanners.
Wilya 6y ago
I used the exact same stack (gitolite+cgit) in the early stages of a previous startup, and code reviews were the big missing part that made us move to something more full featured (for us, gitlab). It's pretty easy to trigger ci runs via git hooks, and once you're used to it, checking their results in jenkins instead of in the git repository UI makes no difference. But code reviews really need a dedicated interface.
arminiusreturns 6y ago
I can second git hooks as a vastly underrated approach to automation. Lots of people who only use github don't know about them. Copy-pasta from an old comment of mine: "So, git hooks are basically executable scripts (of whatever language you have available, I use bash) placed in the .git/hooks dir, whcih are then executed at whichever event is designated (by the name of the script itself) For me, it's post-recieve. After initial setup, a push automatically triggers the post-recieve hook that does something like the following from my git dir: GIT_WORK_TREE=..../example.com git checkout -f and voila, pushes are insta-live, but commits can be pulled and worked on in the meantime. Learned from a few sources (shout out to Dreamhost for my original intro to this idea), but here are some relevant readings: https://www.ibm.com/developerworks/library/wa-git/ https://www.ibm.com/developerworks/library/wa-git/ https://opensource.com/life/16/8/how-construct-your-own-git- https://opensource.com/life/16/8/how-construct-your-own-git-... "

by iveqy 6y ago

krageon 6y ago

I wouldn't enjoy writing personal code without CI/CD if it grew beyond a few hundred lines. It's a lot more convenient to have a setup like that, to the point where I'd say it's essential.

tgragnato 6y ago

The old school way is to notify the ci/cd server using a post-receive hook. You can do it, but it’s not integrated in cgit, it must be set from the command line when you initialize the repo

mnutt 6y ago
You can automatically add hooks to new repositories using gitolite.
aigoota 6y ago
I still like this method, and I take advantage of pre-push, pre-commit hooks for dev tools like linters and scanners.

Wilya 6y ago

I used the exact same stack (gitolite+cgit) in the early stages of a previous startup, and code reviews were the big missing part that made us move to something more full featured (for us, gitlab). It's pretty easy to trigger ci runs via git hooks, and once you're used to it, checking their results in jenkins instead of in the git repository UI makes no difference. But code reviews really need a dedicated interface.

arminiusreturns 6y ago

I can second git hooks as a vastly underrated approach to automation. Lots of people who only use github don't know about them. Copy-pasta from an old comment of mine: "So, git hooks are basically executable scripts (of whatever language you have available, I use bash) placed in the .git/hooks dir, whcih are then executed at whichever event is designated (by the name of the script itself) For me, it's post-recieve. After initial setup, a push automatically triggers the post-recieve hook that does something like the following from my git dir: GIT_WORK_TREE=..../example.com git checkout -f and voila, pushes are insta-live, but commits can be pulled and worked on in the meantime. Learned from a few sources (shout out to Dreamhost for my original intro to this idea), but here are some relevant readings: https://www.ibm.com/developerworks/library/wa-git/ https://www.ibm.com/developerworks/library/wa-git/ https://opensource.com/life/16/8/how-construct-your-own-git- https://opensource.com/life/16/8/how-construct-your-own-git-... "