If nothing else, we could take care of a lot of the confusion with a really good set of pages on the wiki that explain how to use git and how to do things in git that we used to do in svn. There are a bunch of git cheatsheets and svn-to-git cheatsheets, but they're all a bit lacking.
On Dec 11, 2010, at 5:46 PM, Sean Coates wrote: > 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 -- 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
