[ruby-core:21039] Happy new year and... moving Ruby development to Git?

Hello,

On Wed, Jan 7, 2009 at 1:59 AM, Yukihiro Matsumoto <matz@...> wrote:

> Hi,
>
> In message "Re: [ruby-core:21165] Re: Happy new year and... moving Ruby development to Git?"
>    on Tue, 6 Jan 2009 18:29:44 +0900, Sylvain Joyeux <sylvain.joyeux@...> writes:
>
> |This is mainly because non-trivial patches (and even trivial ones) tend
> |to stay quite long in the bug tracker. Which means that you basically
> |have, as a non-committer, to update your patch over and over again to
> |the newest HEAD. I did that with svn, it is horrible (you have to do it
> |by hand). I do that now with git and it works like a charm (thanks to
> |rebase).
>
> As far as I believe issues and patches posted Redmine need not to
> update to the latest.  The committers will do.  Most of left out
> changes are just posted to the list.

Of course, git makes the work easier for the committers too (git
patches are often able to automatically resolve conflicts doing the
appropriate three-way merges). And the patch author gets the benefit
of his or her name in the log ;-)

> |Another thing: maintaining the ChangeLog file. This thing looks very
> |stupid, and makes merging horrible (you basically always have a conflict
> |on ChangeLog, for obvious reasons). I thought first that it was a
> |workaround from the good'ol days of CVS and even started to write a
> |script that would generate it. Then I realized that it was not doable
> |with SVN since there are no merges. Stupid.
>
> We have a tool to do the ChangeLog merge, so let us do the merge, just
> post the ChangeLog entry for the patch.

With git, the changelog can be easily created automatically.

By the way, are these tools (such as the ChangeLog merge tool you
mentioned) available somewhere?

> None the less, we could prepare the git repository synchronized with
> the central repository.  Yugui already has one anyway.

There are also a couple of git mirrors of the svn repository on
github.  It would be nice to have e.g. Yugui's repo (or any other)
elected to be the official mirror and pubished somewhere (possibly on
github and/or gitorious too), with a link from
http://www.ruby-lang.org/en/community/ruby-core/

(by the way, http://www.ruby-lang.org/en/downloads/ still mentions CVS
instead of SVN)
(by the way #2, http://kitenet.net/~joey/rfc/rel-vcs/ proposes a <link
rel=vcs> microformat to add to webpages the reference repositories,
you might want to consider adding it)


--
Giuseppe "Oblomov" Bilotta

Hello,

On Wed, Jan 7, 2009 at 1:55 PM, Michael Klishin
<michael.s.klishin@...> wrote:

>
> On 07.01.2009, at 3:59, Yukihiro Matsumoto wrote:
>
>> None the less, we could prepare the git repository synchronized with
>> the central repository.
>
>
> Matz,
>
> But what repository will core committers check into? Subversion or Git?
> Read-only clone of Git is far less useful than a Git repository where
> development happens,
> because it means changes are still shared as patches, so when people apply
> them, there is no history of changes, and it is always a lot of manual work
> for people
> who want to try out those changes.
>
> I just decided to ask so there are no fault expectations set.

I'm not Matz, but I would say that an official git mirror of the svn
repository is a necessary first step to begin a possible transition to
the new vcs. As has already been mentioned in this discussion,
switching to a different vcs is not something you do snapping your
finger, so there has to be a transition period where the new one is
nothing more than a mirror of the old one.

--
Giuseppe "Oblomov" Bilotta

[evolving_jerk]

On 07.01.2009, at 16:14, Giuseppe Bilotta wrote:

> I'm not Matz, but I would say that an official git mirror of the svn
> repository is a necessary first step to begin a possible transition to
> the new vcs


There are already read-only mirrors. They make little sense: the  
reason to switch is that with git and github even complex flow of  
patches simpler to handle that simple cases like Brett's patches with  
SVN/diff/patch.

