too many forks spoil the code... - Page 1
Forum section: electronics / general

author: ralphd
author_rank: Frequent Contributor
timestamp: March 22, 2015, 12:45:46 am
content: I'm working on updates to an Arduino library that is hosted on github. There's already several forks of the library, most of them no longer maintained. I'm in contact with the maintainer of what seems to be the most active fork, and said I was considering sending my updates by email rather than forking and requesting a pull when my changes are done, since I can't I can't make a private fork. The maintainer suggested I still fork, and then after my changes are merged upstream, delete my fork.Is this the best option? I'm used to CVS and SVN, but just getting (dragged) into git.

author: westfw
author_rank: Super Contributor
timestamp: March 22, 2015, 01:01:58 am
content: I dunno. I think some of the forks are a result of people not understanding the Git workflow, and/or having an overly optimistic impression of whether their changes are likely to be accepted. Take a fork, modify it, submit the pull request, ask whether it's a good idea, and wait for something to happen.Unless your changes are dependent on changes already in some other fork, I think you you should only pay attention to the "official" repository/fork, and not worry about other forks. If it's easier for you to send in diffs, go ahead and do that - the worst that will happen (wrt forking, anyway) is that someone will say "that's great. Can you take a fork and submit a pull request?", which is about as easy to do after-the-fact as before.But I don't think I understand the Git workflow, either :-(

author: photon
author_rank: Frequent Contributor
timestamp: March 22, 2015, 01:20:23 am
content: It is very easy to fork and very hard to merge. That is why a well run product team never allows a fork during development schedule. Forks cause schedule slips and slips are bad.So, developers must always run a check-in regression suite that is there to check that the changes do not break the database. Then the update is done. Then overnight regression is run. This is how progress is made.I doubt anyone will merge your changes for you, especially if you have many. That usually requires the original developer to accomplish.

author: photon
author_rank: Frequent Contributor
timestamp: March 22, 2015, 02:09:34 am
content: Something you can try. Get a fork and a regression suite. Put your changes into the fork and run the regression suite. Fix bugs. Create a patch file with the diffs. Send the patch file to the developer and ask him to add it. This way no pull or push.

author: andersm
author_rank: Super Contributor
timestamp: March 22, 2015, 09:00:34 am
content: If you're going to upstream your changes anyway, there's no reason not to fork. If you don't want others to see your under-development commits, use feature branches on your development machine that you don't push to Github, and only merge to mainline and push once you have something complete you want to publish.

author: ralphd
author_rank: Frequent Contributor
timestamp: March 22, 2015, 09:26:21 pm
content: What I decided to do was create a fork, and in the description I indicate it is a private development fork (not intended for public use). When I finish my changes and local testing I'll commit them to my fork and contact the upstream maintainer. Once it's fully tested, the maintainer will pull my changes. I'll keep my fork in case I do some more work on the library, and try to remember to delete it if I end up doing nothing with it for several months.

author: mrflibble
author_rank: Super Contributor
timestamp: March 23, 2015, 03:34:02 pm
content: And now you know how all those other forks came into existence.Are you sure you need a fork? It sounds like you just need a local branch. Clone repo (either the original or one of those forks, whichever makes most sense), and then branch locally. That way you can still keep in sync with the remote should someone do some useful work there. And it will be easier to merge when you are done locally.See for example:http://stackoverflow.com/questions/3611256/forking-vs-branching-in-githubOr you could just generate patch files and e-mail them if you want to feel retro. I mean, if you're not going to use the capabilities of your chosen versioning software you might as well go all the way.Disclaimer: I am farfarfrom being a git guru, but this choice of yet another fork just sounds like the wrong tool for the job.

author: tszaboo
author_rank: Super Contributor
timestamp: March 23, 2015, 04:21:37 pm
content: I'm sure if there is too many forks, the solution is to create another one to solve the issues with all the other.

author: ralphd
author_rank: Frequent Contributor
timestamp: March 23, 2015, 08:49:07 pm
content: Quote from: mrflibble on March 23, 2015, 03:34:02 pmIf I had cloned, branched locally, then how would I get my changes merged into the main git?Is the idea to ask the maintainer to make a branch that I have permission to make commits on, and then ask him to merge the branch after it's fully tested?

