# Interest in options for stash -k and -u by default

3 messages from 2024-02-07 to 2024-02-07. Participants: Ricardo C, Junio C Hamano, Kristoffer Haugsbakk.
Thread: https://gitlist.dev/t/60870

## Ricardo C, 2024-02-07 20:59

Subject: Interest in options for stash -k and -u by default
Message-ID: <3470180e-2ef7-4393-9d32-92cd419727f5@gmail.com>
URL: https://gitlist.dev/e/3470180e-2ef7-4393-9d32-92cd419727f5%40gmail.com

```
Hello,


After some discussion on Mastodon[1], I decided to try my hand at creating 
configuration options that enable --keep-index and --include-untracked in 
git-stash by default. I have made a preliminary such patch[2], and some 
additional discussion[3] has encouraged me to try submitting it upstream.

I am wondering whether this change is something that would even be considered 
for being accepted. The patch still needs some work (mainly documentation and 
tests), which I'd be happy to do if I knew there was upstream interest in this 
work.

I would also appreciate feedback on the patch. Currently, it creates two 
separate options: stash.keepindex and stash.includeuntracked. These options 
set the default value of --keep-index and --include-untracked if not otherwise 
specified (e.g., --no-keep-index) and do not conflict with other options 
(e.g., --patch). More details are of course available in the source code[2].


Thank you,

Ricardo "MithicSpirit" Prado Cunha


[1] https://bsd.network/@ed1conf/111783574839749798

[2] 
https://github.com/MithicSpirit/git/commit/f33c8d5d26d8438ddb123781bd5db3bff8618247.patch

[3] https://social.jvns.ca/@b0rk/111880230506448122


```

## Junio C Hamano, 2024-02-07 21:08

Subject: Re: Interest in options for stash -k and -u by default
Message-ID: <xmqq34u46kzz.fsf@gitster.g>
URL: https://gitlist.dev/e/xmqq34u46kzz.fsf%40gitster.g
In-Reply-To: <3470180e-2ef7-4393-9d32-92cd419727f5@gmail.com>

```
Ricardo C <rpc01234@gmail.com> writes:

> I am wondering whether this change is something that would even be
> considered for being accepted. The patch still needs some work (mainly
> documentation and tests), which I'd be happy to do if I knew there was
> upstream interest in this work.

There is a canned response for it ;-)

I've seen from time to time people ask "I am thinking of doing this;
will a patch be accepted?  If so, I'll work on it." before showing
any work, and my response always has been:

 (1) We don't know how useful and interesting your contribution would
     be for our audience, until we see it; and

 (2) If you truly believe in your work (find it useful, find writing
     it fun, etc.), that would be incentive enough for you to work
     on it, whether or not the result will land in my tree.  You
     should instead aim for something so brilliant that we would
     come to you begging for your permission to include it in our
     project.


```

## Kristoffer Haugsbakk, 2024-02-07 21:42

Subject: Re: Interest in options for stash -k and -u by default
Message-ID: <7c895747-22a1-48f6-89ce-d518fbd32285@app.fastmail.com>
URL: https://gitlist.dev/e/7c895747-22a1-48f6-89ce-d518fbd32285%40app.fastmail.com
In-Reply-To: <3470180e-2ef7-4393-9d32-92cd419727f5@gmail.com>

```
On Wed, Feb 7, 2024, at 21:59, Ricardo C wrote:
> Hello,
>
>
> After some discussion on Mastodon[1], I decided to try my hand at creating
> configuration options that enable --keep-index and --include-untracked in
> git-stash by default. I have made a preliminary such patch[2], and some
> additional discussion[3] has encouraged me to try submitting it upstream.
>
> I am wondering whether this change is something that would even be considered
> for being accepted. The patch still needs some work (mainly documentation and
> tests), which I'd be happy to do if I knew there was upstream interest in this
> work.
>
> I would also appreciate feedback on the patch. Currently, it creates two
> separate options: stash.keepindex and stash.includeuntracked. These options
> set the default value of --keep-index and --include-untracked if not otherwise
> specified (e.g., --no-keep-index) and do not conflict with other options
> (e.g., --patch). More details are of course available in the source code[2].

The way I understand it:

• You already have a working implementation
• There already exists conventions for using config variables for
  defaults which then can be in turn overridden using the corresponding
  flags (the `--[no]-<flag>` pair)

So what’s the hold-up? :)

> I would also appreciate feedback on the patch.

That would be part of the patch series in any case.

-- 
Kristoffer Haugsbakk

```