GitHub

[Magnus Bergmark]

On Tue, Jan 6, 2009 at 4:31 PM, Lydia Pintscher <lydia at kde.org> wrote:

> proxymailing for Jeff ;-)
>
> [...]
>
> This means that unless everyone shares a single GitHub account, it
> becomes very annoying to actually use this and pass branches back and
> forth.  Here's what it really means:
>

That's what Rails is doing. Check out http://www.github.com/rails/rails. It
is possible and allowed to do this.


>
> 1) If you want to have a branch tracking upstream, you have to add both
> the remote ref and the branch yourself, manually, on each computer to
> access your GitHub repo from.  This branch also isn't synchronized with
> your GitHub account (unless you do it yourself).


I don't what you mean. Say I forked Amarok from amarok/amarok into my own,
Mange/amarok, and then clone it to my computer, this is what I should do:

   1. Run "git remote add upstream git at github.com:amarok/amarok.git" so I
   have the remote repo "upstream" defined
   2. Commit changes to my repository as usual, and then
      1. Push to my own github account ("origin") for sync between my
      machines
      2. Push to "upstream" when my changes are done and official

In newer versions of Git, the remote branches is automatically added as
tracked branches now. If you need to create a *new* remote branch, then yes,
the other developers will not get them automagically, but will have to add
them themselves AFAIK. But as long as you have added upstream like above,
it's as simple as "git checkout upstream/new-cool-feature" and bam!, it's
there, checked out and tracked.

Creating a remote branch is about as simple as "git checkout -b even-cooler;
git push origin even-cooler".

I think the PITA here comes from the fact that a lot of merging will have to
be done in case J.Doe pushes to upstream and I have pushed changes to my
origin AND I want a linear history when I merge to upstream myself. I can't
(shouldn't) rebase my changes on top of J.Doe's changes since I have already
pushed to my origin, which is a public repository.

Of course, the most practical way to use this would be to have just
amarok/amarok with several developers committing to that. If you as a
developer use multiple machines, then fork it, and never push from your own
fork's repository to upstream, instead pull to upstream from your own fork
in that case. We still get the good parts of github, which is that one-shot
contributors can fork, commit, send pull requests and then get their patches
in. GitHub even has a new web-UI for applying patches from other people into
the repo, without even having to merge or anything, which can be mighty
useful.

[...]
> --Jeff
>
> --
> Lydia Pintscher
> Amarok community manager
> kde.org - amarok.kde.org - kubuntu.org
> claimid.com/nightrose
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>

GitHub is like any ordinary repo hosting server, anything you can do with
your own bare-bones git hosting can be done on GitHub. It's their UI around
all features that make people chose them.

But I could also just have missed all the points here. Perhaps Jeff could
elaborate a bit for a naïve mind like mine own. :-)

-- 
Magnus Bergmark - magnus DOT bergmark AT gmail DOT com
GPG/PGP: 0x7BE84794DB6AA648
Fingerprint: 0E6F D2DB F0EF 534A 2184 52AF 7BE8 4794 DB6A A648
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20090106/9ac95e88/attachment-0001.htm