Make rebase.autostash default

[ohhmm]

Thanks for taking the time to contribute to Git! Please be advised that the
Git community does not use github.com for their contributions. Instead, we use
a mailing list (git@vger.kernel.org) for code submissions, code reviews, and
bug reports. Nevertheless, you can use GitGitGadget (https://gitgitgadget.github.io/)
to conveniently send your Pull Requests commits to our mailing list.

Please read the "guidelines for contributing" linked above!

cc: "brian m. carlson" sandals@crustytoothpaste.net
cc: rsbecker@nexbridge.com

[gitgitgadget-git]

Welcome to GitGitGadget

Hi @ohhmm, and welcome to GitGitGadget, the GitHub App to send patch series to the Git mailing list from GitHub Pull Requests.

Please make sure that your Pull Request has a good description, as it will be used as cover letter. You can CC potential reviewers by adding a footer to the PR description with the following syntax:

CC: Revi Ewer <revi.ewer@example.com>, Ill Takalook <ill.takalook@example.net>

Also, it is a good idea to review the commit messages one last time, as the Git project expects them in a quite specific form:

• the lines should not exceed 76 columns,
• the first line should be like a header and typically start with a prefix like "tests:" or "revisions:" to state which subsystem the change is about, and
• the commit messages' body should be describing the "why?" of the change.
• Finally, the commit messages should end in a Signed-off-by: line matching the commits' author.

It is in general a good idea to await the automated test ("Checks") in this Pull Request before contributing the patches, e.g. to avoid trivial issues such as unportable code.

Contributing the patches

Before you can contribute the patches, your GitHub username needs to be added to the list of permitted users. Any already-permitted user can do that, by adding a comment to your PR of the form /allow. A good way to find other contributors is to locate recent pull requests where someone has been /allowed:

• Search: is:pr is:open "/allow"

Both the person who commented /allow and the PR author are able to /allow you.

An alternative is the channel #git-devel on the Libera Chat IRC network:

<newcontributor> I've just created my first PR, could someone please /allow me? https://github.com/gitgitgadget/git/pull/12345
<veteran> newcontributor: it is done
<newcontributor> thanks!

Once on the list of permitted usernames, you can contribute the patches to the Git mailing list by adding a PR comment /submit.

If you want to see what email(s) would be sent for a /submit request, add a PR comment /preview to have the email(s) sent to you. You must have a public GitHub email address for this. Note that any reviewers CC'd via the list in the PR description will not actually be sent emails.

After you submit, GitGitGadget will respond with another comment that contains the link to the cover letter mail in the Git mailing list archive. Please make sure to monitor the discussion in that thread and to address comments and suggestions (while the comments and suggestions will be mirrored into the PR by GitGitGadget, you will still want to reply via mail).

If you do not want to subscribe to the Git mailing list just to be able to respond to a mail, you can download the mbox from the Git mailing list archive (click the (raw) link), then import it into your mail program. If you use GMail, you can do this via:

curl -g --user "<EMailAddress>:<Password>" \
    --url "imaps://imap.gmail.com/INBOX" -T /path/to/raw.txt

To iterate on your change, i.e. send a revised patch or patch series, you will first want to (force-)push to the same branch. You probably also want to modify your Pull Request description (or title). It is a good idea to summarize the revision by adding something like this to the cover letter (read: by editing the first comment on the PR, i.e. the PR description):

Changes since v1:
- Fixed a typo in the commit message (found by ...)
- Added a code comment to ... as suggested by ...
...

To send a new iteration, just add another PR comment with the contents: /submit.

Need help?

New contributors who want advice are encouraged to join git-mentoring@googlegroups.com, where volunteers who regularly contribute to Git are willing to answer newbie questions, give advice, or otherwise provide mentoring to interested contributors. You must join in order to post or view messages, but anyone can join.

You may also be able to find help in real time in the developer IRC channel, #git-devel on Libera Chat. Remember that IRC does not support offline messaging, so if you send someone a private message and log out, they cannot respond to you. The scrollback of #git-devel is archived, though.

[gitgitgadget-git]

There are issues in commit f2795a4:
Make rebase.autostash default
Commit checks stopped - the message is too short
Commit not signed off

[dscho]

/allow

[gitgitgadget-git]

User ohhmm is now allowed to use GitGitGadget.

WARNING: ohhmm has no public email address set on GitHub;
GitGitGadget needs an email address to Cc: you on your contribution, so that you receive any feedback on the Git mailing list. Go to https://github.com/settings/profile to make your preferred email public to let GitGitGadget know which email address to use.

[dscho]

Thanks for taking the time to contribute to Git! Please be advised that the Git community does not use github.com for their contributions. Instead, we use a mailing list (git@vger.kernel.org) for code submissions, code reviews, and bug reports. Nevertheless, you can use GitGitGadget (https://gitgitgadget.github.io/) to conveniently send your Pull Requests commits to our mailing list.

Please read the "guidelines for contributing" linked above!

@ohhmm this is a template that was supposed to be acknowledged and then edited...

There are issues in commit f2795a4: Make rebase.autostash default Commit checks stopped - the message is too short Commit not signed off

Apart from missing the Signed-off-by footer (see https://git-scm.com/docs/SubmittingPatches#sign-off for details), the commit messages in the Git project are expected to be much more than one-liners. See https://github.blog/2022-06-30-write-better-commits-build-better-projects/ for guidance how to improve the commit message substantially.

[dscho]

This seems to have missed https://github.com/git/git/blob/v2.37.1/builtin/rebase.c#L786-L789

[gitgitgadget-git]

There are issues in commit d70b9d2:
Make rebase.autostash default
Commit checks stopped - the message is too short
Commit not signed off

[ohhmm]

There are issues in commit d70b9d2:
Make rebase.autostash default
Commit checks stopped - the message is too short
Commit not signed off

Ok. Ready. Thanks.

[dscho]

@ohhmm then it's time to /submit, as per #1307 (comment)

[ohhmm]

/submit

[gitgitgadget-git]

Submitted as pull.1307.git.git.1660831231.gitgitgadget@gmail.com

To fetch this version into FETCH_HEAD:

git fetch https://github.com/gitgitgadget/git/ pr-git-1307/ohhmm/master-v1

To fetch this version to local tag pr-git-1307/ohhmm/master-v1:

git fetch --no-tags https://github.com/gitgitgadget/git/ tag pr-git-1307/ohhmm/master-v1

[gitgitgadget-git]

On the Git mailing list, "brian m. carlson" wrote (reply to this):

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

[gitgitgadget-git]

User "brian m. carlson" <sandals@crustytoothpaste.net> has been added to the cc: list.

[gitgitgadget-git]

On the Git mailing list, "brian m. carlson" wrote (reply to this):

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

[gitgitgadget-git]

On the Git mailing list, Junio C Hamano wrote (reply to this):

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

[gitgitgadget-git]

On the Git mailing list, wrote (reply to this):

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

[gitgitgadget-git]

On the Git mailing list, Junio C Hamano wrote (reply to this):

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

[gitgitgadget-git]

User <rsbecker@nexbridge.com> has been added to the cc: list.