On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote: [snip] > We cannot change the behavior of push.default = simple already, so at least > that option is not in question. True. > Presumably you are worried about the other options that can't be enabled in any > way. Yes. > But think about this; you are worried that if we add an *option* to enable this > new behaviors, then we would be kind of forced to keep these behaviors. That > seems to imply that you are proposing the current default; we wait until 2.0 > and not make it an *option*, but make it *default*. > > I think waiting until 2.0 to make it a default without evern having an option, > and thus nobody actuallly testing this, is way worst than what I'm proposing; > to add an option to start testing. My concern is that people don't treat it for what it is--a way to experiment with the new behaviors--and then they get upset if we discover that some behavior was not well thought out and it disappears "unexpectedly" when we correct the matter. We have a balance to strike: annoying users and getting some miles on the new behaviors. I see the technical end of this--your proposal to have a 'core.mode'--but where is the non-technical end of this argument? What message are we proposing to send to the users? What's our promise to them surrounding core.mode and the new behaviors it offers? Perhaps we don't have much today that this affects, but what about tomorrow? Are we saying that behaviors enabled by core.mode=next are concrete (they're going in as-is, and we won't alter their behavior before 2.0)? As I said, the only real drawback is that I see this as the latter, because any other choice means users will get annoyed when something changes out from under them. >> So, at the end of the day, I'm just not sure it's worthwhile to have. > > This is exactly what happened on 1.6; nobody really tested the 'git foo' > behavior, so we just switched from one version to the next. If you are not > familiar with the outcome; it wasn't good. You're right, I wasn't around for that. And on the whole, I absolutely agree: it's nice to get miles on these new behaviors/features/etc. I just worry that having an option like this means we've committed to it, and I'm not sure that we want to give up the ability to change them without having to go through some sort of deprecation cycle. Or worse, we have to wait until 3.0 and 2.0 hasn't even come out yet. I hope others chime in here. And don't mistake me as dissenting; I'm not. And, I'm not assenting either. I just want to know if you've thought about what this means to users, and what we're prepared to deal with. Right now, I feel like half the argument around the option is missing. > So I say we shouldn't just provide warnings, but also have an option to allow > users (probably a minority) to start testing this. "probably a minority" -- I guess that's the part I disagree with. I'm not sure what a minority means here, but I don't think it'll be a handful of people. How big does that number get before we get concerned about backlash from users if we decide to change course? Or, is that simply not an issue? Why or why not? I have to be honest, if the option was available, I'd have my developers turn it on. I'm sure a great deal of others would do so too. Is there some other way we can solve this? Having an experimental branch with all the 2.0 features merged and those concerned can just build that version? I see the downside of that too: it's not as easy for people to try, and there is nothing preventing folks from posting binaries with the new behaviors enabled. It leads me to feeling that we're stuck in some regard. But maybe I'm being overly pessimistic here, and it's really all a non-issue. As I said earlier, it'd be nice if others chimed in here. -John -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html