Replacement for cvs2cl, for generating ChangeLog

Hi! I'm considering switching to git for my projects (shishi, gsasl, gnutls, libtasn1, opencdk, ...) and I have some questions:

* How do I discard all locally modified or added files?  'cvs upd -C'
  does some of that, but I've been using a tool 'cvsco' which quickly
  restore a CVS checkout into a pristine state.

* Is there a tool that produce ChangeLog files in the GNU format,
  based on the git logs?  Similar to the 'cvs2cl' tool.  The output
  should look like:

2007-02-22  Simon Josefsson <simon@josefsson.org>

	* link-warning.h, gl/getaddrinfo.c, gl/gnulib.mk, gl/string_.h,
	gl/m4/gnulib-comp.m4, gl/m4/string_h.m4, lgl/Makefile.am,
	lgl/snprintf.c, lgl/snprintf.h, lgl/stdio_.h, lgl/string_.h,
	lgl/unistd_.h, lgl/m4/gnulib-comp.m4, lgl/m4/intdiv0.m4,
	lgl/m4/snprintf.m4, lgl/m4/stdio_h.m4, lgl/m4/string_h.m4,
	lgl/m4/unistd_h.m4: Update.

Thanks, Simon

Simon Josefsson <simon@josefsson.org> writes:

"git reset --hard" (RTFM).

No, but that should probably be trivial. I would suggest you postprocess "git log --pretty --numstat --summary" output, which is probably the most parsable.

Hi,

On Tue, 27 Feb 2007, Simon Josefsson wrote:

The command in git is called "git reset --hard". Beware: this really, 
really loses _all_ local changes. And no need to worry when it completes 
much faster than you expected it to... See "git status" to see that it 
worked, indeed.
 

Let me hack something.

Ciao, Dscho

On Tue, 27 Feb 2007 13:37:23 +0100 (CET) Johannes Schindelin wrote:

But "git reset --hard" won't touch untracked files (this command is similar to "cvs update -C", but does not save old contents anywhere). If what is really needed is to clean out build products, editor backups and other files which are not tracked by git, "git clean -d -x" will do it (but this command will keep local changes to tracked files - an additional "git reset --hard" is needed to restore them to the last committed state).

Sergey Vlasov <vsu@altlinux.ru> writes:

Thanks!  This script solve my original question:

#!/bin/sh # gitco - cruel checkout. Discards everything that has not been # committed, and checkout missing files. git-clean -d -x git-reset --hard

However, one problem with that, compared to 'cvsco', is that 'git-reset --hard' does not tell me tell me which files were deleted and which file were restored. May I suggest a --verbose or similar?

Here is how to use "gitco":

jas@mocca:~/src/libtasn1$ sha1sum foo Makefile.am gendocs.sh sha1sum: foo: No such file or directory e14704b0c3fe4a07e86e4f66df7c6888f619e7dc Makefile.am ea44aed92044fdafffae08a8ec4191ed357e4321 gendocs.sh

# Ok, so we have two files, one which doesn't exists.

jas@mocca:~/src/libtasn1$ echo hej > foo; echo hej >> Makefile.am ; rm gendocs.sh jas@mocca:~/src/libtasn1$ sha1sum foo Makefile.am gendocs.sh 32a0617aab4c9fe725f1b5bc441291180ad25b73 foo e83aa94eb841a329289395f9a88bd5f89a725535 Makefile.am sha1sum: gendocs.sh: No such file or directory

# Ok, one file deleted, one new created, and one modified.

jas@mocca:~/src/libtasn1$ gitco Removing foo

# It isn't that informative...

jas@mocca:~/src/libtasn1$ sha1sum foo Makefile.am gendocs.sh sha1sum: foo: No such file or directory e14704b0c3fe4a07e86e4f66df7c6888f619e7dc Makefile.am ea44aed92044fdafffae08a8ec4191ed357e4321 gendocs.sh

# Ok, back to where we started.

Regards, Simon

As a big fan of cvsco and friends, I admit I often miss that one in git repos.

On Wed, Feb 28, 2007 at 03:08:02PM +0100, Simon Josefsson wrote:

Here is a small change to your script that does just that. It is far from perfect:

- uses cogito and not plain git.  Not sure how to achieve the same
compact layout with plain git - both cogito and stgit forge this type
of output themselves.  Would be great to get it directly from git
itself...

- not very efficient, and not very secure, since we scan the tree once
for reporting and then once for deleting the files, leaving a window
where files could be created by another program after the cg-status
call, and then removed by git-reset.

You've been warned :)

#!/bin/sh # gitco - cruel checkout. Discards everything that has not been # committed, and checkout missing files. git clean -d -x cg status -w git reset --hard

Yann Dirson <ydirson@altern.org> writes:

jas@mocca:~/src/libtasn1$ gitco Removing foo M Makefile.am ! gendocs.sh jas@mocca:~/src/libtasn1$

Perfect!

Thanks, Simon

Hi,

On Tue, 27 Feb 2007, Johannes Schindelin wrote:

See my next three posts. This patch series is on top of "next" (it does not apply cleanly to "master", since the format "format:" conflicts...).

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Wow, that was quick! Thanks. I haven't built my own git yet, so testing this may take some time...

