[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH v2 00/17] merge: learn --autostash
From:       Phillip Wood <phillip.wood123 () gmail ! com>
Date:       2019-12-31 10:34:30
Message-ID: 4032e4bd-fa3d-54eb-fe95-38549dff3aaa () gmail ! com
[Download RAW message or body]

On 30/12/2019 21:49, Junio C Hamano wrote:
> Denton Liu <liu.denton@gmail.com> writes:
> 
>> Alban reported[1] that he expected merge to have an --autostash option,
>> just like rebase. Since there's not really any reason why merge can't
>> have it, let's implement it in this patchset.
> 
> Sigh.
> 
> I would actually have preferred to remove the autostash from rebase
> if the goal is to have a consistent behaviour between the two,
> though ;-)

I find the --autostash option to rebase useful if I want to edit a 
commit and I've got uncommitted changes. I wish it was called --stash 
though as it's not automatic as one has to set a config setting or pass 
it on the commandline. I'm also not convinced the config setting is a 
good idea as it allows rebase to run when I think I've committed 
everything but I haven't.

For `merge --autostash` I think we need to consider the interaction of 
`--no-commit` with `--autostash` as `stash pop` will refuse to run if 
the merge modified any of the stashed paths.

Best Wishes

Phillip


> But it is OK as long as it does not degrade the codepath with
> changes that wouldn't have been necessary if this weren't added.
> 
> Let's see how it goes.  Queued.
> 
[prev in list] [next in list] [prev in thread] [next in thread]