From: Giuseppe Bilotta Date: 2009-01-08T21:24:11+09:00 Subject: [ruby-core:21219] Re: Happy new year and... moving Ruby development to Git? On Thu, Jan 8, 2009 at 12:07 PM, Florian Gilcher wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On Jan 7, 2009, at 5:23 PM, Giuseppe Bilotta wrote: > >> On Mon, Jan 5, 2009 at 6:45 PM, Florian Gilcher >> wrote: >>> >>> On Jan 5, 2009, at 5:29 PM, Giuseppe Bilotta wrote: >>> >>> I'm on the "i don't want to think to much about it" or "lazy bastard" >>> side. >> >> Me too. >> >>> For example, one of my main reasons for darcs is it's nice cherry-picking >>> interface that is the _default_ way of handling it. Sure, i could use git >>> cherry-pick and friends, but Darcs gives me the collection of features I >>> really like at my fingertips. >> >> Out of curiosity, what's so special about darcs cherry-picking interface? >> > > Nothing really special, just that it flows nicely and is the default way of > interaction. So you don't have to decide to cherry-pick, you have to decide > _not_ to cherry-pick. It's not "advanced usage". If it was, I wouldn't use > it (see the "lazy bastard" ;) ). As I said, I haven't used darcs, but it being the default way of interaction means what? That the most documented function to transfer patches is cherry-pick instead of (semi)automatic merge? >>> Also, I tend not to play with branches too much, but only push the >>> patches I >>> really want back to upstream/trunk. Thats the default way in darcs. >> >> The default in darcs is that you have to choose which commits to push >> upstream everytime you push? And that's a plus? 8-D > > It is. Thats their way of doing "quick branches". Say, you somehow developed > two independent features in parallel on the same branch, you can then opt > not to include one of them on the upstream. As long as they are independent, > you are totally allowed to do that. > > It also forces you to somehow think about your patches again. So the typical > problem with "oh ****, I accidentally included a patch I didn't want to > push" vanishes. That makes pushing more work, so I suspect you're not so lazy really ;-) >>> Sure, I could push git into my workflow, but that would mean I would have >>> to >>> costumize git everytime I change computers. It does a lot, but i only >>> need >>> half of it and it always takes me time to figure out which half I wanted >>> to >>> use. >> >> Why would you need to customize git? Having a different workflow with >> it doesn't mean having to change git parameters, it just means using >> it in a different way. > > Well, pushing some features into view more prominently, like having an alias > for "git cherry-pick" and so on. In my experience, git has a pretty equal > distribution for all workflows. That means that my preferred one doesn't > really stand in the back, but it's also not up front. I am a fan of > specialized software. So I want one where my workflow stands in front ;). > So git doesn't fit my needs, darcs does. No offense. None taken. It's not like git is a religion for me ;-) I don't quite see the point of having an alias for a command, unless you mean that you would prefer a shorter form (git cp instead of git cherry-pick) ... aliases make sense for abstruse subcommands, not for commands in plain view. Maybe what would be nice to have is a "git for darcs users" intro/tutorial that summarizes the git commans equivalent to the darcs commands tipically used in the darcs workflow? > But in general, the darcs CLI is very though out and infomative. Thats what > i like about it. I'm sure the git developers wouldn't mind a couple of patches to bring darcs on part with darcs in terms of usability. Also, what version of git do you have experience with? I recently switched to 1.6 which is even better than 1.5 which (as I'm told) is light years ahead of 1.4, in terms of UI. >>> Also, if you allow both workflows, which link will you put on your >>> website? >>> ;) >> >> That's definitely up to whoever maintains the website 8-D >> > > So, that means that an interested committer has to adapt that. Assuming ruby WILL switch to git, I'm pretty sure that a contribution to that patch describing the darcs-style workflow would be appreciated >>> As I said before: your mileage may vary. I don't like git that much and I >>> also have a problem with hypes. So I would tend to wait until the >>> "revolution" is over. >>> But I support the democratic process ;). >> >> Honestly, I don't see this whole "hype" thing about git. >> >> If anything, I see a lot of FUD being spread about it, like for >> example its being extreeeeeemely complex and unfriendly and with an >> unfamiliar interface, which is something totally opposite to my >> experience: I didn't find it less friendly or less familiar than, say >> mercurial (of course there's the clear distinction between committing >> and pushing, but that's shared by all distributed vcs so it's only >> unfamiliar to people used to working with centralized vcs only); in >> fact, I found myself more comfortable with it than with hg. > > I didn't say that its extremly complex or explicitly unfriendly. It wasn't directed at you, but a general remark about some comments I've been reading in this list and elsewhere. > I have a > lot of stuff that I actually like about git (the vast collection of > transports to other upstreams, for example). But I also have the impression > that user friendlyness is not one of the gits main goals (which - > considering the type of programmer it was written for, is not very > surprising). As I mentioned, user friendlyness is being worked on, and proceeds very fast, especially since Linus isn't the lead developer anymore ;-). If you happen to use git for some projects, I recommend you to switch to 1.6+ as soon as possible, and if you have any additional suggestions about how it could be even more user friendly, asking on the git mailing list and/or the #git channel on freenode is likely to gather some attention. > I also know that there is some backlash happening at the moment, at least in > the set of people I often interact with. A not so small number of people I > know jumped on the git-wagon and moved back. Thats a typical sign of a hype. That would lead me to think that those people switched to git without taking the time to learn to use the tool properly, but that may just be my impression ;-) > I don't want to argue that git is bad. I just don't see it as the pinnacle > of VCS evolution as some people try to sell it.[1] My example with darcs was > to prove a point: the git glove doesn't fit for everyone. The SVN glove > doesn't, as well.[2] Same goes for hg and bzr. Hm. As far as hg goes, and from my experience, I can't think of anything that hg offers that git doesn't, both in terms of features and in terms of UI, so I wouldn't be so sure. I can't talk about brz (like I can't talk about darcs) because I have never used them. SVN has the big deficit of not being distributed, which is an essential point IMHO. > Another word to the discussion. Switching to git doesn't fix the biggest > problems in patch interaction. I forked some projects and sent patches to > their core, just to find out that they were inable to discuss the problems > at hand. In that respect, the o so nice distributed model kind of never > worked for me, because the theory didn't match with reality. If I see people > complaining about patches that never get applied: thats no SVN problem. Ah, that's for sure. No tool can supplant the availability of developers at incorporating patches from the outside. However, git _does_ make it easier to (1) keep private branches (2) rebase them (3) publishing the changes for others. > If they have to maintain their own branch and rebase it on head: git-svn > solves this problem already. So I don't see the point where git and only git > suddently makes ruby better. Well, git-svn doesn't solve the problem optimally, as it's somewhat clumsier to use than plain git, so having a git repository to begin with is definitely better, even if you just have to keep your own patches there forever. It also makes it easier for _others_ to rely on your changes on top of the official git (not svn) repository. This is why I say that having an official git repository, even if for the time being it's just a mirror of the svn repo, is an important step in the right direction. -- Giuseppe "Oblomov" Bilotta