On Wed, Jan 7, 2009 at 5:04 AM, Jeff Mitchell <span dir="ltr"><<a href="mailto:kde-dev@emailgoeshere.com">kde-dev@emailgoeshere.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Magnus Bergmark wrote:<br>
> I don't what you mean. Say I forked Amarok from amarok/amarok into my<br>
> own, Mange/amarok, and then clone it to my computer, this is what I<br>
> should do:<br>
><br>
</div>> 1. Run "git remote add upstream git@github.com:amarok/amarok.git" so<br>
<div class="Ih2E3d">> I have the remote repo "upstream" defined<br>
</div>> 2. Commit changes to my repository as usual, and then<br>
> 1. Push to my own github account ("origin") for sync between my<br>
> machines<br>
> 2. Push to "upstream" when my changes are done and official<br>
<br>
This assumes that you have push rights upstream. If that is the case,<br>
there's no point in having your own account in the first place, and you<br>
might as well all just share one account.<br>
</blockquote><div><br>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 <b>will</b> 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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This also doesn't take into account what happens when you have 15<br>
developers, each with their own account, that do the same thing. If<br>
everyone wants to share branches and try each other's out, you need to<br>
add everyone's remote refs and keep them updated, or push them all to<br>
different branches "upstream". Either way, you're better off having<br>
everyone share one Github account, and if you are doing that, you lose<br>
most of the perceived benefit of Github anyways.<br>
<div class="Ih2E3d"><br>
> In newer versions of Git, the remote branches is automatically added as<br>
> tracked branches now.<br>
<br>
</div>Which remote branches? This doesn't happen (in current git) when you<br>
add a remote ref. You still have to decide which branches you want to<br>
track and create local branches for them.</blockquote><div><br>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.<br>
<br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> If you need to create a /new/ remote branch,<br><div class="Ih2E3d">
<br>
</div>This will be a common use-case.<br>
<div class="Ih2E3d"><br>
> yes, the other developers will not get them automagically, but will have<br>
> to add them themselves AFAIK. But as long as you have added upstream<br>
> like above, it's as simple as "git checkout upstream/new-cool-feature"<br>
> and bam!, it's there, checked out and tracked.<br>
<br>
</div>If you've added *everyone's* upstream, or if everyone pushes their<br>
branches to the upstream account (in which case everyone would just be<br>
using that account anyways).</blockquote><div><br>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.<br>
<br>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.<br>
<br>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<br>
<div style="margin-left: 40px;">master<br>2.0.x<br>2.1.x<br>new_collection_scanner<br>seb/master<br>seb/2.0.x<br>seb/2.1.x<br>seb/new_collection_scanner<br>...<br></div> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Github "fork" makes you do a clone of a clone. By the time you get it,<br>
your branches track upstream, except upstream is now your github repo<br>
and not actual upstream. Of course, this means you still have a remote<br>
location to store your data instead of just having it on your local<br>
machine...and that's the real use for Github anyways (but doesn't really<br>
elevate it above a normal git server), but it means it's actually more<br>
complicated to do what a normal, simple "git clone" from a normal git<br>
server would accomplish.</blockquote><div><br>Terminology collision. In GitHub terms, your fork would not be your upstream, but your origin.<br><br>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).<br>
<br>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).<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div class="Ih2E3d">
> GitHub even has a new web-UI for applying patches<br>
> from other people into the repo, without even having to merge or<br>
> anything, which can be mighty useful.<br>
<br>
</div>Why is it useful for Github to do the merge for you?</blockquote><div><br>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.<br>
<br>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. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
> GitHub is like any ordinary repo hosting server, anything you can do<br>
> with your own bare-bones git hosting can be done on GitHub.<br>
<br>
</div>Not actually true. But I'll let it slide.</blockquote><div><br>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?<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br><div class="Ih2E3d">
> It's their<br>
> UI around all features that make people chose them.<br>
<br>
</div>Yes, people are easily amused by AJAX and the word "social", regardless<br>
of whether it actually means anything (and in Github, it doesn't...you<br>
have Github usernames instead of email addresses, which doesn't make it<br>
any more "social"). There isn't anything you can't do on a non Github<br>
server (and some things you can't do on Github). People choose them<br>
because they don't want to bother setting up a server themselves (which<br>
is a perfectly valid reason for many projects)...and for reasons like in<br>
the article Mark gave, where someone is afraid they may abandon their<br>
project and want to make it easy for someone to pick up without them<br>
having to keep the repo up themselves (much easier to have someone else<br>
host it then).</blockquote><div><br>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:<br>
<div style="margin-left: 40px;">Yes, people are easily amused by visualizations and the word "collection", regardless<br>
of whether it actually means anything (and in Amarok, it doesn't...you<br>
have collections instead of file hierarcies). There isn't anything you can't do on a non Amarok <br>music player (and some things you can't do in Amarok). People choose it<br>
because they don't want to bother setting up a collection database themselves (which<br>
is a perfectly valid reason for many users)...and for reasons like in the article Mark gave, <br>where someone is afraid they may forget about some tracks and want to make it easy for <br>him/her to have a play count tracking (much easier to have someone else
create it).<br></div>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.<br>
<br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Please understand that I'm not totally down on Github...it has its<br>
place, and works very well for some things, especially for small<br>
personal projects. But I've also had to do lots of dealing with what<br>
happens when things go wrong with its model, which starts to break down<br>
and make things harder when people are doing more than sending just a<br>
patch or two, especially if they are not sharing an account.<br>
</blockquote><div><br>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. :-) <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
If Amarok people want to use Github, that's fine; but I would very<br>
strongly recommend that everyone then share an account for Amarok<br>
development work.</blockquote><div><br>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)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">It's also worth noting that Github is closed source,<br>
so if people are uncomfortable with that, they should be looking at<br>
Gitorious or some such thing.<br>
</blockquote></div><br>Valid point which I agree with.<br><br>-- <br>Magnus Bergmark - magnus DOT bergmark AT gmail DOT com<br>GPG/PGP: 0x7BE84794DB6AA648<br>Fingerprint: 0E6F D2DB F0EF 534A 2184 52AF 7BE8 4794 DB6A A648<br>