diff/patch do not have history of changes, so a person who does the  
merge must take care and keep that history in one's head. It stops a  
lot of people from even trying to contribute, since they unconsciously  
feel how fun it's gonna be for others to manage a couple of giant  
patches (remember, you have no local commits).

This happens unconsciously. With Git, you just fork Ruby on GitHub, do  
the work incrementally and send a link to your branch to ruby-core,  
and people have all the history provided by the tool, and don't have  
to keep patches order and who sent them in their heads.

This is my personal perspective of the way things are. I may be  
totally wrong. But I still think that keeping main repository in  
Subversion and providing "official git mirror" makes no sense at all,  
since it won't really change the way contributions are made.

MK

On Wed, Jan 7, 2009 at 3:04 PM, Michael Klishin
<michael.s.klishin@...> wrote:

>
> On 07.01.2009, at 16:14, Giuseppe Bilotta wrote:
>
>> I'm not Matz, but I would say that an official git mirror of the svn
>> repository is a necessary first step to begin a possible transition to
>> the new vcs
>
>
> There are already read-only mirrors. They make little sense: the reason to
> switch is that with git and github even complex flow of patches simpler to
> handle that simple cases like Brett's patches with SVN/diff/patch.
>
> diff/patch do not have history of changes, so a person who does the merge
> must take care and keep that history in one's head. It stops a lot of people
> from even trying to contribute, since they unconsciously feel how fun it's
> gonna be for others to manage a couple of giant patches (remember, you have
> no local commits).
>
> This happens unconsciously. With Git, you just fork Ruby on GitHub, do the
> work incrementally and send a link to your branch to ruby-core, and people
> have all the history provided by the tool, and don't have to keep patches
> order and who sent them in their heads.
>
> This is my personal perspective of the way things are. I may be totally
> wrong. But I still think that keeping main repository in Subversion and
> providing "official git mirror" makes no sense at all, since it won't really
> change the way contributions are made.

Sorry, I don't agree. Having one single official mirror of the ruby
repository, instead of a number of unofficial, community-provided
repository means that you can in fact start working on your own github
forks: even though obviously the full power of the git and github
tools cannot be exploited for the patch workflow, it would still be
possible for e.g. Brent to keep his MBARI patchset in a branch of his
fork of the official git mirror, easying access to the rest of the
community.

Of course it wouldn't be the perfect solution until the full
transition to git is done, but, as I said, it's a necessary first
step. Moreover, as the git mirror would probably get a LARGE user base
to switch, it's likely to be a big point in favour of the switch.


--
Giuseppe "Oblomov" Bilotta

[Luis Lavena]

On Tue, Jan 6, 2009 at 2:43 PM, mathew <meta@...> wrote:

> On Sun, Jan 4, 2009 at 13:08, Michael Klishin <michael.s.klishin@...>
> wrote:
>>
>> On 04.01.2009, at 21:53, mathew wrote:
>>>
>>> Yes, we should definitely take advice on working practices from the
>>> people developing Perl 6...
>>
>> If you read the post, it was Perl 5 that moved to Git.
>
> Well, in that case... We should definitely take advice on working practices
> from the people maintaining a project which is in maintenance mode and no
> longer undergoing heavy refactoring.
>
> On Mon, Jan 5, 2009 at 05:09, Luis Lavena <luislavena@...> wrote:
>>
>> Anyhow, what is the point of this discussion? How many Windows users
>> will hack in the Ruby source code?
>>
>> And those who does, I guess they are quite command-line savvy.
>
> I nominate you to tell Austin Ziegler that he needs to start using Cygwin.
> I'll be over here behind the plexiglass shielding.
>
>

My statement was a sarcasm. I myself send fixes to Ruby C code that
doesn't behave properly on native Windows (not cygwin).

Those who do that are quite savvy in the command line, not noobs. I
use msysGit on a daily basis and perform almost all the tasks that can
be done, including committing using the Git GUI.

So... I personally don't see Git on Windows a limitation anymore, even
less than certain MinGW patches were integrated in Git 1.6 and later.

--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

On Mon, Jan 5, 2009 at 6:45 PM, Florian Gilcher <flo@...> wrote:

