From: Marcel Holtmann <marcel@holtmann•org>
To: Petr Baudis <pasky@ucw•cz>
Cc: GIT Mailing List <git@vger•kernel.org>
Subject: Re: [PATCH Cogito] Make use of external editor work like CVS
Date: Sun, 08 May 2005 23:19:11 +0200 [thread overview]
Message-ID: <1115587151.8949.74.camel@pegasus> (raw)
In-Reply-To: <20050508210857.GL9495@pasky.ji.cz>
Hi Petr,
> > @@ -122,10 +124,10 @@
> > if tty -s; then
> > if ! [ "$msgs" ] || [ "$forceeditor" ]; then
> > ${EDITOR:-vi} $LOGMSG2
> > - fi
> > - if ! [ "$msgs" ] && ! [ $LOGMSG2 -nt $LOGMSG ]; then
> > - rm $LOGMSG $LOGMSG2
> > - die 'Commit message not modified, commit aborted'
> > + if ! [ $LOGMSG2 -nt $LOGMSG ]; then
> > + rm $LOGMSG $LOGMSG2
> > + die 'Commit message not modified, commit aborted'
> > + fi
> > fi
> > else
> >
> > If you provide a commit message via -m and then close the editor without
> > changing it, it will commit the message. I think that will not be the
> > intention of the user.
>
> Now, this is a pretty difficult question. The only other place in the
> Cogito toolkit which uses cg-commit -e is now cg-init when doing the
> initial commit - and you definitively want to commit even if the message
> was not modified in that case. Also, what if you want to just review
> how the -m stuff flows like before committing?
>
> OTOH, we might want to stay consistent in behaviour and always abandon
> action when the file was not modified (except for the initial commit).
> Perhaps some -E for that? Other thoughts?
I think using -E to commit even when you don't modify the commit message
is a good idea. The alternative way is to ask the user like CVS does.
> > /*
> > * Remove empty lines from the beginning and end.
> > *
> > * Turn multiple consecutive empty lines into just one
> > * empty line.
> > */
>
> Bah, that's even easier when you want to squeeze the empty lines inside
> of the commit message. I don't, though.
You can do that with "cat -s", I know. But then you still have to look
at the first and the last line and delete it if they are empty.
I think it is a good idea to squeeze empty lines, because multi empty
lines are not useful for commit messages anyway. What do you think?
Regards
Marcel
next prev parent reply other threads:[~2005-05-08 21:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-08 15:02 [PATCH Cogito] Make use of external editor work like CVS Marcel Holtmann
2005-05-08 15:24 ` Sean
2005-05-08 15:25 ` Petr Baudis
2005-05-08 15:43 ` Marcel Holtmann
2005-05-08 15:56 ` Petr Baudis
2005-05-08 16:15 ` Marcel Holtmann
2005-05-08 17:12 ` Petr Baudis
2005-05-08 17:17 ` Marcel Holtmann
2005-05-08 17:30 ` Petr Baudis
2005-05-08 17:40 ` Marcel Holtmann
2005-05-08 17:51 ` Petr Baudis
2005-05-08 18:57 ` Marcel Holtmann
2005-05-08 20:03 ` Petr Baudis
2005-05-08 20:26 ` Marcel Holtmann
2005-05-08 21:08 ` Petr Baudis
2005-05-08 21:19 ` Marcel Holtmann [this message]
2005-05-09 3:28 ` Edgar Toernig
2005-05-09 7:33 ` Petr Baudis
2005-05-08 21:46 ` Sean
2005-05-08 21:43 ` Marcel Holtmann
-- strict thread matches above, loose matches on Subject: below --
2005-05-08 1:10 Marcel Holtmann
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=1115587151.8949.74.camel@pegasus \
--to=marcel@holtmann$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=pasky@ucw$(echo .)cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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