From: Ted Pavlic <ted@tedpavlic.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: gitster <gitster@pobox.com>, git <git@vger.kernel.org>
Subject: Re: [PATCH] Added giteditor script to show diff while editing commit message.
Date: Wed, 21 Jan 2009 17:33:45 -0500 [thread overview]
Message-ID: <4977A2C9.1070502@tedpavlic.com> (raw)
In-Reply-To: <alpine.DEB.1.00.0901212216310.3586@pacific.mpi-cbg.de>
Thanks for your comments. I've responded below. I just want to
top-respond to your comment that the fundamental problem is that the
diff is in a separate file. In fact, this is the point of the script. I
want to be able to scroll through the diff output independent of the
commit message.
(alternatively, I realize I could do "git commit -v" and then use my
editor's "split window" support, but that wouldn't help me with "stg edit")
> the subject could use some work. For example, I would prefix it with
...
>> From: Ted Pavlic<ted@tedpavlic.com>
>
> As this is exactly what your email said in its header, it is redundant
> information. Worse, it is information that made me look back to know why
> it needs to be there. Distracting.
I add --from to my gitsend alias to prevent git send-email from
prompting me for a "From". Is there a way to have git send-email simply
not prompt me for "From"?
> What information does the README add that is not in the script itself?
> If there is none, please refrain from adding the README to begin with.
OK. I noticed plenty of other not-very-useful READMEs in contrib/, and
so I figured it was a pro forma file.
>> +# Find git
>> +[ -z "${GIT}" ]&& GIT="git"
> Yes, I know it is contrib/, but you may want to adopt Git's coding style
> early.
Ok. Switching to test.
> Besides, I find it funny that you want to override git with $GIT.
Isn't it possible that someone has git somewhere else?
>> +# If we recognize a popular editor, add necessary flags
>> +case "${EDITOR}" in
>> + emacs)
>> + EDITOR="${EDITOR} -nw"
>
> Mhm. Should this not be the user's choice? Some like emacs to start up
> in a window.
I don't use emacs, but it was my impression that the "no window" flag
was added to make sure that emacs doesn't fork. That's why "-f" is used
in the vim line.
>> +# End GITTMP in ".git" so that "*.git/" syntax highlighting recognition
>> +# doesn't break
>> +GITTMP="${TMPDIR-/tmp}/giteditor.$RANDOM.$RANDOM.$RANDOM.$$.git"
>> +(umask 077&& mkdir "${GITTMP}") || {
>> + echo "Could not create temporary directory! Exiting." 1>&2
>> + exit 1
>> +}
>
> Umm. Why? Why do you need a temporary .git directory?
The script generates a new "diff" file that I would rather drop
elsewhere (e.g., in a /tmp directory) rather than here in the current
directory.
However, maybe you're right. After all, stg drops ".stgit-edit.txt" in
the working directory. I suppose I could use gitdir, but I wasn't sure
if it was safe to pollute gitdir.
In the next version, I'll get rid of the temp directory and put the file
here.
>> + # Diff is non-empty, so edit msg and diff
>> + ${EDITOR} "${GITTMP}/${COMMITMSG}" "${GITTMP}/diff" || exit $?
>
> vi users will hate you, as you do not give them a chance to edit the
> message after having seen the diff.
I don't see what you mean. I am a vi user (exclusively), and this script
works very well for me.
The "-f -o" flags above ensure that gvim will not fork. I'll add "vi" to
the search string that automatically add "-f -o". Will that satisfy you?
At the moment, giteditor works exactly like EDITOR (or VISUAL) for me,
but it opens up a second buffer (split in the bottom window in my case)
with the diff in it. I'm given the opportunity to save.
> git commit will abort anyway if the commit message has not changed. Plus,
> it does a better job, as it checks only the non-commented-out text.
Okay. Using $1 exclusively.
> BTW why on earth do you put every single variable name in curly brackets?
I always thought that was good practice. It prevents ambiguity, and *I*
don't think it's an eyesore.
> Besides all that criticism, there is also a fundamental issue. The diff
> is in a separate file.
That's the point. If I wanted to put the diff in the commit buffer, I
would have used "git commit -v". I think many would like to be able to
scroll through the diff without having to scroll through the commit.
Is there no value in having the diff in a separate file?
Thanks --
Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
next prev parent reply other threads:[~2009-01-21 22:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-21 20:47 [PATCH] Added giteditor script to show diff while editing commit message ted
[not found] ` <0E82F261-2D96-4204-9906-C5E8D47E9A5D@wincent.com>
2009-01-21 21:07 ` Ted Pavlic
2009-01-21 21:46 ` Johannes Schindelin
2009-01-21 22:33 ` Ted Pavlic [this message]
2009-01-21 22:45 ` [PATCH] contrib: A script to show diff in new window " Ted Pavlic
2009-01-21 23:59 ` Junio C Hamano
2009-01-22 3:39 ` Ted Pavlic
2009-01-22 3:50 ` Ted Pavlic
2009-01-22 7:49 ` Junio C Hamano
2009-01-21 22:52 ` [PATCH] Added giteditor script to show diff " Johannes Schindelin
2009-01-22 1:46 ` Ted Pavlic
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=4977A2C9.1070502@tedpavlic.com \
--to=ted@tedpavlic.com \
--cc=Johannes.Schindelin@gmx.de \
--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 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.