git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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).