From: Thomas Rast <trast@student.ethz.ch>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>, <git@vger.kernel.org>,
Sverre Rabbelier <srabbelier@gmail.com>,
Nanako Shiraishi <nanako3@lavabit.com>,
Nicolas Sebrecht <nicolas.s.dev@gmx.fr>,
Pierre Habouzit <madcoder@debian.org>
Subject: Re: [PATCH v5 0/6] {checkout,reset,stash} --patch
Date: Sat, 15 Aug 2009 12:04:35 +0200 [thread overview]
Message-ID: <200908151204.36709.trast@student.ethz.ch> (raw)
In-Reply-To: <20090815065125.GA23068@coredump.intra.peff.net>
Jeff King wrote:
> > reset -p other Apply this hunk to index? (**)
>
> This doesn't make sense to me. For example:
[...]
> The hunk is _already_ in the index. You are really asking to remove it
> from the index. So shouldn't it say something like "Unstage this hunk"
> or "Remove this hunk from the index"?
>
> Or did you intend to reverse the diff, as with "checkout -p" below?
Yes, sorry :-( I apparently managed to forget the reversing here and
never noticed. I'll make a fixed patch 4/6 today.
> > checkout -p HEAD Discard this hunk from index and worktree? (**)
>
> Good. I like how it clarifies what is being touched.
>
> > checkout -p other Apply this hunk to index and worktree? (**)
>
> I really expected this to just be the same as the "HEAD" case. That is,
> with "git checkout -p HEAD", you are saying "I'm not interested in these
> bits, discard to return back to HEAD". So if I do "git checkout -p
> HEAD^", that is conceptually the same thing, except going back further
> in time.
>
> But I guess you are thinking of it as "pull these changes out of
> 'other'", in which case showing the reverse diff makes sense.
>
> I think this may be a situation where the user has one of two mental
> models in issuing the command, and we don't necessarily know which. So I
> guess what you have is fine, but I wanted to register my surprise.
Well, as I said earlier in the thread I'd hate to reverse the
direction of plain "{reset,checkout,stash} -p" because I want them to
show hunks that match visually.
But then my mental model of "checkout other -- file" is already of the
sort "fetch me the contents of 'file' from 'other'", and I think I use
it about as frequently in a forward as in a backward application. And
I just felt it would be easier to mentally go over the consequences if
it shoed the diff the other way.
(I'm sufficiently confused about which way is back that I think I'll
just stop saying "backward"...)
> > stash -p Stash this hunk?
>
> Getting greedy, is there a reason not to have "stash apply -p" as well?
Should be doable, I'll look at it.
--
Thomas Rast
trast@{inf,student}.ethz.ch
next prev parent reply other threads:[~2009-08-15 10:05 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-23 7:41 [PATCH] git-add -p: be able to undo a given hunk Pierre Habouzit
2009-07-23 8:41 ` Thomas Rast
2009-07-23 8:50 ` Pierre Habouzit
2009-07-24 9:15 ` [RFC PATCH] Implement unstage and reset modes for git-add--interactive Thomas Rast
2009-07-24 16:24 ` [RFC PATCH v2 1/3] Introduce git-unstage Thomas Rast
2009-07-24 17:59 ` Bert Wesarg
2009-07-24 18:02 ` Bert Wesarg
2009-07-24 18:23 ` Elijah Newren
2009-07-24 16:24 ` [RFC PATCH v2 2/3] Introduce git-discard Thomas Rast
2009-07-24 18:02 ` Elijah Newren
2009-07-24 18:12 ` Bert Wesarg
2009-07-24 18:24 ` Elijah Newren
2009-07-25 14:58 ` Pierre Habouzit
2009-07-24 16:24 ` [RFC PATCH v2 3/3] Implement unstage --patch and discard --patch Thomas Rast
2009-07-24 16:40 ` Matthias Kestenholz
2009-07-24 18:08 ` Bert Wesarg
2009-07-24 16:39 ` [RFC PATCH] Implement unstage and reset modes for git-add--interactive Junio C Hamano
2009-07-24 21:58 ` Nanako Shiraishi
2009-07-24 23:17 ` Thomas Rast
2009-07-24 23:25 ` Junio C Hamano
2009-07-25 21:29 ` [RFC PATCH v3 0/5] {checkout,reset,stash} --patch Thomas Rast
2009-07-25 21:29 ` [RFC PATCH v3 1/5] git-apply--interactive: Refactor patch mode code Thomas Rast
2009-07-25 21:29 ` [RFC PATCH v3 2/5] builtin-add: refactor the meat of interactive_add() Thomas Rast
2009-07-25 21:29 ` [RFC PATCH v3 3/5] Implement 'git reset --patch' Thomas Rast
2009-07-25 21:29 ` [RFC PATCH v3 4/5] Implement 'git checkout --patch' Thomas Rast
2009-07-25 21:29 ` [RFC PATCH v3 5/5] Implement 'git stash save --patch' Thomas Rast
2009-07-26 6:03 ` Sverre Rabbelier
2009-07-26 8:45 ` Thomas Rast
2009-07-27 10:10 ` [RFC PATCH v3 0/5] {checkout,reset,stash} --patch Thomas Rast
2009-07-28 21:20 ` [PATCH v4 " Thomas Rast
2009-07-28 21:20 ` [PATCH v4 1/5] git-apply--interactive: Refactor patch mode code Thomas Rast
2009-07-28 21:20 ` [PATCH v4 2/5] builtin-add: refactor the meat of interactive_add() Thomas Rast
2009-07-28 21:20 ` [PATCH v4 3/5] Implement 'git reset --patch' Thomas Rast
2009-07-28 21:20 ` [PATCH v4 4/5] Implement 'git checkout --patch' Thomas Rast
2009-07-28 21:20 ` [PATCH v4 5/5] Implement 'git stash save --patch' Thomas Rast
2009-07-28 21:20 ` [PATCH v4 6/5] DWIM 'git stash save -p' for 'git stash -p' Thomas Rast
2009-08-09 6:52 ` [PATCH v4 0/5] {checkout,reset,stash} --patch Jeff King
2009-08-09 9:17 ` Thomas Rast
2009-08-09 16:32 ` [PATCH v4 0/5] " Nicolas Sebrecht
2009-08-09 16:44 ` Thomas Rast
2009-08-09 21:28 ` Nicolas Sebrecht
2009-08-09 21:42 ` Thomas Rast
2009-08-09 22:26 ` Nicolas Sebrecht
2009-08-10 9:36 ` Thomas Rast
2009-08-13 12:29 ` [PATCH v5 0/6] " Thomas Rast
2009-08-13 12:29 ` [PATCH v5 1/6] git-apply--interactive: Refactor patch mode code Thomas Rast
2009-08-13 12:29 ` [PATCH v5 2/6] Add a small patch-mode testing library Thomas Rast
2009-08-13 12:29 ` [PATCH v5 3/6] builtin-add: refactor the meat of interactive_add() Thomas Rast
2009-08-13 12:29 ` [PATCH v5 4/6] Implement 'git reset --patch' Thomas Rast
2009-08-15 11:48 ` [PATCH v5.1 " Thomas Rast
2009-08-13 12:29 ` [PATCH v5 5/6] Implement 'git checkout --patch' Thomas Rast
2009-08-15 11:48 ` [PATCH v5.1 " Thomas Rast
2009-08-13 12:29 ` [PATCH v5 6/6] Implement 'git stash save --patch' Thomas Rast
2009-08-13 12:29 ` [PATCH v5 7/6] DWIM 'git stash save -p' for 'git stash -p' Thomas Rast
2009-08-14 20:57 ` [PATCH v5 0/6] Re: {checkout,reset,stash} --patch Nicolas Sebrecht
2009-08-15 6:51 ` [PATCH v5 0/6] " Jeff King
2009-08-15 7:57 ` Junio C Hamano
2009-08-15 10:14 ` Thomas Rast
2009-08-15 10:04 ` Thomas Rast [this message]
2009-08-18 16:48 ` Jeff King
2009-08-19 9:40 ` Thomas Rast
2009-08-19 10:11 ` Jeff King
2009-07-23 19:58 ` [PATCH] git-add -p: be able to undo a given hunk Junio C Hamano
2009-07-24 10:32 ` Nanako Shiraishi
2009-07-24 16:06 ` Junio C Hamano
2009-07-24 17:06 ` Jeff King
2009-07-25 0:54 ` Junio C Hamano
2009-07-25 9:35 ` Thomas Rast
2009-07-25 14:48 ` Pierre Habouzit
2009-07-25 14:52 ` Pierre Habouzit
2009-07-26 15:39 ` Jeff King
2009-07-27 8:26 ` Pierre Habouzit
2009-07-27 10:30 ` Jeff King
2009-07-27 10:06 ` Thomas Rast
2009-07-27 10:36 ` Jeff King
2009-07-24 14:58 ` Pierre Habouzit
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=200908151204.36709.trast@student.ethz.ch \
--to=trast@student.ethz.ch \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=madcoder@debian.org \
--cc=nanako3@lavabit.com \
--cc=nicolas.s.dev@gmx.fr \
--cc=peff@peff.net \
--cc=srabbelier@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).