Re: git-commit: allow From: line to be entered in commit message
On Thu, 12 Jan 2006 20:35:54 -0800 Junio C Hamano <junkio@cox.net> wrote:
Show 5 quoted lines
> You are obviously not talking about the use of "git commit" as a
> building block of some script (if you were, it would not make an
> iota of difference whether it is a command line option, an extra
> "echo From: $name" prepending that to the body of the message,
> or setting GIT_AUTHOR_* variables).
Correct. Although, even as a building block script this might
be a nice little touch; as you mentioned it might be able to
simplify the git-am script.
> So you must be talking about some manual process, at the end of
> which the user invokes "git commit" from the command line.
Yes, and in truth I only have a vague notion of his process.
Show 12 quoted lines
> But I would imagine that "git commit" is preceded by a bigger
> process of preparing the tree to the committable state out of
> what is stored in the foreign SCM, after the user figures out
> which commit to pick from (in the original example; the
> committable state may come from something other than SCM ---
> e.g. set of tarballs or patch application or random monkey
> typing). And the whole process of "preparing the tree" and
> "committing" would be done number of times (otherwise we would
> not be having this discussion --- just use GIT_AUTHOR_* which is
> already available), so having to set them as separate steps
> between 'preparing the tree' and 'committing using "git commit"'
> is cumbersome.
Agreed, except even in the one-off case I think being able to set the author info on the command line would be better. The GIT_AUTHOR_* variables only really make sense for defaults, and even that is better handled with .git/config nowadays.
Show 9 quoted lines
>
> But you would write 'preparing the tree' (which may include
> "figuring out who the author is and what the log has to say" if
> the committable state is coming from a foreign SCM) script
> anyway, and I simply do not understand why inserting a couple of
> setting and exporting of GIT_AUTHOR_* variables at the very end
> of that script before calling "git commit" from it, to make it
> not just a 'preparing the tree' script but 'prepare the tree and
> commit' script is such a big deal for you.
Hmmm.. we've already agreed that if there is a script to prepare the tree then this is a non-issue. We're only talking when everything is done from the command line. In fact, i'm suggesting that if you offer this on the command line (or From: line) that fewer scripts would need to be hacked together by git users for some simple cases.
Show 7 quoted lines
> If the committable state does not come from foreign SCM, then
> 'preparing tree' stage may only be able to prepare a committable
> tree, and log and authorship information might need to be
> typed/pasted by the user. But then your script would just do
> "read author" or "${VISUAL-vi} .msgfile" before eventually
> calling 'GIT_AUTHOR_NAME="$author" git commit -F .msgfile' from
> there, so I do not think it is such a big deal either.Yes, this is almost what I emailed to the gentleman in the first place, but as you noted there is more than just one variable to set so you can't do it that way.. you end up having to:
$ export GIT_AUTHOR_NAME="$author" $ GIT_AUTHOR_EMAIL="$email" git commit -F .msgfile
Which is cumbersome and also ends up destroying your defaults if you happen
to use that method, so afterward you have to unset them or reset them back
to your own author info. If git handled a GIT_AUTHOR_COMBINED or some such
where you could give the name and email together in one variable which
would be parsed, then that suggestion would be slightly more palatable
but still seems more obtuse than either just accepting it on the command
line or via a From: line.
Show 5 quoted lines
> I guess the disagreement is primarily coming from that you think
> "git commit" is always the uppermost UI layer, while I feel "git
> commit" is _one_ possible building block of bigger scripts, but
> the true building block is "git commit-tree".
>
Yes, I think you nailed it here. I do see git-commit as a end-user script rather than just a building block.
Sean
sean
