<div dir="auto">Thank you to *everyone* for taking the time to answer. I probably should have been clearer. I have been using git since it was released both professionally and personally and was one of the 2 "config meister's" on a development team for a quite a while (but 5 years ago). Have experience with several other version and configuration management tools as well (both home grown at employers and commercial including some years managing my teams' use of clearcase at 2 different companies)<div dir="auto"><br></div><div dir="auto">Also the problem space as Pete pointed out is bigger than just one FRC team.  Although The Forge Initiative membership has contacted with covid, we still have multiple members of each of about 100 families engaged in exploring tech - many of whom will eventually at least touch some software development activity. This year we only have 12 FIRST teams in house compared to the 25 we had last year. (1 FRC, 4 FTC, and the rest are various leagues of FLL) if you've used ev3hub for FLL, it was developed by one of our members Alan Smith.)</div><div dir="auto"><br></div><div dir="auto">Our members' practiced core values mean that we are seldom concerned with bad actors, but often want to be able to connect someone who made a mistake with a peer or near peer who can help them understand what happened.</div><div dir="auto"><br></div><div dir="auto">I see some useful to us suggested solutions for our approach and am really grateful for them. (We have talked with other FRC teams - this is generally not on their radar yet or they operate differently than we do - scale, resources, intent, etc. There is room for lots of variation in FRC and FTC. Also the FIRST Senior Mentor for NC is a member a is the head referee for FTC in NC.  I think reaching out to FIRST at the national level makes sense and will do that. Have been watching the forums for comments on this problem for months.</div><div dir="auto"><br></div><div dir="auto"><b>bitbucket</b> seems like a reasonable alternative. We do like all the code to be visible to the whole world. In FRC that provides some competitive advantages. We do want to restrict push access to team members, and associate identity with each commit. Looks like we can do that with bitbucket. I'll read more.</div><div dir="auto"><br></div><div dir="auto"><b>Tokens</b> in the command line - this is really really close. On the FRC team we commit and push from vscode. We use 2 plug-ins. A standard git plugin that assumes your credentials are in the windows credential manager, or that the identity is in git global or git local and then prompts for password on push if needed. The second plugin is home brew and makes it easy for a student to select their name and end up with their identity in the local gut config for their repository. We might be able to enhance one or the other to work with tokens. Again, our problem is seldom bad actors and often "accessible to someone who already thinks it's very complicated". It would be easy to simply ask every uaer to know their token. I'm not sure how well it will work in practice.</div><div dir="auto"><b>Still this is really good information.</b> We may be able to make use of.</div><div dir="auto"><br></div><div dir="auto"><b>Setting up our own repo</b> - I'm glad to hear that it isn't anymore complex that I thought it was. I don't think I'd set up a "server" so much as home it in the cloud - Amazon or the like  It isn't my favorite solution. the reasons are that the web access that we get from GitHub or would get from bitbucket removes yet another obstacle to those who aren't quite sure they want to code but might want to look at the code. That is always the criteria - inviting the unsure to give to at least peek or try.</div><div dir="auto"><br></div><div dir="auto">So once again thank you so much for the input all of the other suggestions are interesting and useful but may not directly address what we need for this problem.</div><div dir="auto"><br></div><div dir="auto">Here's an interesting side note on developing what I think of as "extreme volunteer engagement". We have lots and lots of volunteers who will spend lots and lots of time on our organization's activities. The main reason for that being so is because we emphasize finding tasks that each volunteer is very excited to do. Often suggested by the volunteer themselves. This means that we may not have a single volunteer interested in setting up how people log into our systems. That sounds like drudge work you do at work to most people who know how. However we have volunteers who will spend hours and hours or even weeks writing a custom plugin because it's something no one will let them do at work and they've  really want to do.</div><div dir="auto"><br></div><div dir="auto">We're not very good at volun-told. We almost always make room for solutions where someone "found a place in the community, connected and got to know the team, asked how their idea would fit, prototyped the idea engaging others and getting feedback along the way, especially if others can learn by following along or contributing." Lol sounds complicated, but an amazing number of people enjoy it and get amazing things done.</div><div dir="auto"><br></div><div dir="auto">All of that changes the kinds of solutions that work for our organization. Aspects of that may change as we grow and develop staff etc. But right now that approach drives/shapes/cripples/biases/empowers our solutions. :-)</div><div dir="auto"><br></div><div dir="auto">Rob</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 29, 2021, 12:03 PM Jon Wolfe via TriEmbed <<a href="mailto:triembed@triembed.org">triembed@triembed.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="#954F72" style="word-wrap:break-word"><div class="m_5773812096459434012WordSection1"><p class="MsoNormal">On Windows, you can also configure git to use Window’s built-in credential management system so that you do not have to type in user/pass to do git operations. I think this mechanism will still work using tokens, but I have not tried it yet, despite GitHub already nagging me about it for the past few months. I’d bet money you can do that same thing on Linux/Mac, but on those platforms, I’ve used front ends for git that I think do that for me.</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I’m in the opposite boat, I’m a single individual with many git accounts in use on the same machine. I have to setup git so that uses “user/pass 1” for “repo A” and “user/pass 2” for “repo B”. Not only that, but some of my local repo’s have multiple remotes. This GitHub change is sure to be a PITA for me for years to come. I understand their rationale behind it, but when someone gets hacked, it’s going to be because they clicked on a phishing email and that the one thing that is still going to allow a username /password combination. One nice thing about user/pass authentication is that you can embed the user/pass into the url itself for https git operations. That’s not something you would want to do for a “production” workflow, for for one-off things with git, it saves a ton of hassle and setup for something you going to do one time. </p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Setting up your own git central repo isn’t hard, the hardest part is getting the machine itself up and running to host it. I use software called “gitblit” that’s a java-based git server and website interface, that has low system requirements (beyond java), and works on Windows/Linux servers, and works on older machines too. It’s got a lot of GitHub/bitbucket – like features, and it very simple to install/setup.</p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><u></u> <u></u></p><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal" style="border:none;padding:0in"><b>From: </b><a href="mailto:triembed@triembed.org" target="_blank" rel="noreferrer">Pete Soper via TriEmbed</a><br><b>Sent: </b>Friday, January 29, 2021 11:24 AM<br><b>To: </b><a href="mailto:triembed@triembed.org" target="_blank" rel="noreferrer">triembed@triembed.org</a><br><b>Subject: </b>Re: [TriEmbed] GitHub heads up: password logins go away August 13th</p></div><p class="MsoNormal"><u></u> <u></u></p></div></div>Sorry to be a chatter box.<br><br>With Bitbucket you just put your credentials into the local .git/config <br>after defining the global git username and email address. I'm 98% sure <br>if you set up ssh keys for a particular local PC you can bypass having <br>to enter a password to do a push but I'm too lazy/stupid to do that. I <br>just flirt with carpal tunnel and trust my fingers to type the password <br>with close to zero effort.<br><br>-Pete<br><br><br>_______________________________________________<br>Triangle, NC Embedded Computing mailing list<br><br>To post message: <a href="mailto:TriEmbed@triembed.org" target="_blank" rel="noreferrer">TriEmbed@triembed.org</a><br>List info: <a href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org" target="_blank" rel="noreferrer">http://mail.triembed.org/mailman/listinfo/triembed_triembed.org</a><br>TriEmbed web site: <a href="http://TriEmbed.org" target="_blank" rel="noreferrer">http://TriEmbed.org</a><br>To unsubscribe, click link and send a blank message: mailto:<a href="mailto:unsubscribe-TriEmbed@bitser.net" target="_blank" rel="noreferrer">unsubscribe-TriEmbed@bitser.net</a>?subject=unsubscribe<br><br>
_______________________________________________<br>
Triangle, NC Embedded Computing mailing list<br>
<br>
To post message: <a href="mailto:TriEmbed@triembed.org" target="_blank" rel="noreferrer">TriEmbed@triembed.org</a><br>
List info: <a href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org" rel="noreferrer noreferrer" target="_blank">http://mail.triembed.org/mailman/listinfo/triembed_triembed.org</a><br>
TriEmbed web site: <a href="http://TriEmbed.org" rel="noreferrer noreferrer" target="_blank">http://TriEmbed.org</a><br>
To unsubscribe, click link and send a blank message: mailto:<a href="mailto:unsubscribe-TriEmbed@bitser.net" target="_blank" rel="noreferrer">unsubscribe-TriEmbed@bitser.net</a>?subject=unsubscribe<br>
<br>
</blockquote></div>