Forking Versions

Mike Kerner MikeKerner at roadrunner.com
Fri Oct 9 22:49:56 EDT 2015


So checkout is the same as syncing?
It's the details that make any system more difficult.  For instance, when
you want to merge a change into the main, you do a pull, even though from
your perspective you're pushing.  In the case of LC, you have to pull the
entire project, even if all you're really interested in is one piece of
it.  You fork a project even if you're not really doing anything to it.  It
would seem that you aren't really forking anything until you make a change
to it, but you have a fork nonetheless.  The graphs just make it look even
worse.

I'm sure I'll get the hang of it, but every time I look at it, I just want
to say "screw it, here's a bug report with the code I tweaked".

On Fri, Oct 9, 2015 at 5:14 PM, Monte Goulding <monte at sweattechnologies.com>
wrote:

>
> > On 10 Oct 2015, at 2:51 am, Richard Gaskin <ambassador at fourthworld.com>
> wrote:
> >
> > Github is simple - if what you're building is the Linux kernel, which is
> what it was designed for. ;)
>
> Actually the hardcore guys don’t use GitHub… they have a mailing list and
> pass around patch files which git can also generate. GitHub is just a web
> app built on git… A very helpful web app but there you go. There’s others
> like BitBucket, GitLab etc. You can also just put a bare repo somewhere you
> can access and use that as a remote without any web UI. Lots of
> possibilities.
>
> It’s really not all that complicated but it is well worth reading at least
> the first 3 chapters of the git book https://git-scm.com/book/en/v2 <
> https://git-scm.com/book/en/v2>
>
> The basic idea of distributed SCM is everyone has the source but nobody
> has anybody's changes unless they get them. To get them you need to point
> your repo to theirs (remote) and pull (pull means fetch and merge).
>
> Branches sound complicated too but they aren’t. All they are is a pointer
> to a commit. There’s a file in the .git directory for each branch that just
> contains a reference to a commit (a 1 line sha1 hash) that’s it. Each
> commit also has a pointer to its parent commit and that’s how you end up
> with a tree. A merge is just a commit with both a mum and a dad ;-)
>
> Checkout is just making your file tree the same as it was at a particular
> commit. Remember branches are just pointers to commits.
>
> Cheers
>
> Monte
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



-- 
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."



More information about the use-livecode mailing list