Generally, I can sympathise with those who think this feature should not be in the core git. That would correspond to the cvs2cl tool, it is an external tool that uses cvs internally. However, having it be included in core would be simpler for me. I don't care strongly which approach is chosen (external tool vs included in core), but I can't switch to git for my projects until this is resolved.

/Simon

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

I do not know why you want to pile something like this into builtin-log. It would add maintenance burden and I do not see a gain from it.

One beauty of git is being scriptable. When somebody new asks for something like this, I think it is much more productive to demonstrate the power of scriptability than piling random crap in the core.

Hi,

On Tue, 27 Feb 2007, Junio C Hamano wrote:

Well, I briefly considered writing a little Perl script using the output of "git log --stat".

BUT. GNU ChangeLog is a really often asked-for feature. And before risking some Haskell script producing GNU ChangeLog output in git.git, which I have to rewrite as plugin eventually anyway, I thought that I include it right away.

Demonstrating the ease of Git's core, and hacking on Git was a benefit from it.

As were the first two patches: I think print_wrapped_text() only now got usable. And show_date() with an enum should be an improvement, too.

Anyway, it was the third time I read about such a request, and I had a go at it. If you don't like it, don't take it. I have no problems with that.

Ciao, Dscho

Hi,

On Tue, 27 Feb 2007, Johannes Schindelin wrote:

Side note. I am not a good enough Perl/Shell/Python hacker to know how to wrap text correctly to reflect GNU ChangeLog format. That is why I wrote print_wrapped_text() in the first place.

Ciao, Dscho

On Tuesday 2007 February 27 11:41, Simon Josefsson wrote:

If I understand you correctly ("locally" has slightly ambiguous meaning when the repository is local as well), the following would restore a working directory to be identical to the current HEAD.

 git checkout -f HEAD

The "-f" means force - i.e. don't worry about discarding local changes :-)

Not that I know of, but git has some lovely log generation tools, so I'm sure it could be easily done with a snippet of perl - or perhaps a change to git's own log generator to support

 git-rev-list --pretty=gnucl

would be more appropriate.

Andy

Hi,

On Tue, 27 Feb 2007, Andy Parkins wrote:

I was already hacking on a builtin changelog command, because I was convinced that this breaks our model in builtin-log: We show the commit information first, and _then_ we call the diff machinery. And GNU ChangeLog format mixes these informations: the date and the author are commit information, but the files are tree information, and the oneline is commit information again.

However, your mail made me think again.

I now reused (AKA misused) the stats separator to take the oneline description, which is set in show_log() when revs->commit_format == CMIT_FMT_CHANGELOG, which is output by diff_flush() when the diff_options->output_format == DIFF_FORMAT_CHANGELOG.

BTW I already found a subtle bug. In finalize_changelog(), options->stat_sep can be NULL, if no oneline was found.

But AFAIK we do not allow empty commit messages, so this bug would never have been triggered.

Ciao, Dscho

tisdag 27 februari 2007 13:57 skrev Andy Parkins:

gir-rev-list ??

Extend git-shortlog with --gnucl instead. What seems missing is the grouping of changes by date. git-shortlog only groups by author.

-- robin

Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:

If GNU changelog _were_ to have one entry per day, mixing changes from different commits together, that might be a good approach. I do not think GNU changelog guideline can be _THAT_ broken.

Listing of filenames of changed files in the log, followed by short description of the nature of the change (e.g. "Updated to do blah", "New File"), shows the CVS mentality "File matters", and that was what Simon's original example showed. It's been a while I looked at the coding guideline the last time, but I think GNU convention wants you to say "filename (function)" when applicable. Which I happen to think makes much more sense than the filename alone.

The information that would appear in "log -p --pretty" output needs to be condensed to obtain such a log entry. You _could_ still do that as a built-in if you really wanted to, but I tend to think that it is much better to implement such a specialized processing (for one thing, what a function is depends on the programming language you are reading from) as an external postprocessing filter that people can more easily tweak for their specific needs.

That's why I keep stressing that one good thing about git is it is easily scriptable.

Hi,

On Tue, 27 Feb 2007, Junio C Hamano wrote:

It would be easy to write a consume() function (called with context == 0) which takes the information from the "@@" lines.

But the builtin -- as the script -- would suffer from the following problem:

-- snip -- +} + +static int new_function(void) -- snap --

IMHO it is easier to get right as a builtin. But as I said, I am not feeling too strongly about it.

Ciao, Dscho

Hi,

On Tue, 27 Feb 2007, Robin Rosenberg wrote:

No, the revision walker groups by commit (not by date, but you don't want that anyway). git-shortlog works _on top_ of the revision walker.

The sane thing _is_ to use the revision walker.

Given the amount of projects using cvs2cl (I personally saw a couple), I expect a couple of people to speak up in favour of including support for --pretty=cl or =changelog or =gnucl or whatever.

Ciao, Dscho

FYI, the GNU ChangeLog format is actually documented, see:

http://www.gnu.org/prep/standards/html_node/Change-Logs.html

And some parts of it (function names, CPP macro conditionals) are quite neat, although I'm not sure how much of it can be automatically generated, or if that is even something you'd want.

/Simon