Re: [PATCH v3] Add core.mode configuration
From: Jonathan Nieder jrnie...@gmail.com Philip Oakley wrote: Would this be a good time to suggest a specific wording should be proposed (or a reminder of what was proposed repeated) for the documentation of this option. It will be the documentation that users will refer to when they need to know, rather than the list discussions. It's not clear to me that this config item is a good idea. My point was that the arguments had been rehearsed and explored, and that it was possibly a suitable time for Filippe to update any commit message and config item documentation so that the proposal can be judged. What is the intended use? If someone wants to test that their scripts will continue to work with git 2.0, wouldn't testing a 2.0 release candidate (or the current state of the 'jch' branch until one exists) be the simplest way to do that? If someone just likes the proposed behavior changes and wants to start using them right away, maybe we can help them by releasing 2.0 sooner ;-), or by advertising the fairly simple changes in commandline usage to get the new behaviors: In terms of moving forward, there needs to be a balance between being stuck in the old world of the 60's, and being projected into the bright new world of the 20's (OK so I have exaggerated a bit there ;-). It's always been a case of different strokes for different folks - there will be folk who will try such an option (in an honest manner), who may not be aware of branches that are outside of the regular pu / next / master / maint branches which the project publicises. Rather than letting the email discussion degenerate by going round in circles to the usual end point, having a clarifying proposal (hopefully well balanced) would at least allow a cleaner understanding and decision. Instead of git add, use git add -A. When using git add -u or git add -A from a subdirectory of the toplevel, specify git add -u . explicitly unless you want it to apply to the whole tree (in which case use git add -u :/). Instead of letting git push guess, name the branch you want to push: git push origin master. Or set '[push] default = simple' in your configuration. Pass --prefix to git svn clone. The downside of configuration like the proposed core.next is that it is hard to explain (What do you mean that I can't roll back to the pre-2.0 behavior in Git 2.0 by setting this configuration setting to an appropriate value?), users or scripts can rely on it, and configuration variables tend to accumulate and never be removed. If we really want a run-time switch for this, I suspect an appropriately named environment variable would work better, since we have a history of being able to remove those without alarming people. My two cents, Jonathan -- 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
Re: [PATCH v3] Add core.mode configuration
Jonathan Nieder wrote: Philip Oakley wrote: Would this be a good time to suggest a specific wording should be proposed (or a reminder of what was proposed repeated) for the documentation of this option. It will be the documentation that users will refer to when they need to know, rather than the list discussions. It's not clear to me that this config item is a good idea. What is the intended use? If someone wants to test that their scripts will continue to work with git 2.0, wouldn't testing a 2.0 release candidate There is no 2.0 release candidate, and the window between the first 2.0 rc and 2.0 final is limited, such person might not have the time do such testing in that window. Moreover, it's not just to test their scripts, but also their fingers. (or the current state of the 'jch' branch until one exists) That doesn't work for the vast majority of users who do not compile Git. If someone just likes the proposed behavior changes and wants to start using them right away, maybe we can help them by releasing 2.0 sooner ;-) So basically you are advocating for another v1.6 fiasco, where users start complaining about the new behaviors *after* the release has been made, and their user experience has been broken. Is that the case? , or by advertising the fairly simple changes in commandline usage to get the new behaviors: Instead of git add, use git add -A. When using git add -u or git add -A from a subdirectory of the toplevel, specify git add -u . explicitly unless you want it to apply to the whole tree (in which case use git add -u :/). Instead of letting git push guess, name the branch you want to push: git push origin master. Or set '[push] default = simple' in your configuration. Pass --prefix to git svn clone. I don't get why you don't understand something so simple about human nature. Every teach knows that you don't just give a lecture, even if the student understands what you explained, most likely (s)he would not learn it until after doing excercises. 99% of our users have not read the release notes about the 2.0 changes, 98% will not read that advertizement you just said, 90% of those who read it will only get noise, and the ones that read and understand it, might change their minds once they experience it. That's why in every game conference they don't just explain to you the new game, they let you play it, only then the end users can give an honest opinion about the game. Perhaps it's unfortunate, but our users are human, and that's how humans work. We don't know if our users would be OK with the 2.0 changes, it's only after they have given it a try that they can honestly say, and it's better to give them as much time as possible and make it easier for them to try. The downside of configuration like the proposed core.next is that it is hard to explain (What do you mean that I can't roll back to the pre-2.0 behavior in Git 2.0 by setting this configuration setting to an appropriate value?), It is not hard to explain. core.mode = next enables the proposed behavior for the next major version of Git (v2.0), which might change. core.mode = current (the default) enables the behavior of the current version of Git (v1.x). It is implied that there's no core.mode = previous, but it can be explicitly stated. users or scripts can rely on it, and configuration variables tend to accumulate and never be removed. Not this one, because this one makes it clear that is volatile (although probably not that much). If we really want a run-time switch for this, I suspect an appropriately named environment variable would work better, since we have a history of being able to remove those without alarming people. The fact that B has done the job in the past, doesn't mean it would do the job better than A in the future. -- Felipe Contreras -- 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
Re: [PATCH v3] Add core.mode configuration
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 other. 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. Krzysiek -- 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
Re: [PATCH v3] Add core.mode configuration
On Tue, Oct 15, 2013 at 10:55:07PM -0500, Felipe Contreras wrote: John Szakmeister wrote: I like the idea that we could kick git into a mode that applies the behaviors we're talking about having in 2.0, but I'm concerned about one aspect of it. Not having these behaviors until 2.0 hits means we're free to renege on our decisions in favor of something better, or to pull out a bad idea. But once we insert this knob, I don't know that we have the same ability. Once people realize it's there and start using it, it gets harder to back out. I guess we could maintain the stance that the features are not concrete yet, or something like that, but I think people would still get upset if something changes out from under them. We cannot change the behavior of push.default = simple already, so at least that option is not in question. If we add core.addremove=true the same applies to it - we cannot remove it later, the only we can do is to disable it by default in future versions after testing (core.addremove=true or core.mode=next). 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. BTW, I'm still using pre-1.6 git-foo, I have /usr/libexec/git-core in my PATH. So I would like to always have an option to disable some new incompatible improvements. So I say we shouldn't just provide warnings, but also have an option to allow users (probably a minority) to start testing this. and an option to keep the old behavior, like we did with push.default. Krzysiek -- 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
Re: [PATCH v3] Add core.mode configuration
On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras felipe.contre...@gmail.com 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] Add core.mode configuration
On Wed, Oct 16, 2013 at 6:54 AM, John Szakmeister j...@szakmeister.net wrote: [snip] 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. Thinking about this a little more, we do have a proving ground. That's what the whole pu/next/master construct is for. So maybe this is a non-issue. By the time it lands on master, we should have decided whether the feature is worth keeping or not. -John -- 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
Re: [PATCH v3] Add core.mode configuration
Krzysztof Mazur wrote: 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. If we add core.addremove, all the issues you mentioned are solved. If we do that, now the question is, how exactly does core.mode = next affect anybody genatively? If you don't like it, you don't set it, that's why it's a configuration. I don't see the problem. 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 other. Yes, if there are people that will use core.mode it will be worth adding. I'm just not one of them. I am already using it. -- Felipe Contreras -- 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
Re: [PATCH v3] Add core.mode configuration
Krzysztof Mazur wrote: On Tue, Oct 15, 2013 at 10:55:07PM -0500, Felipe Contreras wrote: John Szakmeister wrote: I like the idea that we could kick git into a mode that applies the behaviors we're talking about having in 2.0, but I'm concerned about one aspect of it. Not having these behaviors until 2.0 hits means we're free to renege on our decisions in favor of something better, or to pull out a bad idea. But once we insert this knob, I don't know that we have the same ability. Once people realize it's there and start using it, it gets harder to back out. I guess we could maintain the stance that the features are not concrete yet, or something like that, but I think people would still get upset if something changes out from under them. We cannot change the behavior of push.default = simple already, so at least that option is not in question. If we add core.addremove=true the same applies to it - we cannot remove it later, the only we can do is to disable it by default in future versions after testing (core.addremove=true or core.mode=next). That is true, but adding core.addremove = true would probably imply there's the option of adding core.addremove = false. 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. BTW, I'm still using pre-1.6 git-foo, I have /usr/libexec/git-core in my PATH. So I would like to always have an option to disable some new incompatible improvements. That's what core.addremove = false would do, wouldn't it? So I say we shouldn't just provide warnings, but also have an option to allow users (probably a minority) to start testing this. and an option to keep the old behavior, like we did with push.default. Ditto. -- Felipe Contreras -- 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
Re: [PATCH v3] Add core.mode configuration
John Szakmeister wrote: On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras felipe.contre...@gmail.com 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. Yes, but that's like removing the --force option in rm, because the user might unexpectedly remove files (s)he didn't intend to. If the user uses rm --force, the user must know what (s)he is doing, that's just the way it is. Similarly, if a user does core.mode = next, the user is expecting to enable all future behaviors, because that's what core.mode = next does, if he doesn't want to do that, then why would he use that option? Particularily because there's push.default, and there would be core.addremove, and everything that core.mode = next does would be possible to do in other ways that are not going to introduce new behavior as the version of Git advances. 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)? I'd say we make it explicit that if you turn on core.mode = next, the behavior you experience is going to change from version to version. In other words, there is no backwards compatibility promise for the behaviors core.mode = next enables. In a way it's kind of experimental, except that it's very likely the new behavior won't be reverted back, just not 100% sure. 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. If the user doesn't want things to change dramatically, the user shouldn't use core.mode = next. 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, It doesn't meant we are committed to it, because the behaviors in core.mode = next have no promise to stay. Either way, these behaviors have been announce in each Git release for several releases, and we are already warning the users that things will change in v2.0. I'd say that already 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 don't see why we would be giving up that ability. 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. Of course I've thought about that, otherwise I wouldn't have sent the patch. But I have no hope of others chiming in. 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. How many people do you think want to start testing v2.0 behaviors? How many people do you think will enable core.mode = next? I'd say the people that test release candidates are the minority, and I'd say the wants that would turn on core.mode = next would be even less. I'm not sure what a minority means here, but I don't think
Re: [PATCH v3] Add core.mode configuration
John Szakmeister wrote: On Wed, Oct 16, 2013 at 6:54 AM, John Szakmeister j...@szakmeister.net wrote: [snip] 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. Thinking about this a little more, we do have a proving ground. That's what the whole pu/next/master construct is for. No, that's not true. 'next' doesn't contain experimental patches, it contains potentially dangerous one that might benefit from some testing before going to master, but they are certainly not experimental. 'pu' doesn't contain experimental code either, the code in 'pu' has to be feature complete. It might require a few more tunning patches, but it's not experimental, and those branches are not long lived. For example the pack-v4 patches could be merged today, and the people involved could keep working on top of that merge point, but that doesn't happen, because 'pu' is not for experimental stuff. There is no place in the Git repository for pack-v4, because there's no place for experimental patches. So maybe this is a non-issue. By the time it lands on master, we should have decided whether the feature is worth keeping or not. I believe without an experimental branch, many branches would never mature to go into master, or next, or even pu. -- Felipe Contreras -- 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
Re: [PATCH v3] Add core.mode configuration
From: Felipe Contreras felipe.contre...@gmail.com John Szakmeister wrote: On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras felipe.contre...@gmail.com wrote: [snip] Similarly, if a user does core.mode = next, the user is expecting to enable all future behaviors, because that's what core.mode = next does, if he doesn't want to do that, then why would he use that option? Would this be a good time to suggest a specific wording should be proposed (or a reminder of what was proposed repeated) for the documentation of this option. It will be the documentation that users will refer to when they need to know, rather than the list discussions. The too and fro discussion suggested that it would be important to present the chosen viewpoint well, so there would be no misunderstanding, such that 'users' of the mode realise that they are acting as testers, and there are no promises for the posterity of any trial behaviour, and they (the tester) have a 'caveat emptor' responsibility. And that they need to keep up with developments (list release notes) so that at any update they know what will disappear and appear without warning. Philip -- Felipe Contreras -- -- 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
Re: [PATCH v3] Add core.mode configuration
Philip Oakley wrote: Would this be a good time to suggest a specific wording should be proposed (or a reminder of what was proposed repeated) for the documentation of this option. It will be the documentation that users will refer to when they need to know, rather than the list discussions. It's not clear to me that this config item is a good idea. What is the intended use? If someone wants to test that their scripts will continue to work with git 2.0, wouldn't testing a 2.0 release candidate (or the current state of the 'jch' branch until one exists) be the simplest way to do that? If someone just likes the proposed behavior changes and wants to start using them right away, maybe we can help them by releasing 2.0 sooner ;-), or by advertising the fairly simple changes in commandline usage to get the new behaviors: Instead of git add, use git add -A. When using git add -u or git add -A from a subdirectory of the toplevel, specify git add -u . explicitly unless you want it to apply to the whole tree (in which case use git add -u :/). Instead of letting git push guess, name the branch you want to push: git push origin master. Or set '[push] default = simple' in your configuration. Pass --prefix to git svn clone. The downside of configuration like the proposed core.next is that it is hard to explain (What do you mean that I can't roll back to the pre-2.0 behavior in Git 2.0 by setting this configuration setting to an appropriate value?), users or scripts can rely on it, and configuration variables tend to accumulate and never be removed. If we really want a run-time switch for this, I suspect an appropriately named environment variable would work better, since we have a history of being able to remove those without alarming people. My two cents, Jonathan -- 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
Re: [PATCH v3] Add core.mode configuration
On Mon, Oct 14, 2013 at 04:35:50PM -0500, Felipe Contreras wrote: Krzysztof Mazur wrote: On Sat, Oct 12, 2013 at 02:04:45AM -0500, Felipe Contreras wrote: So that we can specify general modes of operation, specifically, add the 'next' mode, which makes Git pre v2.0 behave as Git v2.0. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- I don't think that single option it's a good idea. From the user's point of view I think that the way push.default was introduced and will be changed is much better. So maybe it's better to just add core.addremove option instead? Maybe, but what happens when we start doing changes for v3.0? As a user, I don't and to figure out which are the new configurations that will turn v3.0 behavior on, I just want to be testing that mode, even if I'm not following Git development closely. If I find something annoying with core.mode = next, I report the problem to the mailing list, which is good, we want to know problems with the backward-incompatible changes that will be introduced before it's too late, don't we? But with core.mode = next after upgrade you may experience incompatible change without any warning. I think it's better to keep the old behavior by default and warn the user if with new behavior the result might be different. So the user: a) knows about the change b) may set appropriate option to enable the new default or keep the old behavior and disable the warning c) may report that he does not like that change I'd be fine with having *both* a fine-tuned option to trigger each specific behavior, and another one that turns all those fine-tuned options on that are meant for v2.0. Unfortunately, I don't see much interest from Git developers in either. I think that most users have already set the push.default, so git add is the only problem. If Junio really wants to change git add he should be interested in allowing user to use it now. I don't see the change in git add as an improvement, because removing files with git add IMHO is more confusing than ignoring such files. Maybe introducing new command - git update for instance - which is equivalent to new git add and teaching new users to use it instead of git add is better. Krzysiek -- 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
Re: [PATCH v3] Add core.mode configuration
Krzysztof Mazur wrote: On Mon, Oct 14, 2013 at 04:35:50PM -0500, Felipe Contreras wrote: Krzysztof Mazur wrote: On Sat, Oct 12, 2013 at 02:04:45AM -0500, Felipe Contreras wrote: So that we can specify general modes of operation, specifically, add the 'next' mode, which makes Git pre v2.0 behave as Git v2.0. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- I don't think that single option it's a good idea. From the user's point of view I think that the way push.default was introduced and will be changed is much better. So maybe it's better to just add core.addremove option instead? Maybe, but what happens when we start doing changes for v3.0? As a user, I don't and to figure out which are the new configurations that will turn v3.0 behavior on, I just want to be testing that mode, even if I'm not following Git development closely. If I find something annoying with core.mode = next, I report the problem to the mailing list, which is good, we want to know problems with the backward-incompatible changes that will be introduced before it's too late, don't we? But with core.mode = next after upgrade you may experience incompatible change without any warning. Yes, and that is actually what the user wants. I mean, why would the user set core.mode=next, if the user doesn't want to experencie incompatible changes? A user that sets this mode is expecting incompatible changes, and will be willing to test them, and report back if there's any problem with them. I think it's better to keep the old behavior by default and warn the user if with new behavior the result might be different. So the user: a) knows about the change b) may set appropriate option to enable the new default or keep the old behavior and disable the warning c) may report that he does not like that change But that's what we are doing already. Look at the test I wrote, it's testing the warnings for the current version of Git. I'd be fine with having *both* a fine-tuned option to trigger each specific behavior, and another one that turns all those fine-tuned options on that are meant for v2.0. Unfortunately, I don't see much interest from Git developers in either. I think that most users have already set the push.default, so git add is the only problem. If Junio really wants to change git add he should be interested in allowing user to use it now. I agree, but he really wants the change, and proof of that is that the warning is already there, and every Git release since then has an annoying message about that at the top. I don't see the change in git add as an improvement, because removing files with git add IMHO is more confusing than ignoring such files. Maybe introducing new command - git update for instance - which is equivalent to new git add and teaching new users to use it instead of git add is better. I agree. At first I simply ignored the changes because I didn't have the patience to figure out what exactly did they mean. Now I was forced to understand them to write this patch, and I'm also forcing myself to use this behavior. 'git add' removing files is counter-intutive, 'git stage' (currently an alias to 'git add') might make more sense. But even better would be to use my proposed changes to 'git stage', which add subcommands, for example: * git stage all (git add --all) * git stage update (git add --update) But it doesn't seem that patch is going to be applied by Junio, so most likely we would have to deal with yet anotyer counter-intuitive behavior in Git. -- Felipe Contreras -- 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
Re: [PATCH v3] Add core.mode configuration
On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote: Krzysztof Mazur wrote: But with core.mode = next after upgrade you may experience incompatible change without any warning. Yes, and that is actually what the user wants. I mean, why would the user set core.mode=next, if the user doesn't want to experencie incompatible changes? A user that sets this mode is expecting incompatible changes, and will be willing to test them, and report back if there's any problem with them. With your patch, because it's the only way to have 'git add' v2.0. But if another git v2.0 incompatible change will be added it will not be warned, because with core.mode=next he decided to enable also future changes and that's why I would never set that. I think it's better to keep the old behavior by default and warn the user if with new behavior the result might be different. So the user: a) knows about the change b) may set appropriate option to enable the new default or keep the old behavior and disable the warning c) may report that he does not like that change But that's what we are doing already. Look at the test I wrote, it's testing the warnings for the current version of Git. With pull.default we did that, but with git add v2.0 now we only warn the user. With your patch he can enable new git add (and disable warning), but he also enables future incompatible changes and disables warnings for such changes. He also cannot keep the old behaviour and disable the warning. I don't see the change in git add as an improvement, because removing files with git add IMHO is more confusing than ignoring such files. Maybe introducing new command - git update for instance - which is equivalent to new git add and teaching new users to use it instead of git add is better. I agree. At first I simply ignored the changes because I didn't have the patience to figure out what exactly did they mean. Now I was forced to understand them to write this patch, and I'm also forcing myself to use this behavior. 'git add' removing files is counter-intutive, 'git stage' (currently an alias to 'git add') might make more sense. Yeah, 'git stage' as an alias to 'git add -A' is much more intuitive. Krzysiek -- 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
Re: [PATCH v3] Add core.mode configuration
Krzysztof Mazur wrote: On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote: Krzysztof Mazur wrote: But with core.mode = next after upgrade you may experience incompatible change without any warning. Yes, and that is actually what the user wants. I mean, why would the user set core.mode=next, if the user doesn't want to experencie incompatible changes? A user that sets this mode is expecting incompatible changes, and will be willing to test them, and report back if there's any problem with them. With your patch, because it's the only way to have 'git add' v2.0. Yeah, but that's not what I'm suggesting. I suggested to have *both* a fined-tunned way to have this behavior, say core.addremove = true, and a way to enable *all* v2.0 behaviors (core.mode = next). If we have both, and the user sets core.mode = next, that means the user wants *all* the incompatible changes. But if another git v2.0 incompatible change will be added it will not be warned, because with core.mode=next he decided to enable also future changes and that's why I would never set that. That's fine, you wouldn't set that, but I would. That's why it's a configuration. I think it's better to keep the old behavior by default and warn the user if with new behavior the result might be different. So the user: a) knows about the change b) may set appropriate option to enable the new default or keep the old behavior and disable the warning c) may report that he does not like that change But that's what we are doing already. Look at the test I wrote, it's testing the warnings for the current version of Git. With pull.default we did that, but with git add v2.0 now we only warn the user. With your patch he can enable new git add (and disable warning), but he also enables future incompatible changes and disables warnings for such changes. Yeah, but I suggested to have *both* a fine-tunned option and a general one, didn't I? He also cannot keep the old behaviour and disable the warning. He cannot do that regardless if my patch is merged or not. I don't see the change in git add as an improvement, because removing files with git add IMHO is more confusing than ignoring such files. Maybe introducing new command - git update for instance - which is equivalent to new git add and teaching new users to use it instead of git add is better. I agree. At first I simply ignored the changes because I didn't have the patience to figure out what exactly did they mean. Now I was forced to understand them to write this patch, and I'm also forcing myself to use this behavior. 'git add' removing files is counter-intutive, 'git stage' (currently an alias to 'git add') might make more sense. Yeah, 'git stage' as an alias to 'git add -A' is much more intuitive. Agreed. -- Felipe Contreras -- 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
Re: [PATCH v3] Add core.mode configuration
On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote: Krzysztof Mazur wrote: On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote: Krzysztof Mazur wrote: But with core.mode = next after upgrade you may experience incompatible change without any warning. Yes, and that is actually what the user wants. I mean, why would the user set core.mode=next, if the user doesn't want to experencie incompatible changes? A user that sets this mode is expecting incompatible changes, and will be willing to test them, and report back if there's any problem with them. With your patch, because it's the only way to have 'git add' v2.0. Yeah, but that's not what I'm suggesting. I suggested to have *both* a fined-tunned way to have this behavior, say core.addremove = true, and a way to enable *all* v2.0 behaviors (core.mode = next). I'm just not sure if a lot of users would use core.mode=next, because of possible different behavior without any warning. Maybe we should also add core.mode=next-warn that changes defaults like next but keeps warnings enabled until the user accepts that change by setting appropriate config option? 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. 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. Krzysiek -- 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
Re: [PATCH v3] Add core.mode configuration
On Tue, Oct 15, 2013 at 10:51 AM, Krzysztof Mazur krzys...@podlesie.net wrote: On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote: Krzysztof Mazur wrote: On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote: Krzysztof Mazur wrote: But with core.mode = next after upgrade you may experience incompatible change without any warning. Yes, and that is actually what the user wants. I mean, why would the user set core.mode=next, if the user doesn't want to experencie incompatible changes? A user that sets this mode is expecting incompatible changes, and will be willing to test them, and report back if there's any problem with them. With your patch, because it's the only way to have 'git add' v2.0. Yeah, but that's not what I'm suggesting. I suggested to have *both* a fined-tunned way to have this behavior, say core.addremove = true, and a way to enable *all* v2.0 behaviors (core.mode = next). I'm just not sure if a lot of users would use core.mode=next, because of possible different behavior without any warning. Maybe we should also add core.mode=next-warn that changes defaults like next but keeps warnings enabled until the user accepts that change by setting appropriate config option? 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. I like the idea that we could kick git into a mode that applies the behaviors we're talking about having in 2.0, but I'm concerned about one aspect of it. Not having these behaviors until 2.0 hits means we're free to renege on our decisions in favor of something better, or to pull out a bad idea. But once we insert this knob, I don't know that we have the same ability. Once people realize it's there and start using it, it gets harder to back out. I guess we could maintain the stance that the features are not concrete yet, or something like that, but I think people would still get upset if something changes out from under them. So, at the end of the day, I'm just not sure it's worthwhile to have. -John -- 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
Re: [PATCH v3] Add core.mode configuration
Krzysztof Mazur wrote: On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote: Krzysztof Mazur wrote: On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote: Krzysztof Mazur wrote: But with core.mode = next after upgrade you may experience incompatible change without any warning. Yes, and that is actually what the user wants. I mean, why would the user set core.mode=next, if the user doesn't want to experencie incompatible changes? A user that sets this mode is expecting incompatible changes, and will be willing to test them, and report back if there's any problem with them. With your patch, because it's the only way to have 'git add' v2.0. Yeah, but that's not what I'm suggesting. I suggested to have *both* a fined-tunned way to have this behavior, say core.addremove = true, and a way to enable *all* v2.0 behaviors (core.mode = next). I'm just not sure if a lot of users would use core.mode=next, I'm not sure if a lot of urser would even notice the difference. because of possible different behavior without any warning. I don't see what is the problem. We haven't had the need for push.default = simplewarning, have we? If you want the warning, you don't change anything, if you want to specify something, you already know what you are doing. Maybe we should also add core.mode=next-warn that changes defaults like next but keeps warnings enabled until the user accepts that change by setting appropriate config option? Maybe, but would you actually use that option? 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. Cheers. -- Felipe Contreras -- 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
Re: [PATCH v3] Add core.mode configuration
John Szakmeister wrote: On Tue, Oct 15, 2013 at 10:51 AM, Krzysztof Mazur krzys...@podlesie.net wrote: On Tue, Oct 15, 2013 at 08:29:56AM -0500, Felipe Contreras wrote: Krzysztof Mazur wrote: On Tue, Oct 15, 2013 at 07:32:39AM -0500, Felipe Contreras wrote: Krzysztof Mazur wrote: But with core.mode = next after upgrade you may experience incompatible change without any warning. Yes, and that is actually what the user wants. I mean, why would the user set core.mode=next, if the user doesn't want to experencie incompatible changes? A user that sets this mode is expecting incompatible changes, and will be willing to test them, and report back if there's any problem with them. With your patch, because it's the only way to have 'git add' v2.0. Yeah, but that's not what I'm suggesting. I suggested to have *both* a fined-tunned way to have this behavior, say core.addremove = true, and a way to enable *all* v2.0 behaviors (core.mode = next). I'm just not sure if a lot of users would use core.mode=next, because of possible different behavior without any warning. Maybe we should also add core.mode=next-warn that changes defaults like next but keeps warnings enabled until the user accepts that change by setting appropriate config option? 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. I like the idea that we could kick git into a mode that applies the behaviors we're talking about having in 2.0, but I'm concerned about one aspect of it. Not having these behaviors until 2.0 hits means we're free to renege on our decisions in favor of something better, or to pull out a bad idea. But once we insert this knob, I don't know that we have the same ability. Once people realize it's there and start using it, it gets harder to back out. I guess we could maintain the stance that the features are not concrete yet, or something like that, but I think people would still get upset if something changes out from under them. We cannot change the behavior of push.default = simple already, so at least that option is not in question. Presumably you are worried about the other options that can't be enabled in any way. 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. 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. So I say we shouldn't just provide warnings, but also have an option to allow users (probably a minority) to start testing this. -- Felipe Contreras -- 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
Re: [PATCH v3] Add core.mode configuration
Krzysztof Mazur wrote: On Tue, Oct 15, 2013 at 01:51:41PM -0500, Felipe Contreras wrote: I don't see what is the problem. We haven't had the need for push.default = simplewarning, have we? If you want the warning, you don't change anything, if simplewarning makes no sense, because push.default=simple sets exact behavior, Exactly. 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? That option wouldn't change in the future. you want to specify something, you already know what you are doing. Maybe we should also add core.mode=next-warn that changes defaults like next but keeps warnings enabled until the user accepts that change by setting appropriate config option? Maybe, but would you actually use that option? No. 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 other. 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. -- Felipe Contreras -- 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
Re: [PATCH v3] Add core.mode configuration
On Sat, Oct 12, 2013 at 02:04:45AM -0500, Felipe Contreras wrote: So that we can specify general modes of operation, specifically, add the 'next' mode, which makes Git pre v2.0 behave as Git v2.0. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- I don't think that single option it's a good idea. From the user's point of view I think that the way push.default was introduced and will be changed is much better. So maybe it's better to just add core.addremove option instead? Krzysiek -- 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
Re: [PATCH v3] Add core.mode configuration
Krzysztof Mazur wrote: On Sat, Oct 12, 2013 at 02:04:45AM -0500, Felipe Contreras wrote: So that we can specify general modes of operation, specifically, add the 'next' mode, which makes Git pre v2.0 behave as Git v2.0. Signed-off-by: Felipe Contreras felipe.contre...@gmail.com --- I don't think that single option it's a good idea. From the user's point of view I think that the way push.default was introduced and will be changed is much better. So maybe it's better to just add core.addremove option instead? Maybe, but what happens when we start doing changes for v3.0? As a user, I don't and to figure out which are the new configurations that will turn v3.0 behavior on, I just want to be testing that mode, even if I'm not following Git development closely. If I find something annoying with core.mode = next, I report the problem to the mailing list, which is good, we want to know problems with the backward-incompatible changes that will be introduced before it's too late, don't we? I'd be fine with having *both* a fine-tuned option to trigger each specific behavior, and another one that turns all those fine-tuned options on that are meant for v2.0. Unfortunately, I don't see much interest from Git developers in either. -- Felipe Contreras -- 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
[PATCH v3] Add core.mode configuration
So that we can specify general modes of operation, specifically, add the
'next' mode, which makes Git pre v2.0 behave as Git v2.0.
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
builtin/add.c | 13
cache.h| 6 ++
config.c | 13
environment.c | 1 +
t/t2205-add-new.sh | 60 ++
5 files changed, 89 insertions(+), 4 deletions(-)
create mode 100755 t/t2205-add-new.sh
diff --git a/builtin/add.c b/builtin/add.c
index 8266a9c..95a396d 100644
--- a/builtin/add.c
+++ b/builtin/add.c
@@ -483,14 +483,16 @@ int cmd_add(int argc, const char **argv, const char
*prefix)
*/
memset(update_data, 0, sizeof(update_data));
if (!take_worktree_changes addremove_explicit 0)
- update_data.warn_add_would_remove = 1;
+ if (git_mode == MODE_CURRENT)
+ update_data.warn_add_would_remove = 1;
if (!take_worktree_changes addremove_explicit 0 argc)
/*
* Turn git add pathspec... to git add -A pathspec...
* in Git 2.0 but not yet
*/
- ; /* addremove = 1; */
+ if (git_mode != MODE_CURRENT)
+ addremove = 1;
if (!show_only ignore_missing)
die(_(Option --ignore-missing can only be used together with
--dry-run));
@@ -503,10 +505,13 @@ int cmd_add(int argc, const char **argv, const char
*prefix)
short_option_with_implicit_dot = -u;
}
if (option_with_implicit_dot !argc) {
- static const char *here[2] = { ., NULL };
+ static const char *here[2] = { :/, NULL };
argc = 1;
argv = here;
- implicit_dot = 1;
+ if (git_mode == MODE_CURRENT) {
+ here[0] = .;
+ implicit_dot = 1;
+ }
}
add_new_files = !take_worktree_changes !refresh_only;
diff --git a/cache.h b/cache.h
index 85b544f..f28240f 100644
--- a/cache.h
+++ b/cache.h
@@ -627,9 +627,15 @@ enum push_default_type {
PUSH_DEFAULT_UNSPECIFIED
};
+enum git_mode {
+ MODE_CURRENT = 0,
+ MODE_NEXT
+};
+
extern enum branch_track git_branch_track;
extern enum rebase_setup_type autorebase;
extern enum push_default_type push_default;
+extern enum git_mode git_mode;
enum object_creation_mode {
OBJECT_CREATION_USES_HARDLINKS = 0,
diff --git a/config.c b/config.c
index e13a7b6..f0e0370 100644
--- a/config.c
+++ b/config.c
@@ -831,6 +831,19 @@ static int git_default_core_config(const char *var, const
char *value)
return 0;
}
+ if (!strcmp(var, core.mode)) {
+ if (!value)
+ return config_error_nonbool(var);
+ else if (!strcmp(value, current))
+ git_mode = MODE_CURRENT;
+ else if (!strcmp(value, next)) {
+ git_mode = MODE_NEXT;
+ push_default = PUSH_DEFAULT_SIMPLE;
+ } else
+ die(wrong mode '%s', value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index 5398c36..751e14d 100644
--- a/environment.c
+++ b/environment.c
@@ -62,6 +62,7 @@ int merge_log_config = -1;
int precomposed_unicode = -1; /* see probe_utf8_pathname_composition() */
struct startup_info *startup_info;
unsigned long pack_size_limit_cfg;
+enum git_mode git_mode = MODE_CURRENT;
/*
* The character that begins a commented line in user-editable file
diff --git a/t/t2205-add-new.sh b/t/t2205-add-new.sh
new file mode 100755
index 000..763664b
--- /dev/null
+++ b/t/t2205-add-new.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+test_description='git add v2.0 behavior'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ mkdir dir1
+ echo one dir1/content
+ echo one dir1/to-remove
+ git add .
+ git commit -m one
+'
+
+test_expect_success 'update in dir throws warning' '
+ test_when_finished git reset --hard
+ echo two dir1/content
+ mkdir -p dir2
+ (
+ cd dir2
+ git add -u 2 err
+ cat err
+ grep will change in Git 2.0 err
+ )
+'
+
+test_expect_success 'update in dir updates everything' '
+ test_when_finished git reset --hard
+ test_config core.mode next
+ echo two dir1/content
+ mkdir -p dir2
+ (
+ cd dir2
+ git add -u 2 err
+ cat err
+ ! grep will change in Git 2.0 err
+ )
+ test $(git ls-files -m) =
+'
+
+test_expect_success 'default to ignore removal' '
+ test_when_finished git reset --hard
+ rm dir1/to-remove
+ git add dir1 2 err
+ cat err
+
