Keep in mind that I'm far, far, far from a Git aficionado, I've just been using it for a few months by myself for projects.
On Dec 11, 2010, at 4:25 PM, Owen Winkler wrote: > Yeah, weird for me to be starting this fight but... > > After reading the ongoing battle over on wp-hackers, I'm curious what the > pain would be to switch entirely over to Git for core and extras SCM. > > 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 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)? = 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. > So, could the people who are most enamored with the idea of using Git please > explain to the rest of us crotchety old svn users what the actual differences > would be for using git for SCM? > > I'm not talking about the "oh, your merges will be so much easier" crap, I'm > talking about actual potential pain points for the switch. For example: No > solid/stable Tortoise-like client for Windows. Need to reconfigure our > server-side stuff (like Trac) to handle it. = 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. 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. == 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. == 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. = 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... > It will be useful to compare those things to what people stuck in svn will > actually care about in order to make a decision about what to do and how to > mitigate the damage. My overall impressions? Git is great, it's the future. Note future, not present. It was designed by programmers for programmers and that shows. There are a million and one options and no clear "I want to do this, the command is x" pattern. Try and read the man page for the branch command and you'll wade through a dozen pages of text describing what happens if parameter1 is this and parameter2 is that, which is totally opposite from what happens if parameter1 is something else or there's a parameter3... We desperately need a good GUI client to wrap around these complexities and bring git to the masses. None of the existing clients even come close to meeting that bar. >From a day-to-day usage standpoint, I find that I make a lot of smaller >changes and commits with git simply because I can. I don't have to worry about >the first one breaking everything for the rest of the team as soon as I add >it, because I can wait until I've fully finished the feature to push upstream. >I think it makes my commits smaller and more easily understood because I'm >explaining a single change in each one, rather than 100 changes at the very >end in a subversion commit. That helps with self-documentation as I explain >why I'm making each individual change without having to devote 30 minutes to >writing a novel in the final commit message. Git was designed for use on what is quite probably the most complex application ever: the Linux kernel. I know that anyone contributing to kernel development is leaps and bounds smarter than I'll ever be, so it doesn't make the most sense for me to be using the same toolset they are. Subversion does its job relatively simply and very well. I don't think we're ready for a switch to git, subversion is the proper fit for our project... at least for the foreseeable future. -- 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
