From: Marcel Holtmann <marcel@holtmann.org>
Date: Sun, 08 May 2005 20:26:55 GMT
Subject: Re: [PATCH Cogito] Make use of external editor work like CVS
Message-ID: <1115584015.8949.43.camel@pegasus>
In-Reply-To: <20050508200334.GG9495@pasky.ji.cz>

Hi Petr,

> > look at the attached patch. We should use "fmt -s" to keep newlines that
> > are inside the commit message and there is one unneeded empty CG: line.
> 
> thanks, fixed and pushed out.

cool. Now I have everything I am used to from CVS, but ...

@@ -113,7 +113,9 @@
                # TODO: Prepend a letter describing whether it's addition,
                # removal or update. Or call git status on those files.
                echo "CG:    $file" >>$LOGMSG
-               [ "$msgs" ] && echo $file
+               if [ "$msgs" ] && ! [ "$forceeditor" ]; then
+                       echo $file
+               fi
        done
 fi

There is no need to print out the files if we start the editor anyway.

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

> > I also put back in the "mess", because if there is no commit message
> > provided via -m it gives us an initial empty line to start in. This is
> > the same that CVS does and it makes the life inside vi a lot more
> > easier.
> 
> Well, I use 'O' to start editing. ;-) (Actually, I use the -m arguments
> extensively; the way it is now is how I always dreamt of it since I
> started using SCMs. Possibly in conjuction with -e to add some fancy
> stuff.)
> 
> Your way might be cunning, fast, or even clever, but it was certainly
> not clear, therefore not maintainable well. I tried to implement it in a
> simpler and more clear way. Does it behave as you want now?

What should I say ;)

I will do a little bit more tests, but it looks very good. Besides the
stuff above.

> > > > If you want the extra newline(s) then it is a good idea to add something
> > > > that strips heading and trailing empty lines from the final commit
> > > > message, because otherwise it will be ugly if you don't enter extra text
> > > > for the merge.
> > > 
> > > Isn't that what I initially suggested? :-)
> > 
> > But this hasn't been done so far. And I don't know any shell tool for
> > this job, beside some crazy awk or sed stuff. However stripspace.c from
> > git-tools can do this job.
> 
> #/bin/sh
> 
> leading=1
> emptylines=0
> while read line; do
>         if ! [ "$line" ]; then
> 		[ "$leading" ] && continue
> 		emptylines=$(($emptylines + 1))
>         else
> 		leading=0
>                 while [ $emptylines -gt 0 ]; do
>                         echo ""
>                         emptylines=$(($emptylines - 1))
>                 done
>                 echo $line
>         fi
> done
> 
> or something? (Based on someone else's script since I was too lazy. ;-)

I am not that script expert anymore. I do most stuff in C now and I am
very happy with it. Maybe someone else comes up with a clever way to
handle the following case:

/*
 * Remove empty lines from the beginning and end.
 *
 * Turn multiple consecutive empty lines into just one
 * empty line.
 */

Regards

Marcel