> On Jan 5, 2009, at 5:29 PM, Giuseppe Bilotta wrote:
>
>> Although I've never used darcs, the inability to properly handle
>> branches was actually one of the reasons why I gladly moved away from
>> mercurial (my first dscm).
>>
>> The upside of git is that it doesn't _force_ you to work with separate
>> checkouts for separate branches, although you _can_ do it: just clone
>> the local repo --git is even smart enough to hardlink blobs when
>> possible. I say this is a strong vote in favour of git, as it allows
>> both branching workflows (in-place and separate checkout).
>
> 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?

> 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

> 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.

> 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

> 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.

It *is* to be said that my experience with git started with 1.5.x
versions, which (from what i've read), made gigantic steps forward in
the UI from 1.4.x and earlier, so I possibly spared myself the initial
scare ealry adopters might have had. So maybe the revolution is
already over ;-)



--
Giuseppe "Oblomov" Bilotta

[James Gray-7]

On Jan 7, 2009, at 7:04 AM, Giuseppe Bilotta wrote:

> (by the way, http://www.ruby-lang.org/en/downloads/ still mentions CVS
> instead of SVN)

Fixed.

James Edward Gray II

[Paul Brannan]

On Wed, Jan 07, 2009 at 04:03:12AM +0900, James Gray wrote:
> Here's what I liked:
>
> http://blog.grayproductions.net/articles/getting_git_thanks_to_peepcode
>
> James Edward Gray II

Proxy Error

The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /articles/getting_git_thanks_to_peepcode.

Reason: Error reading from remote server

[James Gray-7]

On Jan 7, 2009, at 12:17 PM, Paul Brannan wrote:

> On Wed, Jan 07, 2009 at 04:03:12AM +0900, James Gray wrote:
>> Here's what I liked:
>>
>> http://blog.grayproductions.net/articles/getting_git_thanks_to_peepcode
>>
>> James Edward Gray II
>
> Proxy Error

The links seems to work for me right now.  I'm not super what's up  
there. Try again is my best suggestion.

James Edward Gray II

[Paul Brannan]

On Thu, Jan 08, 2009 at 03:49:13AM +0900, James Gray wrote:
> The links seems to work for me right now.  I'm not super what's up  
> there. Try again is my best suggestion.
>
> James Edward Gray II

Working for me now too, thanks. :)

Paul

> It *is* to be said that my experience with git started with 1.5.x
> versions, which (from what i've read), made gigantic steps forward in
> the UI from 1.4.x and earlier, so I possibly spared myself the initial
> scare ealry adopters might have had. So maybe the revolution is
> already over ;-)
I can tell you that it is the case. I have actually been scared away from git
because a friend of mine told me about it in the 1.4 time (I was using darcs
at the time). Then later on I tried it again. Much MUCH better.

Sylvain

[Florian Gilcher]

-----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  
> <flo@...> 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" ;) ).

>> 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.

>> 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.

But in general, the darcs CLI is very though out and infomative. Thats  
what i like about it.

>> 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.

>> 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. 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).

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.

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.

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.

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.

Regards,
Florian

[1]: For example "Why git is better than X", where you still have to  
skim through the HTML comments to see whats actually _bad_ about  
git ;). And it states windows support.
[2]: But I also don't buy that it is worthless.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkll3oMACgkQyLKU2FMxSOJWDQCfcA8EtT3KkOB5FhiQOURb3j66
gm4AnRtPf6ojguNLBUBgsiD45sda0Pyl
=pXUN
-----END PGP SIGNATURE-----

On Thu, Jan 8, 2009 at 12:07 PM, Florian Gilcher <flo@...> 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 <flo@...>
>> 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

[evolving_jerk]

On 08.01.2009, at 15:24, Giuseppe Bilotta wrote:

> 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?


Imagine that in git all the commands that take -i switch (commit,  
merge, rebase, ...) use it by default,
and you pick hunks/patches all the time.

I personally found it annoying, but some like it.

MK