Comments on: Working with Forks on GitHub or CodePlex http://lostechies.com/jimmybogard/2012/04/02/working-with-forks-on-github-or-codeplex/ Strong opinions, weakly held Fri, 17 May 2013 09:02:38 +0000 hourly 1 http://wordpress.org/?v=3.4.2 By: The Morning Brew - Chris Alcock » The Morning Brew #1078 http://lostechies.com/jimmybogard/2012/04/02/working-with-forks-on-github-or-codeplex/#comment-4502 The Morning Brew - Chris Alcock » The Morning Brew #1078 Tue, 03 Apr 2012 08:33:25 +0000 http://lostechies.com/jimmybogard/2012/04/02/working-with-forks-on-github-or-codeplex/#comment-4502 [...] Working with Forks on GitHub or CodePlex - Jimmy Bogard gives an overview of forking projects which use Git has their Version Control, as the first stage in contributing back to a project. This use of Git has increasing importance in the .NET world with the new support for Git on CodePlex and the Open Source release of large parts of the ASP.NET Stack. [...] [...] Working with Forks on GitHub or CodePlex – Jimmy Bogard gives an overview of forking projects which use Git has their Version Control, as the first stage in contributing back to a project. This use of Git has increasing importance in the .NET world with the new support for Git on CodePlex and the Open Source release of large parts of the ASP.NET Stack. [...]

]]> By: Matt Enright http://lostechies.com/jimmybogard/2012/04/02/working-with-forks-on-github-or-codeplex/#comment-4501 Matt Enright Tue, 03 Apr 2012 01:23:00 +0000 http://lostechies.com/jimmybogard/2012/04/02/working-with-forks-on-github-or-codeplex/#comment-4501 I always find it best to, immediately after cloning, delete all of the "mirror branches" from the upstream repo. You're almost always going to continue updating from upstream anyways, and it's just as easy to work with 'upstream/master' as it is 'origin/master', without the mental burden of having to a) keep your fork versions up-to-date, for no real reason, and b) double the amount of references (which clutter up things like log --all or branch --contains). GitHub won't let you delete 'master', since it has to have one checked out for display, but you can either let that sit fallow, or if you're going to be more heavily dev'ing on the fork, switch the active branch to your own personal 'next' or something as taste dictates (and then delete the master). Just a maybe-helpful addition. Thanks for writing this! I always find it best to, immediately after cloning, delete all of the “mirror branches” from the upstream repo. You’re almost always going to continue updating from upstream anyways, and it’s just as easy to work with ‘upstream/master’ as it is ‘origin/master’, without the mental burden of having to a) keep your fork versions up-to-date, for no real reason, and b) double the amount of references (which clutter up things like log –all or branch –contains).

GitHub won’t let you delete ‘master’, since it has to have one checked
out for display, but you can either let that sit fallow, or if you’re
going to be more heavily dev’ing on the fork, switch the active branch
to your own personal ‘next’ or something as taste dictates (and then
delete the master).

Just a maybe-helpful addition. Thanks for writing this!

]]>