On Sat, Sep 08, 2007 at 04:47:31PM +0300, Kalle Vahlman wrote: > 2007/9/8, Olav Vitters <[EMAIL PROTECTED]>: > > On Sat, Sep 08, 2007 at 05:56:38AM -0400, Kevin Kubasik wrote: > > Let's summarize it as: I don't know any D-SCM :-) (only investigate by > > checking out docs) > > (but I am also not interested in learning a SCM) > > Hopefully that doesn't translate "I don't know and I don't care"...
It translates to: I really care about not needing to learn an SCM. Take for example the output of 'git' push Update remote refs along with associated objects That to me is a 'wtf?' (1.5.2). > > For me, I consider the "you don't change directories for each branch you > > make" a drawback. I find directories as branches easier to understand (I > > hated this in CVS). > > There's some tools to visualize the branch history in git, which > includes more information than just "this is a branch". > > > > mkdir projdir && cd projdir > > > git clone ssh://[EMAIL PROTECTED]/git/coolproject/kkubasik > > > git branch newcoolfeature > > > git checkout newcoolfeature > > > > I don't like this checkout step. > > You can merge it with the branch command if you like: > > git checkout -b newcoolfeature It is not about one command. One dir per branch is perfectly understandable for me. > > > <write an awesome feature> > > > git commit -a > > > > Is the confusing way removed? If I do git-<TAB> I see 'Display all 144 > > possibilities'. Why so many? > > Because that's how git is structured. It's a collection of little > tools to do specific tasks. You'll likely use 4-5 of them in normal > developer tasks. Also, invoking 'git' gives you the most common ones. > If you do svn<TAB> there's only one useful command out of 9 (on my > machine) and it doesn't tell what it does either just by looking at > the name. Does that really mean anything? Equivalent of git-<TAB> is not svn<TAB>, it is svn-<TAB>. I mean that there is too much stuff that gets in the way. > And furthermore, looking at git commands is absolutely the worst way > to start learning git. Specially when coming from SVN, git commands as > they are will make no sense at all. But, when you read up and look at > few pretty pictures about how git works (like in > http://eagain.net/articles/git-for-computer-scientists/ ), they start > to make sense and you'll see how they turn SCM from just storing > snapshots of file states to actual tool for managing a project and > it's changes. I didn't have to learn SVN. > And this all is naturally from the developer/maintainer POV, as > translators and documentors do not benefit from this as much. But as > the general opinion seems to be, they shouldn't be forced to use SCM:s > directly anyway. That is a theoretical discussion. Ideally GNOME has a D-SCM now and all translators use a websystem that automatically translators. It doesn't exist. Although there is now some progress towards D-SCM, I don't see such a websystem happening. Also am not sure if a websystem is the most appropriate way. > > Easy stuff should be easy, hard stuff > > should be harder (otherwise the easy stuff is confusing). I never liked > > CVS, but I like SVN.. easy to understand. > > There was great commotion about people not wanting to switch to svn > because they had to learn new SCM. I bet nobody today wants to go back > to CVS though, and it is bound to be the same for the next step too... Git is not SVN. On the Bugzilla account, I started out with: alias cvs='svn' because I wanted to prevent someone typing in the wrong commands. It is pretty similar (CVS/SVN commands). There is no need for me to learn a D-SCM. I'm perfectly happy if git commit would first try to commit remotely, and if that fails, locally. That is the kind of D-SCM I'd like (probably pretty unique in that). > > Anyway, I think you forgot the 'push'. > > > > > Now you have 2 branches (the original, and newcoolfeature) where new > > > cool feature has your changes. > > > > Is it easy enough if you want to avoid branches? I usually work on > > trunk, nothing else (I do understand people want better merging than > > available in SVN). > > Even more pleasant as you "own" the cloned repo and nothing happens on > the central server until you really want it to. > > But I guess that's for the "newbie-committee" to decide if there ever > will be one... -- Regards, Olav _______________________________________________ foundation-list mailing list foundation-list@gnome.org http://mail.gnome.org/mailman/listinfo/foundation-list
