From: Junio C Hamano <gitster@pobox.com>
To: Kirill Likhodedov <kirill.likhodedov@jetbrains.com>
Cc: git <git@vger.kernel.org>
Subject: Re: Remove help advice text from git editors for interactive rebase and reword
Date: Sun, 23 Jul 2017 15:09:54 -0700 [thread overview]
Message-ID: <xmqqshhmerf1.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <241D60E0-1687-4DD8-A18C-CF7310DBFAEB@jetbrains.com> (Kirill Likhodedov's message of "Sun, 23 Jul 2017 13:03:49 +0300")
Kirill Likhodedov <kirill.likhodedov@jetbrains.com> writes:
> My motivation is the following: I'm improving the Git client
> inside of IntelliJ IDEA IDE and I would like to provide only the
> plain commit message text to the user (any hints can be shown
> separately, not inside the editor).
Who is running "git commit --amend" and "git rebase -i" in the
workflow of a user of your tool? Is it the end user who types these
commands to the shell command prompt, or does your tool formulate
the command line and does an equivalent of system(3) to run it?
I am assuming that the answer is the latter in my response.
> If there is no way to do it now, do you think it makes sense to
> provide a configuration variable for this, e.g. to introduce more
> advice.* config variables in addition to existing ones?
Not at all interested, as that would mean your tool will tell its
users to set such a configuration variable and their interactive use
of Git outside your tool will behave differently from other people
who use vanilla Git, and they will complain to us.
But I do not think adding a new command line option that only is
passed by a tool like yours when it runs "git rebase -i" via
system(3) equivalent would introduce such an issue, so that may be
workable.
But stepping back a bit, as you said in the parentheses, your tool
would need to grab these "hints" from Git, instead of having a
separate hardcoded hints that will go stale while the underlying Git
command improves, to be able to show them "separately". Which means
to me that you would need to get the output Git would normally show
to the end user and do your own splitting and parsing anyway. Which
in turn would mean that a configuration or a command line option to
squelch these, which would rob your tool the ability to read what
Git would have told to your users, would be a bad idea and not a
useful addition to the overall system. So...
next prev parent reply other threads:[~2017-07-23 22:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-23 10:03 Remove help advice text from git editors for interactive rebase and reword Kirill Likhodedov
2017-07-23 12:42 ` Alexei Lozovsky
2017-07-23 22:09 ` Junio C Hamano [this message]
2017-07-23 22:26 ` Kirill Likhodedov
2017-07-24 17:23 ` Jeff King
2017-07-24 18:47 ` SZEDER Gábor
2017-07-24 21:47 ` 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=xmqqshhmerf1.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=kirill.likhodedov@jetbrains.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.