Re: [PATCH Cogito] Make use of external editor work like CVS

[Marcel Holtmann <marcel@holtmann.org>]

Hi Petr,

> > > What is so special about 74 columns? Why not 75 (fmt default), or 72
> > > (emails)?
> > 
> > I ended up with 74, because "CG" has only two letters instead of "CVS"
> > which has three. And cg-log uses a prefix of four whitespaces. This
> > leaves two free characters at the end of a line if your terminal uses a
> > width of 80 characters. The decision was of cosmetic nature.
> 
> Isn't one free character enough?  I'll just stay with 75. :-)

I think it looks a little bit squeezed, but I don't mind at all. Maybe
using 72 is a good idea. However it is only cosmetic and I can change it
to use the fmt default.

> > > Also, I'd prefer the empty line to be always there in front of the CG:
> > > stuff (two empty lines in case of merge - I want to encourage people to
> > > keep possible details w.r.t. the merge separated by an empty line from
> > > the merge information), and when reading it back cg-commit should strip
> > > any trailing empty lines.
> > 
> > I think we should differentiate between the merges. There is no need for
> > additional information if it is an automatic merge (no conflicts) and in
> > general it makes no sense to open the editor (until forced). I wanted to
> > address this later. And yes in case of a manual merge it is a good idea
> > to add two extra empty lines at the top.
> 
> Not so. I frequently write a brief summary of what I'm actually merging.
> I'm not forcing you to do so too, but I personally think it's a good
> idea, and want to do it in the future too. :-)

What do you think about a special flag for automatic merging (which
makes the commit message say "Automatic merge") and a .cogitorc file
like .cvsrc where you can choose the default method.

I am using a lot of temporary trees where I pull a lot of kernel
subsystems together and I don't need that "feature" there.

> > This is only cosmetic. Using vim it displays the name of the temporary
> > file and confusing the user with gitci2.XXXX instead of gitci.XXX is
> > weird. Even using gitci as basename looks not good to me, but I left it
> > for now.
> 
> It boosts the patch size unnecessarily. It shouldn't be called gitci2
> anyway... :-) Feel free to change the mktemp templates instead.

I will check what I can do, but I don't really care that much about the
patch size ;)

> The gitci name comes all the way from the times where this command was
> usually triggered by 'git ci'.

I thought so. Is using cogito.XXXXXX and cogito.temp.XXXXX fine with
you?

> > Index: cg-commit
> > ===================================================================
> > --- f00d7589973e8ea65d2264f5fbac82e1b217dc8f/cg-commit  (mode:100755)
> > +++ cb61efa8a01400150162af9b0f3773f21d502fe9/cg-commit  (mode:100755)
> > @@ -94,30 +78,55 @@
> >  		echo "$uri" >>$LOGMSG
> >  		[ "$msgs" ] && echo "$uri"
> >  	done
> > -	echo >>$LOGMSG
> > +else
> > +	first=1
> >  fi
> > -first=1
> > +
> >  for msg in "${msgs[@]}"; do
> >  	if [ "$first" ]; then
> >  		first=
> >  	else
> >  		echo >>$LOGMSG
> >  	fi
> > -	echo $msg | fmt >>$LOGMSG
> > +	echo $msg | fmt -s -w 74 >>$LOGMSG
> >  done
> > +
> > +if [ "$first" ]; then
> > +	echo >>$LOGMSG
> > +fi
> 
> This mess is still here.

That is not mess. Think about it. If we have messages provided by -m we
want an empty line between the merge message and the the first commit
message. And we don't wanna have an extra empty line at the top if you
provide a commit messages via -m.

Regards

Marcel