GitHub

[Magnus Bergmark]

On Wed, Jan 7, 2009 at 5:04 AM, Jeff Mitchell <kde-dev at emailgoeshere.com>wrote:

> Magnus Bergmark wrote:
> > 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
>
> This assumes that you have push rights upstream.  If that is the case,
> there's no point in having your own account in the first place, and you
> might as well all just share one account.
>

That depends on the model of development. With a centralized repo, almost
every developer should have push access to it, yes. However, one-shot
contributors shouldn't get push access to the repo, but should instead send
in patches or pull requests (in case of GitHub). There *will* be people who
are a permanent part of the project with push access, but don't forget about
the people who just wants to do a smaller feature, help with translations,
etc. but still don't want to be a permanent part of the project.

This also doesn't take into account what happens when you have 15
> developers, each with their own account, that do the same thing.  If
> everyone wants to share branches and try each other's out, you need to
> add everyone's remote refs and keep them updated, or push them all to
> different branches "upstream".  Either way, you're better off having
> everyone share one Github account, and if you are doing that, you lose
> most of the perceived benefit of Github anyways.
>
> > In newer versions of Git, the remote branches is automatically added as
> > tracked branches now.
>
> Which remote branches?  This doesn't happen (in current git) when you
> add a remote ref.  You still have to decide which branches you want to
> track and create local branches for them.


I still doesn't understand what you are trying to say here. All branches in
the public repo is visible in your local clone. Every fetch will update the
branch contents and also fetch all new branches you have not seen before.
The reason for creating a tracking branch is to make sure that you have a
local branch you can commit to and when you push, that branch will be pushed
to a branch on the remote server instead of being merged into HEAD on the
remote repo.

When you create a branch with a remote branch as a base, you will create a
new tracking branch for that (in case you haven't turned off the autotrack
option). If the remote branch "2.0.x" exists on the server and you do a
checkout on it, you will have a local branch named "2.0.x" which will
automatically be synced with "<remote>/2.0.x" when you fetch or push.


> > If you need to create a /new/ remote branch,
>
> This will be a common use-case.
>
> > 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.
>
> If you've added *everyone's* upstream, or if everyone pushes their
> branches to the upstream account (in which case everyone would just be
> using that account anyways).


Once again, the common model for bigger projects on GitHub is to have a main
repository, in this case "amarok/amarok", with the primary developers having
push access to it. Primary developer Steve will have a clone of this
repository on his machine and push to it like any other repo. This is no
different than having your own git hosting with several people having access
to it.

Now, if John the Contributor has a fork/clone with some large changes, Steve
can add it as a remote called, say, "john". This is not common, but it's
still easy to handle, since he can then track branches by checking out
"john/master" into "crazy-branch" and then be done with it. Committing will
work. Pushing will work. Fetching will work. If Steve, which have push
access to amarok/amarok, wants to integrate John's changes, he just have to
make them work for him, merge into the primary master and then push again.
Still no problem or hard-to-do stuff here.

What you are talking about seems to be no primary repository at all, which
of course is hard. It would be hard if everyone had their own SVN branch or
server, too. Still, if you added every single repo as a remote, with the
nickname of the developer as the remote name, you would still know which
branches they all use by just issuing "git branch -a", which would display
like
master
2.0.x
2.1.x
new_collection_scanner
seb/master
seb/2.0.x
seb/2.1.x
seb/new_collection_scanner
...


> Github "fork" makes you do a clone of a clone.  By the time you get it,
> your branches track upstream, except upstream is now your github repo
> and not actual upstream.  Of course, this means you still have a remote
> location to store your data instead of just having it on your local
> machine...and that's the real use for Github anyways (but doesn't really
> elevate it above a normal git server), but it means it's actually more
> complicated to do what a normal, simple "git clone" from a normal git
> server would accomplish.


Terminology collision. In GitHub terms, your fork would not be your
upstream, but your origin.

Every developer has a private (on his machine) and a public (on GitHub)
repository. The public is called "origin" since that's the one you clone if
you have a fork. After the cloning, you do a "remote add upstream <URL>" and
then you have a remote called "upstream", which will be the original repo
you forked. You can then push to your public repo for any reason you want --
since it's your own version. Perhaps you do it in case you have multiple
development machines you want to sync between, because you have some large
changes that need even more participation from others or similar. Now, when
you want the change into the primary repo, you can push to it directly if
you have that access, or you'll have to push to your own fork of it and
request a merge (or send patches through email, or give people connection
information to your public repository).

