Re: Forking Versions

[Monte Goulding]

git will throw an error if you try to push and your commits aren't ancestors of 
the head of the branch you are pushing. You can get around this by force 
pushing but don't do that... Nasty... I don't even know why git allows it.

Sent from my iPhone

> On 10 Oct 2015, at 4:57 pm, Mark Wieder  wrote:
> 
> That way if anyone has pushed anything to the common repository before your 
> latest pull from it, you have a chance to get the latest changes locally, 
> make sure there aren't any conflicts, and only then is it safe to push your 
> changes up.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Forking Versions

[Mike Kerner]

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 
wrote:

>
> > On 10 Oct 2015, at 2:51 am, Richard Gaskin 
> 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@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."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Forking Versions

[Monte Goulding]

> On 10 Oct 2015, at 2:51 am, Richard Gaskin  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 


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@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Forking Versions

[Mark Wieder]

On 10/09/2015 07:49 PM, Mike Kerner wrote:


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.


No, it's just better to pull before pushing.
That way if anyone has pushed anything to the common repository before 
your latest pull from it, you have a chance to get the latest changes 
locally, make sure there aren't any conflicts, and only then is it safe 
to push your changes up.


--
 Mark Wieder
 ahsoftw...@gmail.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Forking Versions

[Monte Goulding]

> So checkout is the same as syncing?

Hmm… checkout is just getting setting the state of all the files in the repo to 
the state they were in when you committed. It’s a local operation.

> 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.  

How are you pushing? Push is upload to server while pull & fetch are 
downloading. As I said before pull is just fetch and merge combined into one 
command for convenience. Fetch just downloads any commits and branch references 
you don’t have locally.

> 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.

Once you have cloned the repo when you pull you just get updates not everything 
again.

>  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.

You don’t have to do that. You could just clone their repo instead of forking 
on github and cloning your fork if you don’t want to contribute anything…

> 
> 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".

Read those first three chapters of the git book I recommended and it will 
become much clearer.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Forking Versions

[Richard Gaskin]

Github is simple - if what you're building is the Linux kernel, which is 
what it was designed for. ;)


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


Mike Kerner wrote:


wow, what a pain.

On Thu, Oct 8, 2015 at 5:55 PM, Monte Goulding 
wrote:


Oh, you also need to add the official repo as a remote on your fork:

git remote add upstream https://github.com/livecode/livecode.git <
https://github.com/livecode/livecode.git>

This adds the official repo as a remote named upstream which is the normal
name of the original repo when you have a fork. Your fork is called origin.
What you want to do is pull the changes from upstream (the company repo),
make commits and push them to origin (your fork). If you have anything to
contribute you can then send a pull request which is basically a request
for them to merge in the changes on a branch on your fork into the official
repo.

Now that you have added upstream as a remote you want to set the upstream
of each of the official branches that you have checked out. Say you have
checked out develop (livecode 8) then you want to do this:

git branch --set-upstream develop upstream/develop

This means that when you checkout develop and pull it will automatically
pull from the upstream remote (the company repo) rather than your origin
remote (your fork).

Anyway I hope that helps ;-)

> On 9 Oct 2015, at 5:55 am, Mike Kerner 
wrote:
>
> 1) In Git, if I have a fork, but then there are updates to the master
> branch, and I want to take those and replace at least some of the
contents
> in my fork, do I have to create a new fork and download the entire
project,
> again?  That seems like it would screw up the things I've been working on
> in my fork, and mean that I would have to manually re-integrated the
things
> I'm doing in the files I'm working on.
>
> 2) I've been messing around with various widgets, but I'm not messing
with
> the engine, but there does not seem to be a way to fork part of the
project
> without forking all of it.
>
> --
> 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."


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Forking Versions

[Mike Kerner]

wow, what a pain.

On Thu, Oct 8, 2015 at 5:55 PM, Monte Goulding 
wrote:

