From: "Marco Costalba" <mcostalba@gmail.com>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "Jan Hudec" <bulb@ucw.cz>, git@vger.kernel.org
Subject: Re: [Qgit RFC] commit --amend
Date: Wed, 4 Jul 2007 14:44:16 +0200 [thread overview]
Message-ID: <e5bfff550707040544l6272bdeao3a891c1793d29eae@mail.gmail.com> (raw)
In-Reply-To: <7vy7hwlpo4.fsf@assigned-by-dhcp.cox.net>
On 7/4/07, Junio C Hamano <gitster@pobox.com> wrote:
> Jan Hudec <bulb@ucw.cz> writes:
>
> >> P.S: Why 'git-commit --amend -F' it's explicitely forbidden?
>
> The reasoning goes like this (here, I am not particularly trying
> to justify it, but am merely explaining the original reasoning
> and intended use case as a historical background):
>
Thanks for your explanation, of course ;-) I think you will agree that...
>
> There is no room for -F, -c, nor -m to make sense for these use
> cases, and giving them to "commit --amend" is most likely a user
> error, and diagnozed as such, because "commit --amend" is an
> end-user level Porcelain program.
>
Why an 'end-user' should _erroneusly_ write '-F' option to 'git commit
--amend' ?
An error IMHO could occur if user *forgets* to write something, not if
he intentionally writes a very specific '-F' option, in that case I
would say user knows what it writes.
And speaking about errors one can always write 'git reset HEAD^' with
worst results.
Probably you agree it's very _artificial_ try to guess what is in the
head of the user and what is not, especially if this guess is made by
a tool.
So I would dare to say this could be a good occasion to remove that
illusory and obscure check.
> But if a Porcelain like StGIT or Qgit would want to do that kind
> of operation for different use case than "amending", it can and
> should use plumbing commands, just like the implementation of
> "commit --amend" does, with different constraints and error
> checks.
>
I always prefer qgit to use the highest level commands as possible because:
1- Less error prone
2- Easier to implement
3- More robust to API change
4- Less easy to break by changes in git.
Having said that, from '-F' option documentation:
-F <file>::
Take the commit message from the given file. Use '-' to
read the message from the standard input.
Jan, what about to use '-' and feed message from stdin?
Indeed the full signature of run() is:
bool Git::run(SCRef runCmd, QString* runOutput, QObject* receiver, SCRef buf)
Where the last parameter 'buf' it's a string that, if not empty, is
passed to the launched program stdin.
I don't know if it is already too late, but I would suggest to stick
to git-commit if possible, I see only downsides in not doing so. But
of course who writes the code decides.
Marco
next prev parent reply other threads:[~2007-07-04 12:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-10 15:08 [Qgit RFC] commit --amend Jan Hudec
2007-06-10 22:10 ` Marco Costalba
2007-06-11 4:42 ` Jan Hudec
2007-06-11 5:24 ` Marco Costalba
2007-06-11 5:45 ` Marco Costalba
2007-07-01 12:26 ` Jan Hudec
2007-07-01 16:09 ` Marco Costalba
2007-07-02 18:03 ` Jan Hudec
2007-07-04 5:10 ` Junio C Hamano
2007-07-04 12:44 ` Marco Costalba [this message]
2007-07-04 18:28 ` Jan Hudec
2007-07-04 19:51 ` Junio C Hamano
2007-07-06 7:54 ` Marco Costalba
2007-07-05 18:54 ` Jan Hudec
2007-07-06 8:12 ` Marco Costalba
2007-07-08 13:38 ` Jan Hudec
2007-07-08 13:49 ` Marco Costalba
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=e5bfff550707040544l6272bdeao3a891c1793d29eae@mail.gmail.com \
--to=mcostalba@gmail.com \
--cc=bulb@ucw.cz \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).