If you have no reason to fork the project (why would a primary developer
fork his own project?) you can just work with the primary repo directly.
That would be your "origin" in that default case, but it's up to you to
decide what you name your remote. Forking is for external contributors only,
or in case of a regular split between developers (a traditional software
forking).


>
> > 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.
>
> Why is it useful for Github to do the merge for you?


Well, it's useful if you get a long list of small commits. Now, this may not
happen here, but in many projects, people can contribute with small commits
like spelling fixes and it would be easy if you didn't have to fetch your
repo, add the other fork as a remote, fetch the remote, get the specific
commit, cherry-pick it into your own repo, push it and then remove the
remote repo. In GitHub, you can see all commits done in forks in this UI and
cherry-pick the commits you want, look at the diffs and try them out
directly.

This is once again one of the reasons people chose GitHub over the others. I
wasn't saying it was something you would use personally, but you might.

>
> > GitHub is like any ordinary repo hosting server, anything you can do
> > with your own bare-bones git hosting can be done on GitHub.
>
> Not actually true.  But I'll let it slide.


Could you please elaborate. Let's say you create a repo and then just forget
about the web site. What will be different from your SSH access to a repo on
server X and the SSH access to the repo on GitHub's server?


>
> > It's their
> > UI around all features that make people chose them.
>
> Yes, people are easily amused by AJAX and the word "social", regardless
> of whether it actually means anything (and in Github, it doesn't...you
> have Github usernames instead of email addresses, which doesn't make it
> any more "social").  There isn't anything you can't do on a non Github
> server (and some things you can't do on Github).  People choose them
> because they don't want to bother setting up a server themselves (which
> is a perfectly valid reason for many projects)...and for reasons like in
> the article Mark gave, where someone is afraid they may abandon their
> project and want to make it easy for someone to pick up without them
> having to keep the repo up themselves (much easier to have someone else
> host it then).


It's not always about "not bother". Some times it's just easier to do it in
one way. That logic could be applied to just about anything which make stuff
more useful for people:
Yes, people are easily amused by visualizations and the word "collection",
regardless
of whether it actually means anything (and in Amarok, it doesn't...you
have collections instead of file hierarcies).  There isn't anything you
can't do on a non Amarok
music player (and some things you can't do in Amarok).  People choose it
because they don't want to bother setting up a collection database
themselves (which
is a perfectly valid reason for many users)...and for reasons like in the
article Mark gave,
where someone is afraid they may forget about some tracks and want to make
it easy for
him/her to have a play count tracking (much easier to have someone else
create it).
Yes, very bad example, but I still think it got the point through. In case
you don't have any specific examples to back up the claim that GitHub
repositories lack some fundamental things neccessary, it's just empty talk
like my bad attempt at a metaphor above. People doesn't just use GitHub
because of AJAX and the word "social", they use it and like it because that
dreaded AJAX makes it fast and easy to use and that awful "social" makes it
just a bit easier to make small time contributions.

You still commit with your email adress on GitHub. They haven't changes any
of that. That is why there is no commit to the Rails repository by the user
"Rails". It's only the email addresses that matters.

Please understand that I'm not totally down on Github...it has its
> place, and works very well for some things, especially for small
> personal projects.  But I've also had to do lots of dealing with what
> happens when things go wrong with its model, which starts to break down
> and make things harder when people are doing more than sending just a
> patch or two, especially if they are not sharing an account.
>

I do, and I hope you understand that I'm not 100% for GitHub either. I'm
that kind of person that believes in using the best tool for the job. I will
change my stance in a heartbeat if I could see a valid reason GitHub is not
adequate. I'm also aware that I'm not part of the project yet, so I have
nothing to say in the matter. I'm not trying to decide for anyone, just make
sure that people get the facts straight. :-)


>
> If Amarok people want to use Github, that's fine; but I would very
> strongly recommend that everyone then share an account for Amarok
> development work.


That is my recommendation as well. It's the most common and useful practice.
(E.g. have a central repo, doesn't matter if you have an own account or not,
since GitHub will only be looking at your email anyway - email matching an
existing account will be displayed with your nick instead of the email,
tough)


> It's also worth noting that Github is closed source,
> so if people are uncomfortable with that, they should be looking at
> Gitorious or some such thing.
>

Valid point which I agree with.

-- 
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/20090107/00ae7790/attachment-0001.htm