All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Beyer <s-beyer@gmx.net>
To: Marc Branchaud <marcnarc@xiplink.com>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git <git@vger.kernel.org>
Subject: Re: [RFC] stash --continue
Date: Wed, 18 Jan 2017 20:20:37 +0100	[thread overview]
Message-ID: <e273c7c8-278a-061c-44fd-4808b53d0475@gmx.net> (raw)
In-Reply-To: <d5456165-bdf2-e9e7-117f-aeab0ff4b417@xiplink.com>

Hi,

On 01/18/2017 04:41 PM, Marc Branchaud wrote:
> On 2017-01-16 05:54 AM, Johannes Schindelin wrote:
>> On Mon, 16 Jan 2017, Stephan Beyer wrote:
>>> a git-newbie-ish co-worker uses git-stash sometimes. Last time he used
>>> "git stash pop", he got into a merge conflict. After he resolved the
>>> conflict, he did not know what to do to get the repository into the
>>> wanted state. In his case, it was only "git add <resolved files>"
>>> followed by a "git reset" and a "git stash drop", but there may be more
>>> involved cases when your index is not clean before "git stash pop" and
>>> you want to have your index as before.
>>>
>>> This led to the idea to have something like "git stash --continue"[1]
>>
>> More like "git stash pop --continue". Without the "pop" command, it does
>> not make too much sense.
> 
> Why not?  git should be able to remember what stash command created the
> conflict.  Why should I have to?

Dscho and Junio gave you a git-perspective argument.
I give you a user-perspective one:
What if you did "git stash pop" and ran into an (unexpected) conflict.
You resolve it, and you probably - for some reason - don't want to drop
the stash now, as "git stash --continue" (assuming "pop") would do. So
I'd regard it as a feature if you could now run "git stash apply
--continue" to just finish the job without dropping.

Best
Stephan

PS: I put this idea in my todo priority queue. If somebody else is
interested: I am not going to work at this idea before February.

PPS: Any opinions about the mentioned "backwards-compatibility" issue
that people are then forced to finish their commits with "--continue"
instead of "git reset" or "git commit"?

  parent reply	other threads:[~2017-01-18 19:22 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-15 23:56 [RFC] stash --continue Stephan Beyer
2017-01-16  3:59 ` Jacob Keller
2017-01-16 10:54 ` Johannes Schindelin
2017-01-18 15:41   ` Marc Branchaud
2017-01-18 16:34     ` Johannes Schindelin
2017-01-18 18:44       ` Marc Branchaud
2017-01-18 19:35         ` Samuel Lijin
2017-01-19 15:49         ` Johannes Schindelin
2017-01-19 18:38           ` Marc Branchaud
2017-01-19 21:30             ` Johannes Schindelin
2017-01-20 15:19               ` Marc Branchaud
2017-01-20 15:27                 ` Johannes Schindelin
2017-01-18 19:10       ` Junio C Hamano
2017-01-18 19:20     ` Stephan Beyer [this message]
2017-01-19 15:54       ` Johannes Schindelin
2017-01-17 20:21 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e273c7c8-278a-061c-44fd-4808b53d0475@gmx.net \
    --to=s-beyer@gmx.net \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=marcnarc@xiplink.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.