Re: Repositories

[Dr. H. Nikolaus Schaller]

Am 20.12.2013 um 17:11 schrieb Markus Hitter:

> Am 20.12.2013 16:05, schrieb David Chisnall:
>> - svn or git views of the repo, so developers can use either
> 
> That's possible with pure SVN repos, too. git-svn will check out a SVN
> repo just fine and you can work with it as if it were a Git repo.
> 
>> - An easy way for people to branch / submit patches
> 
> Actually, you can neither and I consider this to be the weakest point of
> Github. You can only fork and this forked repo is invisible from the
> originating repo. Also, sending patches is extremely awkward, because
> attaching files to bug reports is straight out not possible. You have to
> fork, clone the fork again (or fuss with git remote), move patches over
> there, too, push back to Github, then send a pull request. That done the
> maintainer has to git-remote-add the fork to pick over (or merge) the
> patch. This "merge" button on the web page is pointless, because it
> doesn't allow to review the patch. Not to mention that merging is a bit
> old fashioned when using Git, cherry-picking and rebasing opens new
> horizons.
> 
> I'm writing this as one who hosts three active projects on Github. If
> you can deal with the disallowance of patch/file uploads (and the
> resulting lack of patch contributions), Github is fine. It's indeed the
> least sucking one and very visible.

There would be the Linux way of handling patches.

1. people clone the central repository (and pull from time to time)
2. they develop patches in whatever (local) branches they like to
3. if a patch is working for them, they git-format-patch and post it to
the mailing list
4. the (a) maintainer picks up the patch and tries to apply with
git am file.patch to a local branch
5. if ok, the maintainer makes a push to github and it is "accepted"

Linux has of course a multi-stage approach to this so that Linus
gets bigger junks to handle rather than single patch files. And
he pulls from topic specific repos as you describe.

After a while I found this the most natural way of collaborating
on a git project. I..e I don't need write access to the central repo
at all.

BR,
Nikolaus