author: Stupid Beard
author_rank: Regular Contributor
timestamp: March 23, 2015, 09:14:37 pm
content: Quote from: ralphd on March 23, 2015, 08:49:07 pmThe problem you are having is that you are thinking of git in the same way you think about CVS or Subversion.With svn there is a central repository and you checkout a copy of the code and work on it and then commit back to the repository. Git does not work that way, and the sooner that you stop thinking about things in those terms the easier time you will have.Instead of local checkouts, git clone is an entire separate copy of the repository. There is no central repository at all. Commits are tracked by hash and in a way that can be tracked back to the original commit, regardless of what cloned repository it was originally made in.Branching and merging is thus a really simple process and it (nearly) doesn't matter how or where you do it. The repo maintainer would not create a branch for you because they don't need to. They can just pull from your existing branch directly and merge in however they want.You actually don't need to do anything besides make your branch accessible to them somehow. The easiest way to do that is with a fork on github that you push to, but you could just as easily have done it by giving them an ssh account on your local machine and giving them direct access to your local clone through that. Not necessarily a good idea from a security point of view, but it is very useful to do that yourself when you're working on multiple machines.The above description of things is probably a bit crap, so I suggest you do some reading on how git works and actually try and understand it without thinking of it in terms of svn. A good way to do that is to try doing some work on multiple machines.We switched to git from svn a couple of years back and the conceptual differences were a major stumbling block at the beginning. Once you have used it a bit and spent the time to understand things without being polluted by how svn works it all makes sense and is a really decent way of doing things. But, until you actually forget your existing interpretation of what a repository is you will be frustrated and not understand things.Personally, I hated git at first and thought it was stupid. Now you'd have to pay me to go back to svn

author: photon
author_rank: Frequent Contributor
timestamp: March 23, 2015, 09:59:47 pm
content: Thanks for the info, StupidBeard. I am also an svn user. I have not used git. From your description it seems to me the difference between a merge for svn and git is the following:SVN merge:1. pull to get an updated repo2. make your change3. push the change to the repoGIT merge:1. update your repo2. ask someone to merge your repo into his

author: Stupid Beard
author_rank: Regular Contributor
timestamp: March 23, 2015, 10:40:35 pm
content: Quote from: photon on March 23, 2015, 09:59:47 pmIn general, yes thats about right and a good way to look at it.In the interest of accuracy: if you want to confuse yourself a bit then read up on bare repositories, but you don't need to worry about that unless you're hosting a server that people can push to.

author: ralphd
author_rank: Frequent Contributor
timestamp: March 24, 2015, 12:56:57 am
content: Ditto on the thanks from me.Your description has left me in just the right mix of confused and intrigued. It sounds like I'll have to bite the bullet and read up on how git works under the hood in order to really understand how it works and what it can do...

author: Stupid Beard
author_rank: Regular Contributor
timestamp: March 24, 2015, 01:07:46 am
content: Glad to help.If you're able to, give it a go on a small project. Some things only really click through using it. Working in a team helps, but working with the repo on more than one computer is also a good thing to aid understanding. You can also fake it by using multiple clones on one machine if you have to.

author: codeboy2k
author_rank: Super Contributor
timestamp: March 24, 2015, 02:05:08 am
content: Forks on github are painless and I would suspect they don't even waste space on github servers.What I do is fork a project in my own public space. Then I 'git clone' that down to my local PC using the ssh protocol (so I can push back). I work locally, committing locally as needed, local branches, whatever makes it easy for me. When I am ready to give back, I do a final commit and push that back to my own fork on github. Then from within my own fork using the github web site, I make a pull request to the upstream maintainer.It's very painless and should not be a blocker for you.It's a standard operating procedure on github, and people expect you to make pull requests.

author: photon
author_rank: Frequent Contributor
timestamp: March 24, 2015, 02:53:20 am
content: Thanks codeboy. What happens when the upstream maintainer does the pull and there are conflicts, ie 2 people changed the same file at the same place? Then the upstream maintainer's pull has to be resolved somehow. How is that done?

author: Stupid Beard
author_rank: Regular Contributor
timestamp: March 24, 2015, 04:11:40 am
content: Quote from: photon on March 24, 2015, 02:53:20 amIt is worth differentiating from github (and other hosting site) terminology/features and actual git features. Forks and pull requests are github (and etc) things to make some common tasks easier. What a pull request basically amounts to is a branch merge, so your question can be simplified to "how are merge conflicts resolved?"From a technical point of view, the way you resolve conflicts in git is more or less the same as the way you do it in svn. The commit fails, you edit the offending files to fix the conflict then mark it as fixed and commit the merge.What the maintainer does is in the case of a pull request failing to merge is totally up to the maintainer. Maybe they'll spend the time to fix it, maybe they'll punt it back to you and say "fix these conflicts then do another PR." That's not an answerable part of the question in any kind of general sense.

author: Muxr
author_rank: Super Contributor
timestamp: March 24, 2015, 04:41:17 am
content: Forks are the way to do it with github. It's how you're supposed to contribute to a project. Fork, work on the feature branch/fix, and create a PR to have the maintainer merge to main fork.Don't worry about all these forks out there, the original fork is what matters. Unless of course you're talking about project forks, where a separate fork is being maintained as a master fork and is diverging from the original project.

