[PATCH 0/2] Make rebase.autostash default

[PATCH 0/2] Make rebase.autostash default

[Sergei Krivonos via GitGitGadget]

Sergio (2):
  Make rebase.autostash default
  Add Eclipse project settings files to .gitignore

 .gitignore                      | 2 ++
 Documentation/config/rebase.txt | 2 +-
 builtin/pull.c                  | 2 +-
 config.c                        | 8 ++++++++
 config.h                        | 8 ++++++++
 5 files changed, 20 insertions(+), 2 deletions(-)


base-commit: c50926e1f48891e2671e1830dbcd2912a4563450
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-1307%2Fohhmm%2Fmaster-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-1307/ohhmm/master-v1
Pull-Request: https://github.com/git/git/pull/1307
-- 
gitgitgadget

[PATCH 1/2] Make rebase.autostash default

[Sergio via GitGitGadget]

From: Sergio <sergeikrivonos@gmail.com>

Signed-off-by: Sergio <sergeikrivonos@gmail.com>
---
 Documentation/config/rebase.txt | 2 +-
 builtin/pull.c                  | 2 +-
 config.c                        | 8 ++++++++
 config.h                        | 8 ++++++++
 4 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/Documentation/config/rebase.txt b/Documentation/config/rebase.txt
index f19bd0e0407..bc952327140 100644
--- a/Documentation/config/rebase.txt
+++ b/Documentation/config/rebase.txt
@@ -19,7 +19,7 @@ rebase.autoStash::
 	successful rebase might result in non-trivial conflicts.
 	This option can be overridden by the `--no-autostash` and
 	`--autostash` options of linkgit:git-rebase[1].
-	Defaults to false.
+	Defaults to true.
 
 rebase.updateRefs::
 	If set to true enable `--update-refs` option by default.
diff --git a/builtin/pull.c b/builtin/pull.c
index 403a24d7ca6..333d6a232a7 100644
--- a/builtin/pull.c
+++ b/builtin/pull.c
@@ -362,7 +362,7 @@ static int git_pull_config(const char *var, const char *value, void *cb)
 	int status;
 
 	if (!strcmp(var, "rebase.autostash")) {
-		config_autostash = git_config_bool(var, value);
+		config_autostash = git_config_bool_or_default(var, value, 1);
 		return 0;
 	} else if (!strcmp(var, "submodule.recurse")) {
 		recurse_submodules = git_config_bool(var, value) ?
diff --git a/config.c b/config.c
index e8ebef77d5c..c4f6da3547e 100644
--- a/config.c
+++ b/config.c
@@ -1437,6 +1437,14 @@ int git_config_bool(const char *name, const char *value)
 	return v;
 }
 
