3 ms·
I already live by the dogma that my local machine is the lone input into master on the remote server of my Gitlab instance. And that remote master never inputs
by jancsika 8y ago
I already live by the dogma that my local machine is the lone input into master on the remote server of my Gitlab instance. And that remote master never inputs into my local copy of the repo.
What better UX is awaiting me and my new developers by taking an email-based approach?
Edit: clarification
- BurritoAlPastor 8y agoYou have a push-only workflow, and 100% of commits are made on your local? Frankly, I’m not sure what you’re even using Gitlab for in this setup; it seems like you might as well just rsync your working directory to your remote server instead, since you don’t have to approve, merge, or reconcile commits from other sources. There’s nothing distributed about your version control needs.
- jancsika 8y agoNo-- I'll fetch branches from other devs, inspect them, merge them locally, then push to remote. But that all happens on my local machine. I use the Gitlab UI for issues, creating merge requests and discussing them with other devs, etc. That centralized Gitlab instance provides a lot of value for me. If there were a method of leveraging something close to the Gitlab UX with a decentralized or even federated design underneath, I'd use that. But this article reads like it's saying, "Give up that value and use this less convenient flow in order to protect against an unlikely class of attack."
- ozim 8y agoUX none and for most proprietary projects central repo is what is needed. Hippie utopia where people publish or send changes by email to mailing list their code fixes for software they are using themselves, sharing all code, all free (not necessarily as free beer but free and reviewable). Software improvements where you can not accept some feature sent to mailing list only for your own pleasure or own decision, in contrast to SaaS where changes or "features" for software are pushed down your throat. World where everyone is his own software developer deciding exactly what codes of line his hardware is executing. I don't mean to be derogatory with 'hippie utopia', but that view is really attractive. Though in reality I don't have time to review and merge changes for all software I am using, I would have to have life span of 1000 years probably just to do it, so I understand that is not very practical.