author: westfw
author_rank: Super Contributor
timestamp: March 24, 2015, 06:10:13 am
content: QuoteI think I get it. Having a lot of "branches" would be a bad thing in most RCSes, but Git's 'Fork' concept is a much ligher-weight concept; pretty much just per-change working storage. Not to be confused with a Project "forking" into multiple incompatible and independently-maintained source trees (emacs vs xemacs, or Wiring/Arduino/Arduino.) (although I guess Git forks could be used that way as well? But it's not not normal case.)

author: codeboy2k
author_rank: Super Contributor
timestamp: March 24, 2015, 06:31:33 am
content: Quote from: westfw on March 24, 2015, 06:10:13 amGit doesn't have forks. Remember that. The fork and pull requests concept is a github thing .. other sites have copied it. It's git underneath, but you should keep the concepts separate. git has branches. From one git repo to another, you pull and push branches (and the main branch, traditionally called 'master' is just another branch, it's nothing special like it would be in SVN (trunk) or CVS. )Yes, branches in git are lightweight and in my local copy of a repository I will often have several branches going at once. To try out a test code path, I'll make a branch. If that's not working, maybe I'll commit that branch, then go back and checkout the point before the branch and make another branch, going down a different path. If I want to stay on the same branch and make a small test, I'll do that with another quick branch. It's painless in git.However github introduced the concept of forks, and pull requests. github has users "forking" other repos and making pull requests, so the upstream maintainer can do the actual merge (and resolve conflicts). This workflow was created so that maintainers did not have to give write permission to their repository, yet still allowing an open contribution model. But after you fork a repo (on github), then the same branching model is used on your local copy (and your forked copy on github if you also choose to push the branch(es) there).

author: photon
author_rank: Frequent Contributor
timestamp: March 24, 2015, 06:39:29 am
content: Quote from: westfw on March 24, 2015, 06:10:13 amThat's also true for svn. The branches are a series of diff files or patches. This makes it possible to go from one branch to another very efficiently by just applying the diffs. What can be problematic is when you have a very old branch and merge it with the newest branch that is many diffs away from it, ie a lot of changes have been made. This is harder to merge since there are a lot more chances for conflicting changes to occur.I am used to svn where there is only one repo. It appears that git doesn't have the idea of a central repo , just a branch. All branches are created equal. Somebody creates the inital branch and you go from there. You can merge any two branches in git. In svn, on the other hand, you always merge a branch into the repo, if I understand it correctly.

author: photon
author_rank: Frequent Contributor
timestamp: March 24, 2015, 06:46:14 am
content: Thanks codeboy for the explanation of the difference between github and git.

author: Bassman59
author_rank: Super Contributor
timestamp: March 24, 2015, 05:37:25 pm
content: Quote from: codeboy2k on March 24, 2015, 06:31:33 amthanks for the explanation. As a long-time subversion user, git has sorta baffled me. You've made it clearer.

author: codeboy2k
author_rank: Super Contributor
timestamp: March 25, 2015, 10:33:28 am
content: you're welcome. as a long time user, git still baffles me oftenSome resources:Git - The Simple Guidehttp://rogerdudler.github.io/git-guide/Pro Githttp://git-scm.com/book/en/v2The Git CheatSheettries to show the relationship between the stash, the workspace, the index (staging area), the repo, and the upstream repohttp://www.ndpsoftware.com/git-cheatsheet.htmlThe Vogella Tutorials- detailed guideshttp://www.vogella.com/tutorials/Git/article.htmlGitBlit- not a tutorial, but a pretty good Github like server for your own in-house repositories. I've used it at a site.I'm not affiliated with them."Gitblit blends elements of GitHub, BitBucket, and Gerrit to provide a streamlined collaboration workflow based on branches within the primary repository"http://gitblit.com/index.htmlhttp://gitblit.com/screenshots.html

author: mrflibble
author_rank: Super Contributor
timestamp: March 25, 2015, 09:21:19 pm
content: Quote from: codeboy2k on March 25, 2015, 10:33:28 amThanks! Definitely some useful tidbits in there.And thanks to Stupid Beard as well for the github fork vs branch explanation. Github's use of fork was a bit confusing. But given their constraint of rather coarse grained repository permission it's understandable. If I understand correctly a github repo is either read-only, or you can write all over the entire repo. No option to restrict someone's write access to a particular feature branch.If you really wanted to work branch based locally, you probably could work around that by having 1 repo locally with branches. And then have the remotes of those branches point to the github forks. Not sure if that would be worth the trouble though.

author: Stupid Beard
author_rank: Regular Contributor
timestamp: March 25, 2015, 09:59:21 pm
content: To add to the list of useful links,http://nvie.com/posts/a-successful-git-branching-model/is worth a read for anyone considering setting up a git based project.Edit: it also has some useful general info that may help anyone who still has mental blocks, or it may not

author: codeboy2k
author_rank: Super Contributor
timestamp: March 26, 2015, 07:31:36 pm
content: I follow that branching model somewhat.. it works well for me.Except that I call my development branch just dev, not develop ... geez.. who wants to type 3 syllables