[PATCH v3] Add core.mode configuration

[PATCH v3] Add core.mode configuration

[Felipe Contreras]

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.contreras@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 0000000..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 &&
+	grep "will change in Git 2.0" err &&
+	test "$(git ls-files -c)" != "dir1/content"
+'
+
+test_expect_success 'default adds removals' '
+	test_when_finished "git reset --hard" &&
+	test_config core.mode next &&
+	rm dir1/to-remove &&
+	git add dir1 2> err &&
+	cat err &&
+	! grep "will change in Git 2.0" err &&
+	test "$(git ls-files -c)" = "dir1/content"
+'
+
+test_done
-- 
1.8.4-fc

Re: [PATCH v3] Add core.mode configuration

[Krzysztof Mazur]

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

Re: [PATCH v3] Add core.mode configuration

[Felipe Contreras]

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

Re: [PATCH v3] Add core.mode configuration

[Felipe Contreras]

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

Re: [PATCH v3] Add core.mode configuration

[Krzysztof Mazur]

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

Re: [PATCH v3] Add core.mode configuration

[Felipe Contreras]

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

Re: [PATCH v3] Add core.mode configuration

[Krzysztof Mazur]

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

Re: [PATCH v3] Add core.mode configuration

[Krzysztof Mazur]

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

Re: [PATCH v3] Add core.mode configuration

[John Szakmeister]

On Tue, Oct 15, 2013 at 10:51 AM, Krzysztof Mazur <krzysiek@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

Re: [PATCH v3] Add core.mode configuration

[Felipe Contreras]

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

Re: [PATCH v3] Add core.mode configuration

[Krzysztof Mazur]

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, not some "next" behavior that may change in future.

For instance, I was very unhappy once, when git pull failed and said
that I should do git pull --merge.

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

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

Krzysiek

Re: [PATCH v3] Add core.mode configuration

[Felipe Contreras]

John Szakmeister wrote:
> On Tue, Oct 15, 2013 at 10:51 AM, Krzysztof Mazur <krzysiek@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

Re: [PATCH v3] Add core.mode configuration

[Felipe Contreras]

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

Re: [PATCH v3] Add core.mode configuration

[Krzysztof Mazur]

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

Re: [PATCH v3] Add core.mode configuration

[Krzysztof Mazur]

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

Re: [PATCH v3] Add core.mode configuration

[John Szakmeister]

On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras
<felipe.contreras@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

Re: [PATCH v3] Add core.mode configuration

[John Szakmeister]

On Wed, Oct 16, 2013 at 6:54 AM, John Szakmeister <john@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

Re: [PATCH v3] Add core.mode configuration

[Felipe Contreras]

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

Re: [PATCH v3] Add core.mode configuration

[Felipe Contreras]

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

Re: [PATCH v3] Add core.mode configuration

[Felipe Contreras]

John Szakmeister wrote:
> On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras
> <felipe.contreras@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 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?

I don't think it does matter, that's why I put the comment in parenthesis.

If 99% of users do 'rm --force' that doesn't make the --force option worst,
--force means --force, and that's that.

And core.mode = next doesn't include any promise of the new behaviors locked
in, and that's that. Even if 100% enable core.mode = next, it would still mean
no promise.

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

You are welcome to do that, but then you should be aware there's a possibility
that if you rely on a v2.0 behavior, it might change.

If you are not willing to accept that caveat, then core.mode = next is not for
you. It's that simple.

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

I actually think we should have both. A branch were incomplete or potentially
dangerous features are being worked on, but we have agreed they should be
merged eventually *and* a configuration option to turn v2.0 behavior.

The experimental branch would be clearly experimental, but that doesn't fullfil
the need of the v2.0 mode option, because the people that might to test this
could be end users that don't want to compile their own Git, they want to use
their distro's git-1.9, just enable that option, and see how things fare.

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

We are stuck, but not because we don't have options, but because these options
would never be realized. core.mode = next is one option, the experimental
branch is another option, and yet none of those are going to happen.

At the end of the day the collision course is set, and nobody would be testing
this stuff for v2.0 and the complaints will come in a similar way as they did
in v1.6, probably less because this time we have warnings, and probably way
less because the behaviors changes are very subtle, but exactly like in v1.6,
nobody will test this behavior until v2.0 is release (except me, apparently).

But this is not what really worries me, what worries me is that we don't have
enough changes for v2.0, we need more backwards incompatible change, and we
need to start testing it *now*, that way v2.0 will be better as it would
introduce more improvements, and the backwards incompatible changes would be
accepted by the users. Alas, that's not going to happen. Change and Git don't
go together.

Cheers.

-- 
Felipe Contreras

Re: [PATCH v3] Add core.mode configuration

[Felipe Contreras]

John Szakmeister wrote:
> On Wed, Oct 16, 2013 at 6:54 AM, John Szakmeister <john@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

Re: [PATCH v3] Add core.mode configuration

[Philip Oakley]

From: "Felipe Contreras" <felipe.contreras@gmail.com>
> John Szakmeister wrote:
>> On Tue, Oct 15, 2013 at 11:55 PM, Felipe Contreras
>> <felipe.contreras@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
> --

Re: [PATCH v3] Add core.mode configuration

[Jonathan Nieder]

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

Re: [PATCH v3] Add core.mode configuration

[Philip Oakley]

From: "Jonathan Nieder" <jrnieder@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
> 

Re: [PATCH v3] Add core.mode configuration

[Felipe Contreras]

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