> Oh, you also need to add the official repo as a remote on your fork:
>
> git remote add upstream https://github.com/livecode/livecode.git <
> https://github.com/livecode/livecode.git>
>
> This adds the official repo as a remote named upstream which is the normal
> name of the original repo when you have a fork. Your fork is called origin.
> What you want to do is pull the changes from upstream (the company repo),
> make commits and push them to origin (your fork). If you have anything to
> contribute you can then send a pull request which is basically a request
> for them to merge in the changes on a branch on your fork into the official
> repo.
>
> Now that you have added upstream as a remote you want to set the upstream
> of each of the official branches that you have checked out. Say you have
> checked out develop (livecode 8) then you want to do this:
>
> git branch --set-upstream develop upstream/develop
>
> This means that when you checkout develop and pull it will automatically
> pull from the upstream remote (the company repo) rather than your origin
> remote (your fork).
>
> Anyway I hope that helps ;-)
>
> > On 9 Oct 2015, at 5:55 am, Mike Kerner 
> wrote:
> >
> > 1) In Git, if I have a fork, but then there are updates to the master
> > branch, and I want to take those and replace at least some of the
> contents
> > in my fork, do I have to create a new fork and download the entire
> project,
> > again?  That seems like it would screw up the things I've been working on
> > in my fork, and mean that I would have to manually re-integrated the
> things
> > I'm doing in the files I'm working on.
> >
> > 2) I've been messing around with various widgets, but I'm not messing
> with
> > the engine, but there does not seem to be a way to fork part of the
> project
> > without forking all of it.
> >
> > --
> > 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."
> > ___
> > use-livecode mailing list
> > use-livecode@lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
> ___
> use-livecode mailing list
> use-livecode@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."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Forking Versions

[Monte Goulding]

While it is possible to commit your changes on master then merge their stuff in 
its a real headache to do things that way. What you want to do is create a 
branch to work on. Commit your changes there then when you want their stuff you 
checkout the branch you want to update. In the case of the LiveCode repo it is 
most likely develop. Then pull changes. Then checkout your branch and merge in 
develop. Now your branch is being kept updated with their stuff but isn't in 
the way when you want to get their stuff. Any merge conflicts are sorted out on 
your private branch.

Cheers

Monte

Sent from my iPhone

> On 9 Oct 2015, at 5:55 am, Mike Kerner  wrote:
> 
> 1) In Git, if I have a fork, but then there are updates to the master
> branch, and I want to take those and replace at least some of the contents
> in my fork, do I have to create a new fork and download the entire project,
> again?  That seems like it would screw up the things I've been working on
> in my fork, and mean that I would have to manually re-integrated the things
> I'm doing in the files I'm working on.
> 
> 2) I've been messing around with various widgets, but I'm not messing with
> the engine, but there does not seem to be a way to fork part of the project
> without forking all of it.
> 
> -- 
> 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."
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Forking Versions

[Monte Goulding]

Oh, you also need to add the official repo as a remote on your fork:

git remote add upstream https://github.com/livecode/livecode.git 


This adds the official repo as a remote named upstream which is the normal name 
of the original repo when you have a fork. Your fork is called origin. What you 
want to do is pull the changes from upstream (the company repo), make commits 
and push them to origin (your fork). If you have anything to contribute you can 
then send a pull request which is basically a request for them to merge in the 
changes on a branch on your fork into the official repo.

Now that you have added upstream as a remote you want to set the upstream of 
each of the official branches that you have checked out. Say you have checked 
out develop (livecode 8) then you want to do this:

git branch --set-upstream develop upstream/develop

This means that when you checkout develop and pull it will automatically pull 
from the upstream remote (the company repo) rather than your origin remote 
(your fork).

Anyway I hope that helps ;-)

> On 9 Oct 2015, at 5:55 am, Mike Kerner  wrote:
> 
> 1) In Git, if I have a fork, but then there are updates to the master
> branch, and I want to take those and replace at least some of the contents
> in my fork, do I have to create a new fork and download the entire project,
> again?  That seems like it would screw up the things I've been working on
> in my fork, and mean that I would have to manually re-integrated the things
> I'm doing in the files I'm working on.
> 
> 2) I've been messing around with various widgets, but I'm not messing with
> the engine, but there does not seem to be a way to fork part of the project
> without forking all of it.
> 
> -- 
> 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."
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Forking Versions

[Mike Kerner]

1) In Git, if I have a fork, but then there are updates to the master
branch, and I want to take those and replace at least some of the contents
in my fork, do I have to create a new fork and download the entire project,
again?  That seems like it would screw up the things I've been working on
in my fork, and mean that I would have to manually re-integrated the things
I'm doing in the files I'm working on.

2) I've been messing around with various widgets, but I'm not messing with
the engine, but there does not seem to be a way to fork part of the project
without forking all of it.

-- 
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."
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode