<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Rob!</p>
<p>I'm not a git expert by any stretch, but will take my best shot.</p>
<p>First, in my humble opinion a bunch of kids sharing a repo is no
big deal. I would venture to guess it's going on all over the
planet as I type this. Not every repository has to be treated as
if it contains the secret of the temple. An if the central repo
gets turned into guacamole, just push a backup copy and get on
with your lives.<br>
</p>
<p>They will be either having or sharing GitHub accounts, however.
You may recall when I was teaching Ben we could not use GitHub
'cause their terms and conditions did not allow for account usage
by a 10 year old (minimum is 13. CAVEAT: I have not read the terms
and conditions since MS bought GitHub and only use GitHub when a
client dictates its use). <br>
</p>
<p>So Bitbucket might be a better choice, and it offers the option
of the repo being private and that might be useful to minimize the
chance of somebody giving a bad actor access to the repo and
causing chaos. Private effectively just means it isn't visible to
the world, not that it has to be limited to some number of users.
But with bitbucket a public repo still has read, write, and
read/write controls configurable for every user. I can give you
direct assist with Bitbucket if you need it. But I'm not familiar
with mutating a bitbucket repo "online", that is except via a
"push" from a local clone. We'd be learning about that together if
it's supported.<br>
</p>
<div class="moz-cite-prefix">On 1/29/21 2:27 AM, Robert Mackie via
TriEmbed wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAQbUTLm_43xKYZh0Gw2N_rqPWOg-GUXkXoBSXYNPfdPrsNjcQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">Carl, (or anyone else)
<div dir="auto"><br>
</div>
<div dir="auto">Here i go. I'm going to risk sounding like a
wild eyed crazy guy. But if I can get good suggestions, it's
worth it. :-)<br>
<div dir="auto"><br>
</div>
<div dir="auto">Question 1:<br>
<div dir="auto"><br>
</div>
<div dir="auto">How is a central git repo dramatically
ifferent from a local repo? <br>
</div>
</div>
</div>
</div>
</blockquote>
A local repo is typically just a clone of a central repo. The flow
for a large fraction of developers is 1) make a clone of the
web-based repo on a local PC, modify some file, use "git add" and
"git commit" and "git push" to put the modification back into the
web-based repo, with the understanding that you cannot do that if
other changes to the web-based repo conflict with your push. So the
cautious flow is to do a "git pull" immediately before applying your
changes (doing any "merges" into the files with newer changes than
yours) before the add/commit/push.<br>
<blockquote type="cite"
cite="mid:CAAQbUTLm_43xKYZh0Gw2N_rqPWOg-GUXkXoBSXYNPfdPrsNjcQ@mail.gmail.com">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">I'm guessing a lot has happened in the world
of git that I've been priveledged to ignore, while using
git as a simple "client".</div>
<div dir="auto"><br>
</div>
<div dir="auto">What I remember is that i was using
bitkeeper for one of the repositories my development group
had inherited during an acquisition at the time that linus
torvolds and the owner of bitkeeper decided to separate
linux from bitkeeper. Are the time it seemed acrimonious
although to hear it now it was something that they
mutually agreed to.</div>
<div dir="auto"><br>
</div>
<div dir="auto">So I started using git when it was still
just a set of quick scripts that linus "had thrown
together over the weekend". It clearly inherited a lot of
good it worked from bitkeeper. There are some differences
because bitkeeper was for profit and git was to support
distributed opensource development.</div>
</div>
</div>
</div>
</blockquote>
Aha, and my remarks above suggest you know less about git than I
thought, but that's of course not at all true.<br>
<blockquote type="cite"
cite="mid:CAAQbUTLm_43xKYZh0Gw2N_rqPWOg-GUXkXoBSXYNPfdPrsNjcQ@mail.gmail.com">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">At that time one of the explicit goals of
git was to ensure that no one repo or repo manager could
ever "own" the source history of a project. The goal was
that if a repo was closed, or locked or "taken over" -
then any other repo could become the central repository as
long as all the "clients" (i.e. local repository holders)
decided to reconfigure their "parent" to that alternate
repo. at the time it seemed (in the press) that linus was
unhappy with the idea that the holder of a singal repo
could hold the history of the Linux change control hostage
to a personal agenda. But saying that's what the owner of
bitkeeper did. It's just that what he wanted to do made it
clear that it was a possibility that someone might someday
do that.</div>
</div>
</div>
</div>
</blockquote>
From my memory the owner of bitkeeper didn't do any hostage-taking
as much as forbid the ripping off of his IP by some mono developer
if I recall correctly. So git was created to escape from a
stalemate. The bitkeeper guy was the author of Sun's RCS and was
definitely not a monster.<br>
<blockquote type="cite"
cite="mid:CAAQbUTLm_43xKYZh0Gw2N_rqPWOg-GUXkXoBSXYNPfdPrsNjcQ@mail.gmail.com">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">And my experience with git is that i can
point at pretty much any repo as the upstream source,
whether it's one on the same hard drive, one on another
computer in my office, or one hosted on the cloud. <br>
</div>
</div>
</div>
</div>
</blockquote>
Exactly<br>
<blockquote type="cite"
cite="mid:CAAQbUTLm_43xKYZh0Gw2N_rqPWOg-GUXkXoBSXYNPfdPrsNjcQ@mail.gmail.com">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">What all am I missing about a central
server? I don't doubt that I'm missing things, i just
don't know what? I can imagine the "central server" should
be backed up, but every time it's fully cloned that
happens. And if there are other records, then a standard
disk backup would do. I can imagine that if it gets enough
traffic, there might be some questions of scale, (load
balancing, atomicity, etc) but I'm not to talking about
thousands of users but rather 10s or at most a couple of
hundred occasional users.</div>
<div dir="auto"><br>
</div>
<div dir="auto">What am I missing?</div>
</div>
</div>
</div>
</blockquote>
Nothing significant. But I'm probably missing some of this. In
typical fashion I barely skimmed the earlier traffic about this.
Apologies if that creates a big impedance mismatch (high SWR can
lead to high voltage swings, sometimes causing "RF burns", ha!)<br>
<blockquote type="cite"
cite="mid:CAAQbUTLm_43xKYZh0Gw2N_rqPWOg-GUXkXoBSXYNPfdPrsNjcQ@mail.gmail.com">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">Question 2:</div>
<div dir="auto">What horrible problems do you see happening
with a single account for all of many users? How </div>
</div>
</div>
</div>
</blockquote>
Only people problems, but you and your org at the Forge Initiative
are masters of those kinds of problems.<br>
<blockquote type="cite"
cite="mid:CAAQbUTLm_43xKYZh0Gw2N_rqPWOg-GUXkXoBSXYNPfdPrsNjcQ@mail.gmail.com">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div dir="auto">would you address it? (Approach not
staffing) Keep in mind you are addressing a small
nonprofit with a very limited budget, a need to give
almost every user admin (or some equivalent to sudo) so
they can install software and experiment and even ruin an
OS install and then learn to rebuild it, and that pretty
much all the computers are 5 or more years out of date and
heterogenous makes and models because all are donated as
cast offs.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Also, it is easier to wipe them and start
over, than to worry about keeping them clean, and that we
have had very few problems with wild "sw virus plagues"
over the last decade, because people use these computers
to get things done, not to browser random websites.</div>
</div>
</div>
</div>
</blockquote>
Right.<br>
<blockquote type="cite"
cite="mid:CAAQbUTLm_43xKYZh0Gw2N_rqPWOg-GUXkXoBSXYNPfdPrsNjcQ@mail.gmail.com">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">There is not disk space on each laptop for a
personal account for every member of the organization. It
is not reasonable to dedicate specific computers to
specific people. We might be able to set up active
directory (or the like) and have people use an account and
home directory) on a server, but then we need a reliable
and accessible server. However, these computers often
leave the site to be used for outreach, often while
training brand new people who would not yet be in the
directory and in locations where the computer would not
be able to reach the directory server. (Often used when
wifi or ethernet not available.)</div>
<div dir="auto"><br>
</div>
<div dir="auto">So I'm curious - what do you think will go
wrong and how would you solve it? I'd love a creative
effective approach that addresses our odd requirement set.
The requirements are a result of working really really
hard to eliminate perceived obstacles to trying something
technical. Our efforts are aimed at getting people who
aren't even sure they should consider that they might
someday become technical to try something that is far
outside their comfort zone. So each delay of access, each
complexity of access, each extra step adds to the
likelihood that the people we are addressing will decide
that their first impression was correct - tech is not for
them. We want to avoid that.</div>
<div dir="auto"><br>
</div>
<div dir="auto">So we leave things as wide open as we can.</div>
<div dir="auto"><br>
</div>
<div dir="auto">So again - if you have creative solutions
that will help us make this more accessible, and easier to
manage - I'd really love to hear what you suggest. Our
requirements are so different from an office, or a school,
or a government, or even the part of our organization that
runs it as a business that most ideas I've heard are cures
worse than the problem in terms of lowerng perceived
barriers. Just saying "people should get over it and do it
right", which I've heard a lot - well we can do that, but
a lot of people with a lot of potential will just walk
away - their self story will be "tech is too hard" before
they find out how much they can love it, and well they can
learn it.</div>
</div>
</div>
</div>
</blockquote>
<p>I can't offer a creative solution as much as suggesting that a
single Bitbucket repo fully accessible by a finite group seems
like a good fit for kids that might be younger than 13 and I'm
100% with you as far as unfettered access by anybody put "on the
list" for that repo. We can connect and work through the how-to
with Google Hangouts if I haven't missed the boat with this.<br>
</p>
<p>-Pete<br>
</p>
<blockquote type="cite"
cite="mid:CAAQbUTLm_43xKYZh0Gw2N_rqPWOg-GUXkXoBSXYNPfdPrsNjcQ@mail.gmail.com">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div dir="auto"><br>
</div>
<div dir="auto">Rob.</div>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Jan 27, 2021, 12:36 PM
Carl Nobile <<a href="mailto:carl.nobile@gmail.com"
moz-do-not-send="true">carl.nobile@gmail.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Robert,
<div><br>
</div>
<div>I hate to say this but everybody working with the same
account is asking for trouble.</div>
<div>The reason why I'm the only one to respond, at least
with respond all, is because there is no better solution
but to have separate accounts.</div>
<div>I understand that you have no admin to seemingly solve
the issue for you, but that's the issue to solve not to
get around it by trying to solve the myriad of problems
having only one account will cause.</div>
<div><br>
</div>
<div>If you really can't solve the single account problem
then yes definitely set up a local git repo, but that will
take the talents of somebody that really knows how git
works. A central git repo is NOT set up like the one you
have locally in your working environment, it may need that
elusive admin for setting up.</div>
<div><br>
</div>
<div>~Carl</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jan 26, 2021 at
5:55 PM Robert Mackie <<a href="mailto:rob@mackies.org"
target="_blank" rel="noreferrer" moz-do-not-send="true">rob@mackies.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hey Folks,
<div><br>
</div>
<div>Could use some insights from you. My normal case -
on a computer I own, or work at regularly and am the
only user of, or on an account i own and am the only
user of (home or work), it seems like tokens won't be
a problem. In fact, they may make things even easier,
day-to-day.</div>
<div><br>
</div>
<div>I have 2 special cases - curious if you have any
suggestions. </div>
<div><br>
</div>
<div><b>Case 1)</b> I coach an FRC team. Everyone on the
team uses shared laptops with shared login. We don't
have an IT staff to keep a login on each machine for
each member of the team on each laptop or computer. So
any suggestion that requires doing that isn't worth
putting out there. With passwords it was easy. Anyone
could clone a repo, do work, push the work, and delete
the repo - all they needed was their password - oh
another aside, some of the students aren't at all sure
they even want to learn to code so we want to keep the
obstacles level as low as possible. requiring lots of
expertise to access the code isn't really useful. Many
of them have never used a command line, and the
interest in doing so is still far in their future.<br>
<br>
So with a token on shared machines and shared accounts
-<b> one solution</b> - everyone uses the same token
and the same accounts. No one has a clue who put what
code in the repo because the push always comes from
that account. Any better solutions?<br>
<br>
<b>Case 2)</b> For me 0 I often find that I am in a
situation where I'm on a machine that is not "my own
machine" and may be on an account that is "not my
account". Having non-confidential projects where they
can be pulled in quickly is handy. I have open repos
on github where confidentiality isn't an issue and can
just clone a repo, so some work and push the work, and
delete the local repo. if i forget to delete the local
repo - no harm to me - they don't have my password,
and the harm to them is just the need to delete a
directory full of junk (whoever "them" is) and if
they do push some junk to my repo, given the repo IS
version control - it would be generally pretty easy to
undo the mess unless they were very nefarious.</div>
<div><br>
What is the easiest way to make a "token" portable
(usb thumb?) and make sure it is never left behind on
a machine that I don't control? It feels like losing
control of the token is a bad thing.</div>
<div><br>
</div>
<div><b>Parting note:</b></div>
<div>I have to admit that I haven't taken the time to
look and see if there are easy solutions. I'm hoping
to get a free ride here on someone else's brilliance.
So feel free to tell me my cases are "too special" and
go fish on my own. :-) But if you have any
suggestions, I'm interested.</div>
<div><br>
</div>
<div>Rob.</div>
<div>PS: I've seriously thought about just setting up a
non github git repo in the cloud to solve some of
these problems, but there are downsides to that as
well. There is value to getting these students on
github and aware of how all of that works. and Github
has some nice features beyond simple git, and is
publicly findable. (and someone else maintains it)</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jan 26, 2021
at 11:53 AM Carl Nobile via TriEmbed <<a
href="mailto:triembed@triembed.org" target="_blank"
rel="noreferrer" moz-do-not-send="true">triembed@triembed.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px
0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Sure,
<div><br>
</div>
<div>I already described in one of my
previous tutorials how to actually get the token,
but not how to use it for normal SSH access.</div>
<div><br>
</div>
<div>~Carl</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jan 26,
2021 at 11:45 AM Pete Soper via TriEmbed <<a
href="mailto:triembed@triembed.org"
target="_blank" rel="noreferrer"
moz-do-not-send="true">triembed@triembed.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">Been a long
time since I hooked up for working with a GitHub
repo (the <br>
day MS bought them) and I just got a message
saying it's time to get <br>
with the the token, SSH thing.<br>
<br>
If anybody's interested I could take notes about
how to make this <br>
transition, but it will be Linux-centric.<br>
<br>
-Pete<br>
<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"
moz-do-not-send="true">TriEmbed@triembed.org</a><br>
List info: <a
href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://mail.triembed.org/mailman/listinfo/triembed_triembed.org</a><br>
TriEmbed web site: <a href="http://TriEmbed.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true">unsubscribe-TriEmbed@bitser.net</a>?subject=unsubscribe<br>
<br>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">-------------------------------------------------------------------------------<br>
Carl J. Nobile (Software Engineer)<br>
<a href="mailto:carl.nobile@gmail.com"
target="_blank" rel="noreferrer"
moz-do-not-send="true">carl.nobile@gmail.com</a><br>
-------------------------------------------------------------------------------</div>
_______________________________________________<br>
Triangle, NC Embedded Computing mailing list<br>
<br>
To post message: <a
href="mailto:TriEmbed@triembed.org" target="_blank"
rel="noreferrer" moz-do-not-send="true">TriEmbed@triembed.org</a><br>
List info: <a
href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">http://mail.triembed.org/mailman/listinfo/triembed_triembed.org</a><br>
TriEmbed web site: <a href="http://TriEmbed.org"
rel="noreferrer noreferrer" target="_blank"
moz-do-not-send="true">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"
moz-do-not-send="true">unsubscribe-TriEmbed@bitser.net</a>?subject=unsubscribe<br>
<br>
</blockquote>
</div>
</blockquote>
</div>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">-------------------------------------------------------------------------------<br>
Carl J. Nobile (Software Engineer)<br>
<a href="mailto:carl.nobile@gmail.com" target="_blank"
rel="noreferrer" moz-do-not-send="true">carl.nobile@gmail.com</a><br>
-------------------------------------------------------------------------------</div>
</blockquote>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: <a class="moz-txt-link-abbreviated" href="mailto:TriEmbed@triembed.org">TriEmbed@triembed.org</a>
List info: <a class="moz-txt-link-freetext" href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org">http://mail.triembed.org/mailman/listinfo/triembed_triembed.org</a>
TriEmbed web site: <a class="moz-txt-link-freetext" href="http://TriEmbed.org">http://TriEmbed.org</a>
To unsubscribe, click link and send a blank message: <a class="moz-txt-link-freetext" href="mailto:unsubscribe-TriEmbed@bitser.net?subject=unsubscribe">mailto:unsubscribe-TriEmbed@bitser.net?subject=unsubscribe</a>
</pre>
</blockquote>
</body>
</html>