+int git_config_bool_or_default(const char *name, const char *value, int default_value)
+{
+	int v = git_parse_maybe_bool(value);
+	if (v < 0)
+		v = default_value;
+	return v;
+}
+
 int git_config_string(const char **dest, const char *var, const char *value)
 {
 	if (!value)
diff --git a/config.h b/config.h
index ca994d77147..d236bb0a326 100644
--- a/config.h
+++ b/config.h
@@ -242,6 +242,14 @@ int git_config_bool_or_int(const char *, const char *, int *);
  */
 int git_config_bool(const char *, const char *);
 
+/**
+ * Parse a string into a boolean value, respecting keywords like "true" and
+ * "false". Integer values are converted into true/false values (when they
+ * are non-zero or zero, respectively). Other values results in default. If
+ * parsing is successful, the return value is the result.
+ */
+int git_config_bool_or_default(const char *, const char *, int);
+
 /**
  * Allocates and copies the value string into the `dest` parameter; if no
  * string is given, prints an error message and returns -1.
-- 
gitgitgadget

Re: [PATCH 1/2] Make rebase.autostash default

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 990 bytes --]

On 2022-08-18 at 14:00:30, Sergio via GitGitGadget wrote:
> From: Sergio <sergeikrivonos@gmail.com>
> 
> Signed-off-by: Sergio <sergeikrivonos@gmail.com>

Typically you'll want to explain in the commit message why this is a
valuable change. For example, I don't have this option set and don't use
it, and I always stash my changes manually before rebasing.  You should
tell me why the user will benefit from this setting defaulting to
enabled, since I personally don't see a need for it.

You may also want to discuss why any pitfalls of stash, such as unadded
changes being added after a stash pop, are not problematic here and why
this behaviour won't be more surprising or annoying to experienced users
who are used to seeing an error message instead.

This isn't to say that the change is bad or we shouldn't accept it, only
that I (and others) need help understanding why it's a good change to make.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [PATCH 1/2] Make rebase.autostash default

[Junio C Hamano]

"Sergio via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Sergio <sergeikrivonos@gmail.com>

Neither the cover letter nor the proposed log message even attempt
to justify why this is a good change.

Probably that is because it is not justifiable.  I do not think it
is a good idea to change the default, either.

> diff --git a/builtin/pull.c b/builtin/pull.c
> index 403a24d7ca6..333d6a232a7 100644
> --- a/builtin/pull.c
> +++ b/builtin/pull.c
> @@ -362,7 +362,7 @@ static int git_pull_config(const char *var, const char *value, void *cb)
>  	int status;
>  
>  	if (!strcmp(var, "rebase.autostash")) {
> -		config_autostash = git_config_bool(var, value);
> +		config_autostash = git_config_bool_or_default(var, value, 1);

This is wrong.  What this says is "if the user has rebase.autostash,
attempt to interpret its value as a Boolean, and store it in this
variable.  If the value cannot be read as a Boolean, pretend as if
true was given".

That does not set the default to a configuration variable.  The
default is the value used when the user does *NOT* specify
rebase.autostash anywhere, but anything the code does inside the
block guarded by that strcmp() cannot affect that case.

If it were a good idea to make the variable default to true, the
place to do so would probably be

        diff --git i/builtin/pull.c w/builtin/pull.c
        index 403a24d7ca..0bb8421dfc 100644
        --- i/builtin/pull.c
        +++ w/builtin/pull.c
        @@ -87,7 +87,7 @@ static char *opt_ff;
         static char *opt_verify_signatures;
         static char *opt_verify;
         static int opt_autostash = -1;
        -static int config_autostash;
        +static int config_autostash = 1; /* default to true */
         static int check_trust_level = 1;
         static struct strvec opt_strategies = STRVEC_INIT;
         static struct strvec opt_strategy_opts = STRVEC_INIT;

> diff --git a/config.c b/config.c
> index e8ebef77d5c..c4f6da3547e 100644
> --- a/config.c
> +++ b/config.c
> @@ -1437,6 +1437,14 @@ int git_config_bool(const char *name, const char *value)
>  	return v;
>  }
>  
> +int git_config_bool_or_default(const char *name, const char *value, int default_value)
> +{
> +	int v = git_parse_maybe_bool(value);
> +	if (v < 0)
> +		v = default_value;
> +	return v;
> +}

And this is not a useful helper function.  At least, this is not
useful for this particular case.  We have tristate Booleans that
take yes/no/auto, and 

	git_config_bool_or_default(name, value, 2);

can take "name.value=auto" and turn it into 2 (instead of 0=no
1=yes), but because the helper takes *any* garbage that is not a
Boolean and gives the same default_value, the value does not have to
be "auto" here, which makes the helper pretty much useless.

The patch is incomplete.  It only changes "git pull" but does not
do anything to "git rebase".

[PATCH 2/2] Add Eclipse project settings files to .gitignore

[Sergio via GitGitGadget]

From: Sergio <sergeikrivonos@gmail.com>

Signed-off-by: Sergio <sergeikrivonos@gmail.com>
---
 .gitignore | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.gitignore b/.gitignore
index 42fd7253b44..13755c31caf 100644
--- a/.gitignore
+++ b/.gitignore
@@ -246,3 +246,5 @@ Release/
 /git.VC.db
 *.dSYM
 /contrib/buildsystems/out
+/.cproject
+/.project
-- 
gitgitgadget

Re: [PATCH 2/2] Add Eclipse project settings files to .gitignore

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

On 2022-08-18 at 14:00:31, Sergio via GitGitGadget wrote:
> From: Sergio <sergeikrivonos@gmail.com>
> 
> Signed-off-by: Sergio <sergeikrivonos@gmail.com>
> ---
>  .gitignore | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/.gitignore b/.gitignore
> index 42fd7253b44..13755c31caf 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -246,3 +246,5 @@ Release/
>  /git.VC.db
>  *.dSYM
>  /contrib/buildsystems/out
> +/.cproject
> +/.project

