I don't have any answers to Owen's questions on infrastructure changes, other than… (Answering Meller inline, too)
>> The one requirement I have is that all the code lives centrally (heh, the >> irony of "distributed" SCM) on the hp.o server, not in some third-party >> hosted service. > = Configuration and Users = > I have absolutely no experience setting up or maintaining a git repo. I like > user-based authentication in SVN because you don't have to worry about > exchanging SSH keys. If there were a web interface that allowed users to > manage the key on their own that would at least partially mitigate the > problem. I suspect that a lot of people contributing, particularly to > -extras, would not know how to create or share an SSH key, which would > further complicate the process of introducing new users to our system. I don't want to step on Owen's one requirement, but Github *would* take care of this for us, I think. > I also don't know what kind of permissions setups you can have. Is it > possible to grant users permission to push to a single branch like we do > currently while only a select group can push to 'master' (the 'trunk' of git)? This is a bit hard to explain. Software like gitosis (and I believe this is also how Github's "teams" functionality (which I'm currently using -— http://github.com/fictivekin/webshell </plug> ) works) manages permission on a per-repository basis, only. The fundamental difference to the norm we're used to with svn is that each clone becomes its own repository. I could create 1000 branches, locally, without ever affecting habari-master, even (especially) if I'm not a PMC member. > = Transport = > There's also the issue of how one accesses the repo. With our SVN setup > everything is over HTTP (or HTTPS), but git has SSH, GIT, or HTTP options. I > have no idea what the advantages of each are and there seems to be no pattern > to which transport is used by different projects / providers / configurations. I don't know of an our-own way to handle this (I really don't know about the infrastructure side; our team is small), but Github allows cloning over HTTP, so it's definitely possible. > = Merges = > I actually find merges significantly more difficult in git. Any time there's > any sort of conflict I just swear and abandon my changes, pull, and re-do it. > It seems git has no concept of conflict resolution, it just bails and makes > you fix it and won't do anything with the file until you've told it the > conflict is resolved. That annoys me. I agree with you to a certain extent. I'll admit that if you're used to resolving conflicts the traditional way, this is really confusing. This could definitely cause confusion with our users. I don't expect you to believe me until it happens to you (and I was in your camp until a few months ago), but git actually does make merging significantly easier. Using feature branches becomes a PLEASURE. Managing a master branch makes complex operations (such as partial rollbacks (removing a feature from a preview release), cherry-picking, and long-running feature merges) much simpler, once you get it. Getting it is the hard part. > This may be specifically more related to the lack of a good GUI client (or > even a good CLI client, I find the git command horribly obtuse and poorly > organized compared with the SVN client). If there were a client that easily > let me pick which file to use (mine or theirs) to resolve a conflict (or even > which specific changes of each file, which I think git supposedly supports?) > that would significantly decrease my frustration. I use the git command line client for work, probably 98% of the time. The other 2% is split between gitx (for tree visualization, log browsing, and commit searches) and FileMerge to resolve merge conflicts visually. The CLI git manual is cryptic. Unfortunately, it was written by people who already understand git. It makes sense to them. It doesn't make sense to those who don't, and when I reach for the manual, it's often because I don't understand the thing I'm trying to do. > == Fast-Forwards == > I can't tell you how many times I've had a "can't fast-forward" error when I > try to update. If you force the push you can end up with different "trees" > for no apparent reason. That's basically like having two completely different > repositories running side-by-side and I have no idea how you're supposed to > reintegrate them. Maybe git's supposed to handle that on its own, but it > didn't seem to. Yet another confusing thing that would totally screw you if > you didn't know how to handle it. For work, I've never, ever forced a push. We use a [pull, ]change, pull, push model. This might not scale well to large teams, but it works great for our team of 6 (we just ignore the merge commits); it might work fine for a limited set like the PMC. The alternative is change, rebase, push. Admittedly, I don't have much experience with the alternative model. > == Checkout, Rebase, Reset == > 90% of the time I have no clue which command does what I'm trying to do... > Usually what I want is 'reset' (the git version of 'revert'), but I also have > to include a parameter, rather than it just doing what I want it to do. It > seems that randomly I'll hit a problem and have to google for a solution, > read a couple of pages, and mix reset with one of the other two. Very > confusing and complex. Again, this is the kind of thing that makes more sense once you've been using git for a while. I don't deny that this would be confusing for those new to git. > = Branches = > I also still find branching in git confusing (and have no idea what the > actual difference between a branch and a tag is, though supposedly there is > one). Managing which branch you're on, checking out a different branch, > handling pushing / pulling between local and remote branches... There are a > lot of variables to take into account. With SVN there is only one: what did I > check out? This may also be related to the lack of a good client... Same as above. In my opinion, branches are far superior in Git. Sometimes things that are fundamentally better are harder than other things, and here's a good example. Keep in mind that SVN is significantly harder than saving text files to disk, and we all agree that it's worth the hassle of version control because the net value is far into the positive side. As an aside, if using Github is not an option, it might be worth keeping the main repository in SVN and using git-svn as an intermediary. I haven't used it, personally, and it's not as flexible as git (proper), but I've heard good things. Facebook uses git-svn internally, in this way. S -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev
