From: Yann Dirson <ydirson@free.fr>
To: Kevin Ballard <kevin@sb.org>
Cc: Junio C Hamano <gitster@pobox.com>, Yann Dirson <ydirson@free.fr>,
Jonathan Nieder <jrnieder@gmail.com>,
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
Eric Raible <raible@nextest.com>, Yann Dirson <dirson@bertin.fr>,
git@vger.kernel.org
Subject: Re: [PATCH] git-rebase--interactive.sh: Add new command "shell"
Date: Mon, 8 Nov 2010 23:29:37 +0100 [thread overview]
Message-ID: <20101108222937.GH3167@home.lan> (raw)
In-Reply-To: <663A3F43-5F64-41F0-B272-64EEE9775250@sb.org>
On Mon, Nov 08, 2010 at 01:49:44PM -0800, Kevin Ballard wrote:
> On Nov 8, 2010, at 10:31 AM, Junio C Hamano wrote:
>
> > Yann Dirson <ydirson@free.fr> writes:
> >
> >> # e, edit = use commit (if specified) but pause to amend/examine/test
> >
> > When an end user is given
> >
> > pick one
> > pick two
> > pick three
> > ...
> >
> > and told the above, would it be crystal clear that, if he changed the insn
> > sheet to
> >
> > pick one
> > edit
> > pick three
> > ...
> >
> > then he will _lose_ the change made by foo, or will the user come back
> > here and complain that a precious change "two" is lost and it is git's
> > fault?
>
> On the one hand, once someone understands what the todo list is actually
> doing, then it should be instantly obvious that removing the reference to
> a commit will remove that commit entirely. On the other hand, I agree it
> may be confusing to new git users (or new rebase users). Do you have an
> alternative solution in mind?
Maybe restating in an explanatory paragraph something like:
|Keep in mind that any commit in the original todo list, that would
|not be there after your edits, would not be included in the resulting
|rebased branch. In case you realize afterwards that you need such a
|commit, you can still access it as an ancestor of @{1}, see
|git-reflog(1) for details.
Maybe we could list a copy of the todo list in the comments, as a
reference for double-checking. Such a list could even be used for a
final check before applying, that would ask confirmation if the set of
patches has changed, and offer to edit again. The same config item
(eg. advice.interactiveRebase ?) could be used to hide the note and
the check.
Now making "rebase -i" possibly interactive may cause problems, for
any porcelain scripts above it. Not sure it'd be the way to do it.
Maybe add a "check" command to be inserted at bottom of todo list to
activate it, that would be here by default but commented out ?
next prev parent reply other threads:[~2010-11-08 22:29 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-04 5:17 [PATCH] git-rebase--interactive.sh: Add new command "shell" Kevin Ballard
2010-11-04 5:22 ` Kevin Ballard
2010-11-04 8:42 ` Matthieu Moy
2010-11-04 8:53 ` Kevin Ballard
2010-11-04 9:23 ` Ævar Arnfjörð Bjarmason
2010-11-04 9:25 ` Kevin Ballard
2010-11-04 9:27 ` Ævar Arnfjörð Bjarmason
2010-11-04 10:24 ` Johannes Sixt
2010-11-04 9:36 ` Erik Faye-Lund
2010-11-04 9:43 ` Kevin Ballard
2010-11-04 10:25 ` Yann Dirson
2010-11-04 10:40 ` Erik Faye-Lund
2010-11-04 17:04 ` Eric Raible
2010-11-04 17:34 ` Matthieu Moy
2010-11-04 17:43 ` Eric Raible
2010-11-04 18:10 ` Jonathan Nieder
2010-11-04 20:53 ` Yann Dirson
2010-11-04 21:05 ` Eric Raible
2010-11-04 22:01 ` [PATCHv2] git-rebase--interactive.sh: extend "edit" command to be more useful Kevin Ballard
2010-11-04 21:33 ` [PATCH] git-rebase--interactive.sh: Add new command "shell" Kevin Ballard
2010-11-05 7:33 ` Johannes Sixt
2010-11-05 8:39 ` Kevin Ballard
2010-11-08 18:31 ` Junio C Hamano
2010-11-08 21:49 ` Kevin Ballard
2010-11-08 22:29 ` Yann Dirson [this message]
2010-11-10 1:42 ` Jonathan Nieder
2010-11-10 1:46 ` Kevin Ballard
2010-11-10 1:56 ` Jonathan Nieder
2010-11-10 7:43 ` Yann Dirson
2010-11-10 16:00 ` Matthieu Moy
2010-11-10 1:53 ` Jonathan Nieder
2010-11-10 2:14 ` Kevin Ballard
2010-11-24 20:19 ` [PATCHv3] git-rebase--interactive.sh: extend "edit" command to be more useful Kevin Ballard
2010-12-03 8:06 ` Jonathan Nieder
2010-12-03 8:16 ` Kevin Ballard
2010-12-03 8:55 ` Jonathan Nieder
2010-12-03 9:55 ` Johannes Sixt
2010-12-03 10:00 ` Jonathan Nieder
2010-12-03 10:14 ` Kevin Ballard
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=20101108222937.GH3167@home.lan \
--to=ydirson@free.fr \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=dirson@bertin.fr \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=kevin@sb.org \
--cc=raible@nextest.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).