Jump to content

Syncing a fork on github


vehystrix

Recommended Posts

Like I asked on StackOverflow (http://stackoverflow.com/questions/23125859/syncing-a-fork-on-github-with-plastic-scm):

 

I've decided to contribute to an open source project on github. Since Plastic SCM can be used as a github client I decided to use it as such.

Now this is my first time using github, so I followed the classic github workflow as described in all the tutorials:

  • Fork the repo to get your own copy

  • Sync the Plastic SCM repo with the personal github repo

  • Commit changesets in Plastic SCM

  • Sync the Plastic SCM repo with github again

So far everything went fine. I contributed my code, uploaded it to github and saw all the changesets and branches appear in the github webui.

Next I put in a pull request to the original repo I forked from. This is where my problems start. The pull request was accepted, and a new changeset appeared in the original repo which contains my pull request. It seems all my intermediate branches did not transfer to the original repo either.

411YK.png

As shown in the network graph above, the original repo (purple) is now no longer in sync with mine. I started with further development in another branch (VEH003) but this one seems to be completely disconnected from the original repo (purple).

In my Plastic SCM client I can see exactly the same network graphs in the branch explorer, with the exception of the purple branch.

I read that to update your fork with the changesets from the original repo this has to be done explicitly, and in your local git repository (github help). Now I don't know how this is done using Plastic SCM.

 

 

Any help is greatly appreciated

Link to comment
Share on other sites

Hi,

 

Assuming that the picture is of from the hosted repository on GitHub belonging to 'egret85' (so not your own repo- or perhaps it is your repo, but you have pulled again from 'egret85'), then it looks like everything has worked perfectly - your Plastic branches were exported into your repo, and that in turn was pulled from into the one belonging to 'egret85'. The 'master' branch for 'egret85' seems to have a merge commit from your own repo's 'master' (hard to tell as the diagram is a little cluttered). Your new branch VEH003 has made its way on to the 'egret85' repo. Unless you 1) merge that branch into your own Plastic 'main' branch (which is 'master' on your local Git repo), resync with Git and 2) make another pull request, or 3) you ask 'egret85' to merge from VEH003, then that branch will stay disconnected.

 

So I think everything is working fine.

Link to comment
Share on other sites

The picture is from my repository.

the last changeset on egret85's repository is my latest pull request. This pull request was the same changeset (in my repo) as the base for my branch VEH003.

I am worried that github does not recognise these 2 changesets as being one and the same. Idealy the master branch of both repos (mine and egret85s) should have only a single head, as it stand now they each seem to have their own head.

Either that, or I am completely misinterpreting the workings of github and it's forking.

 

Picture from egret85s repository network graph:

2zem934.png

Link to comment
Share on other sites

(I'm not sure whether you have *pulled* back from egret85 or just done a *fetch* since making your pull request, so I'm guessing here - sorry if I'm off the mark.)

 

 

I think this is a misunderstanding - I would agree that it looks like you branched 'main-VEH003' off the changeset used as the source of the merge carried out by egret85 in answer to your pull request.

 

The merge done by egret85 in response to your pull request creates a new changeset in egret85's repo and updates egret85's 'master' branch to refer to it - however yours is still pointing to the source changeset in your repo.

 

If you pull from egret85 in Git, this will fast-forward your own 'master' to align with egret85's, so you will see just one 'master' again if my memory of how Github's network rendering works is correct. You can then re-sync with Plastic from your repo once you have done this.

 

 

As for 'main-VEH003', that will remain as a separate head until you merge it either via Plastic or via Git.

Link to comment
Share on other sites

(Disclaimer - I am not part of Codice Software - so you are getting another user's opinion).

 

In short, I think that you are right.

 

1. Plastic SCM will correctly sync with your public GitHub repo (this is what I do every day for my open source work - I rarely use Git these days unless I'm working on a client company's machine and contributing hot fixes).

 

2. When you want to collaborate with others in the GitHub community, you will need to use the GitHub workflow for doing this, this is directly between your GitHub repo and those belonging to other people - Plastic isn't involved. So yes, you would either manage this in GitHub using its web interface, or use Git itself on your own machine to do this. This is all documented elsewhere, and I encourage you to spend some time getting familiar with the Git tools. It's pretty straightforward.

 

3. However, if you can liase with other people on GitHub, you could request direct commit rights on to their repo, and then directly sync Plastic to their repo.

 

If you go down this third road, I strongly advise you to  *not* involve your own repo on GitHub - so for example, you *SHOULD NOT*:-

 

i) change the sync on your Plastic repository so that it alternates between your own public GitHub repo and, say, egret85's.

ii) use Plastic to sync between two separate Plastic repositories, one of which also syncs with your own public GitHub repo and the other which also syncs with egret85. Just trust me and don't do this.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...