I have no strong opinion on this change, but typically, to avoid a
proliferation of patterns with everyone's favourite editor settings, it
can be useful if each individual user sets their own editor files in
~/.config/git/ignore (or core.excludesFile, if you prefer a different
location).  For example, I do this with Vim-related files, and it
applies to all repos on my system, such that other developers don't have
to care what editor I use.

However, Eclipse is a popular editor, so it may be that Junio really
likes this change since it will benefit many people.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: [PATCH 2/2] Add Eclipse project settings files to .gitignore

[Junio C Hamano]

"brian m. carlson" <sandals@crustytoothpaste.net> writes:

> location).  For example, I do this with Vim-related files, and it
> applies to all repos on my system, such that other developers don't have
> to care what editor I use.
>
> However, Eclipse is a popular editor, so it may be that Junio really
> likes this change since it will benefit many people.

I am all for making new contributor's life better, and in this case,
NOT adding editor-specific patterns to OUR .gitignore contributes
better for that goal.  It will be a shame for us to make a move that
will keep our contributors unaware of what they can do with Git, and
in this case, lack of Eclipse specific patterns did trigger Sergio
to notice that these are not ignored, and learn that a better place
to do so is in $HOME/.gitignore, because it will help not only when
the contributor works on Git, but when the same contributor works on
anything using Eclipse.  Adding editor-specific patterns ourselves
robs such a learning opportunity from new contributors.

Thanks.

RE: [PATCH 2/2] Add Eclipse project settings files to .gitignore

[rsbecker]

On August 18, 2022 2:18 PM, Junio C Hamano wrote:
>To: brian m. carlson <sandals@crustytoothpaste.net>
>Cc: Sergio via GitGitGadget <gitgitgadget@gmail.com>; git@vger.kernel.org;
>Sergei Krivonos <sergeikrivonos@gmail.com>
>Subject: Re: [PATCH 2/2] Add Eclipse project settings files to .gitignore
>
>"brian m. carlson" <sandals@crustytoothpaste.net> writes:
>
>> location).  For example, I do this with Vim-related files, and it
>> applies to all repos on my system, such that other developers don't
>> have to care what editor I use.
>>
>> However, Eclipse is a popular editor, so it may be that Junio really
>> likes this change since it will benefit many people.
>
>I am all for making new contributor's life better, and in this case, NOT
adding
>editor-specific patterns to OUR .gitignore contributes better for that
goal.  It will
>be a shame for us to make a move that will keep our contributors unaware of
>what they can do with Git, and in this case, lack of Eclipse specific
patterns did
>trigger Sergio to notice that these are not ignored, and learn that a
better place to
>do so is in $HOME/.gitignore, because it will help not only when the
contributor
>works on Git, but when the same contributor works on anything using
Eclipse.
>Adding editor-specific patterns ourselves robs such a learning opportunity
from
>new contributors.

There is a related case to this in ECLIPSE,
https://bugs.eclipse.org/bugs/show_bug.cgi?id=575408, discussing a problem
with where ECLIPSE CDT is improperly storing and modifying build settings.
What my project team found is that much of the ECLIPSE settings need to be
preserved, especially the encodings - .gitignore is not a valid option for
these. ECLIPSE has a habit of inheriting container encodings, which is not
always correct (we keep our files in UTF-8 not cp1292). Most settings should
be retained, but the ones in .settings/language.settings.xml changes each
time ECLIPSE restarts or sometimes clones a project. Unfortunately, some of
the settings in that file are needed to bootstrap builds for new clones. The
case has been open a while with no resolution. Whether a good idea or not,
what our team found an acceptable solution is to use update-index
--assume-unchanged on that specific file and manage other ECLIPSE artifacts
in git not excluding them in .gitignore.

--Randall

Re: [PATCH 2/2] Add Eclipse project settings files to .gitignore

[Junio C Hamano]

"Sergio via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Sergio <sergeikrivonos@gmail.com>
>
> Signed-off-by: Sergio <sergeikrivonos@gmail.com>
> ---
>  .gitignore | 2 ++
>  1 file changed, 2 insertions(+)

Your interest in the git project is appreciated, but we try to keep
our .gitignore to the common build artifacts.  Things that are
created for those who share a certaion personal preference, like
editor backup files, are best listed in .git/info/exclude (or
$HOME/.gitignore).  I am an Emacs user but *~ is not in .gitignore
in the project, for example.

Thanks.