From: Matheus Tavares Bernardino <email@example.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: "Ævar Arnfjörð Bjarmason" <firstname.lastname@example.org>,
"Christian Couder" <email@example.com>,
"Оля Тележная" <firstname.lastname@example.org>
Subject: Re: [GSoC] Some #leftoverbits for anyone looking for little projects
Date: Tue, 28 May 2019 14:37:33 -0300 [thread overview]
Message-ID: <CAHd-oW7BFYd=LQBF4mF5QTpce9YtXj1WDf85AyO+CLwC9GMqDg@mail.gmail.com> (raw)
On Tue, May 28, 2019 at 7:37 AM Johannes Schindelin
> Hi Matheus,
> On Mon, 20 May 2019, Matheus Tavares wrote:
> > > Give "rebase -i" some option so when you "reword" the patch is
> > > included in the message.
> > >
> > > I keep going to the shell because I have no idea what change I'm
> > > describing.
> > I have the same problem, so I wanted to try solving this. The patch
> > bellow creates a "rebase.verboseCommit" configuration that includes a
> > diff when rewording or squashing. I'd appreciate knowing your thoughts
> > on it.
> > As Christian wisely pointed out to me, though, we can also achieve this
> > behavior by setting "commit.verbose" to true. The only "downside" of it
> > is that users cannot choose to see the diff only when rebasing.
> You could of course add an alias like
> myrebase = -c commit.verbose=true rebase
Hmm, I didn't know about `alias`. Thanks for the information.
> which *should* work.
> However, I am actually slightly in favor of your patch because it *does*
> make it more convenient to have this on during rebases only.
Another option we were discussing is to document that rebase obeys all
commit.* options, instead of adding the rebase.verboseCommit config.
Yes, this way we won't be able to toggle diff for rebase only, but I'm
not sure if that's something users would want to do...
next prev parent reply other threads:[~2019-05-28 17:37 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-17 21:20 [GSoC] Some #leftoverbits for anyone looking for little projects Ævar Arnfjörð Bjarmason
2019-05-20 18:23 ` Matheus Tavares
2019-05-20 23:49 ` Ævar Arnfjörð Bjarmason
2019-05-21 4:38 ` Matheus Tavares Bernardino
2019-05-28 10:37 ` Johannes Schindelin
2019-05-28 17:37 ` Matheus Tavares Bernardino [this message]
2019-05-28 18:16 ` Johannes Schindelin
2019-05-29 9:38 ` Johannes Schindelin
2019-05-29 9:40 ` Johannes Schindelin
[not found] ` <email@example.com>
[not found] ` <CANsrJQdNKiX93GnVXztmvYQQBxr6-HsYNx5UvYXSFg32Op3ZPQ@mail.gmail.com>
[not found] ` <CANsrJQe1YuggxdBHdSdukXRj3myVCTNwLiiWNLrAzPpzA4FOOA@mail.gmail.com>
[not found] ` <firstname.lastname@example.org>
[not found] ` <CANsrJQdJ1wBThUyJ=QSt6NwU8HzQY2VaWc11UfZQ+ktRQs_YTQ@mail.gmail.com>
[not found] ` <email@example.com>
2022-03-20 19:14 ` Having grep support the -o option Jayati Shrivastava
2022-03-22 6:08 ` Christian Couder
2022-03-22 10:50 ` Ævar Arnfjörð Bjarmason
2022-03-23 17:45 ` Jayati Shrivastava
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:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.
Code repositories for project(s) associated with this public inbox
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 read-only IMAP folder(s) and NNTP newsgroup(s).