Livecode / Github

[Brian Milby]

I think some of this is a bit too much to address in a list post.  I'll
make some comments though.
(i) Make a repo at https://github.com;
https://www.atlassian.com/git/tutorials/setting-up-a-repository; you can
view tons of docs at https://docs.github.com/en
(ii)-(iv) I use https://www.sourcetreeapp.com (Mac and Win app available)
to manage my repos (many other options available). They also have other
tutorials at https://www.atlassian.com/git

When you create a GitHub repository currently, it will make a default
branch called "main".  Initially you would take your stack and commit
(really another word for "save") to the main branch.  If you had 2
developers that were working on the same stack at the same time, then one
way would be to have 2 branches off of main.  Let's say "brian" and "sean"
for example.  So each of us would check out our branch (initially the same
as main).  We would make any changes we needed and each would commit to our
own branch.  When whatever we are working on is ready to incorporate into
the product, we would merge our branch into the main branch.  Since
everything is text files (except for the images and other binary resources
like that), git can detect which pieces have changed and integrate them
together.  So instead of a zip going back and forth of the full project,
the individual changes would be tracked and integrated.  The biggest
difference is that multiple developers can work on the same stack at the
same time and have their changes integrated together.

The down side that I do see with this implementation is that it is
difficult to know what object is being changed.  Since everything is stored
by GUID it can be hard to know what is being updated by looking at the
commit logs.  Due to the Mac CR issue, I probably won't be able to do much
for demonstrating how it works until there is a good workaround (I guess I
could manually convert the JSON each time for now).  I did fix the JSON
file on my ScriptTracker repo so it could be viewed on GitHub.  I need to
make a change to a script that hasn't been fixed to see how it shows up.
The JSON fix showed pretty much as a whole new file (line 1 was updated to
lines 1-1000+).

My approach with ScriptTracker is a bit different.  First is that my tool
is much more limited (just does the scripts).  But, my tool adds a bit of
information to the header of each exported script to give it context and
the scripts are named by the object ID (mainly to avoid issues with illegal
characters in the object name).  It might be something that could be done
with plugins to add some info to the JSON and script files.  I'll need to
take a look - it would make working with the scripts easier.  For the JSON,
I think it may be helpful to have full object names included with the GUID
so you have more of an idea what was changed when looking at the diff.

Also, if you just want to track your changes (and not work with another dev
to merge), it does get a bit easier.  Then you don't even need to use a
server (GitHub) but can run git completely on your seat.  The same GUI
tools mentioned above can be used there as well.

Command line tools are there but not required.  As I mentioned above, I use
a GUI for just about all of my git usage.  They make it easy to see what
happened and when.

Hopefully this helps a little.  I think there are a couple of videos from
conferences over the past few years covering Git.  I know that there is at
least one that I did (but it was targeted at building LC from source).

Thanks,
Brian

On Thu, Sep 1, 2022 at 5:39 PM Pi Digital via use-livecode <
use-livecode at lists.runrev.com> wrote:

> Fab :D
>
> however, ‘how’ does one…
>  (i) set up a GitHub (I know how, this is for the benefit of others),
> (ii) perform commits, push, pulls (perhaps using LC and having an LC
> library/widget for this would be best),
> (iii) merge to a branch,
> (iv) switch branches
> All the while making it simple for even the most beginner of beginners to
> understand, like everything else in LC *Should be?
>
> It’s like giving us the front door but the hallway floor is missing.
>
> There is no guide on real world usage so we are left stranded with it.
>
> Here’s the actual situation myself and my colleague face. At the moment
> one of us works on the app, makes some changes, zips it up, and posts it up
> to a server. Then the other does the same ad infinitum.
>
> But what you have described is not much different. How can we really tell
> who made changes unless we know the uid for the script or card (for layout)
> or object? And are we all supposed to now become command line experts to
> manage an svc? I’m puzzled at the moment.
>
> It shows great promise, but it’s still not fully ready, is it. It’s
> usable, like LCB, if you can do lower level stuff. But not many using LC
> are able, hence why they use LC. Everything LC, and I mean everything, that
> is front end for LC users *Should, note, Should be High Level and easy to
> code & understand. The plug-in language for SmartCrumbs is dreamy. Thank
> you whoever came up with that. I love it! LCB is a nightmare and could have
> been done so much better - much more in line with the HyperCard principle.
>
> Sean Cole
> Pi
>
>