On Tue, Oct 15, 2013 at 11:03:26PM -0500, Felipe Contreras wrote:
> > not some "next" behavior that may change in future.
> But I'm suggesting to add a core.addremove option as well, like you suggested,
> am I not?
Yes, I think we both agreed on adding core.addremove. I'm just not
convinced if we should also add core.mode.
> So you would be happy if we had core.addremove = true *and* core.mode = next,
> right? You would use one, different people with different needs would use the
Yes, if there are people that will use core.mode it will be worth
adding. I'm just not one of them.
> > > > That's safer than next (at least for interactive use) and maybe more
> > > > users
> > > > would use that, but I don't think that's worth adding.
> > >
> > > Maybe, but I don't think many users would use either mode, and that's
> > > good.
> > >
> > > > For me, old behavior by default and warnings with information how to
> > > > enable new incompatible features, is sufficient. So I don't need
> > > > core.mode option, but as long it will be useful for other users I have
> > > > nothing against it.
> > >
> > > OK, but that seems to mean you don't need core.mode = next-warn either.
> > > I'm not
> > > against adding such a mode, but I would like to hear about _somebody_ that
> > > would like to actually use it. I don't like to program for ghosts.
> > >
> > As I said earlier, I don't think that next-warn it's worth adding, but
> > such option might increase the number of people interested in the
> > core.mode.
> Well that's a hypothesis, and I would be interested in finding out if that's
> true, but until I see somebody that says "I want core.mode = next-war", I'm
> going to assume they are hypothetical.
Yes, that's just a hypothesis.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html