Hi Rob!
I'm not a git expert by any stretch, but will take my best shot.
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.
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).
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.
On 1/29/21 2:27 AM, Robert Mackie via TriEmbed wrote:
Carl, (or anyone else)
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. :-)
Question 1:
How is a central git repo dramatically ifferent from a local repo?
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.
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".
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.
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.
Aha, and my remarks above suggest you know less about git than I
thought, but that's of course not at all true.
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.
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.
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.
Exactly
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.
What am I missing?
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!)
Question 2:
What horrible problems do you see happening with a single account for
all of many users? How
Only people problems, but you and your org at the Forge Initiative are
masters of those kinds of problems.
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.
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.
Right.
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.)
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.
So we leave things as wide open as we can.
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.
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.
-Pete
Rob.
On Wed, Jan 27, 2021, 12:36 PM Carl Nobile <[email protected]
<mailto:[email protected]>> wrote:
Robert,
I hate to say this but everybody working with the same account is
asking for trouble.
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.
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.
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.
~Carl
On Tue, Jan 26, 2021 at 5:55 PM Robert Mackie <[email protected]
<mailto:[email protected]>> wrote:
Hey Folks,
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.
I have 2 special cases - curious if you have any suggestions.
*Case 1)* 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.
So with a token on shared machines and shared accounts -*one
solution* - 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?
*Case 2)* 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.
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.
*Parting note:*
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.
Rob.
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)
On Tue, Jan 26, 2021 at 11:53 AM Carl Nobile via TriEmbed
<[email protected] <mailto:[email protected]>> wrote:
Sure,
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.
~Carl
On Tue, Jan 26, 2021 at 11:45 AM Pete Soper via TriEmbed
<[email protected] <mailto:[email protected]>> wrote:
Been a long time since I hooked up for working with a
GitHub repo (the
day MS bought them) and I just got a message saying
it's time to get
with the the token, SSH thing.
If anybody's interested I could take notes about how
to make this
transition, but it will be Linux-centric.
-Pete
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected]
<mailto:[email protected]>
List info:
http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
<http://mail.triembed.org/mailman/listinfo/triembed_triembed.org>
TriEmbed web site: http://TriEmbed.org
<http://TriEmbed.org>
To unsubscribe, click link and send a blank message:
mailto:[email protected]
<mailto:[email protected]>?subject=unsubscribe
--
-------------------------------------------------------------------------------
Carl J. Nobile (Software Engineer)
[email protected] <mailto:[email protected]>
-------------------------------------------------------------------------------
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected]
<mailto:[email protected]>
List info:
http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
<http://mail.triembed.org/mailman/listinfo/triembed_triembed.org>
TriEmbed web site: http://TriEmbed.org <http://TriEmbed.org>
To unsubscribe, click link and send a blank message:
mailto:[email protected]
<mailto:[email protected]>?subject=unsubscribe
--
-------------------------------------------------------------------------------
Carl J. Nobile (Software Engineer)
[email protected] <mailto:[email protected]>
-------------------------------------------------------------------------------
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected]
List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org
To unsubscribe, click link and send a blank message:
mailto:[email protected]?subject=unsubscribe
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected]
List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org
To unsubscribe, click link and send a blank message:
mailto:[email protected]?subject=unsubscribe
