Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
No D on DVCS via github?
Posted Dec 13, 2012 22:53 UTC (Thu) by man_ls (subscriber, #15091)
That is just the bare minimum; people also sync with other repos all the time, fork and sync afterwards, request merges, etcetera. It is not hard to do, there are big shiny buttons to simplify it.
Besides, the implication is that distributed git does not work unless it's centralized in a single place. Just the notion of having two or more repos as upstream is apparently too confusing for "normal people". I cannot fathom what that means in the context of developers without imagining sweat shops of lowly Visual Basic coders -- glad to switch from SourceSafe to anything else.
Posted Dec 14, 2012 20:30 UTC (Fri) by mirabilos (subscriber, #84359)
Posted Dec 15, 2012 0:48 UTC (Sat) by man_ls (subscriber, #15091)
Then there is the rest of the features that github makes easy, but which are trivial to anyone that has worked with patches for a couple of years.
Posted Dec 14, 2012 4:13 UTC (Fri) by apoelstra (subscriber, #75205)
People use github in as many different ways as people use git.
For example, I often use github repositories as a read-only central repository, on top of which I have a few local changes. Then I periodically sync with "git fetch origin && git rebase origin master". Maybe I'll read the new entries of "git log origin --not master" before rebasing. This is nearly the way I'd use a centralized CVS.
Other times I'll add several github repositories as remotes to a local repository. (Such as on the bitcoin project, where several developers have their own repositories where they push experimental changes.) Then I can switch between their code and mine and cherry-pick to my heart's content.
With my own code, I start working with local git repositories -- well, local in the sense that the "origin" remote lives on my backup server. Then if I want to publish things, I can just set up a github repo, add it as a remote, then push things to and from there. When people send me pull requests or patches, I can pull them to the local system and rearrange them, then push them to the github remote.
Besides, Github itself has pretty buttons for managing pull requests between different github repositories, and also has key management tools if you want to let people push directly. So they go further than just "not enforcing anything" and actively support different workflows.
The only times I use git in such a simple way that svn could handle it, I'm using "git clone" as a shortcut for wget and tar -- that is, I'm not controlling the source code at all.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds