Hi Gary. On Wednesday 02 November 2011, Gary V wrote: > > >> package_revision=`$SHELL $ac_aux_dir/git-version-gen .tarball-version` > >> diff --git a/libltdl/.gitignore b/libltdl/.gitignore > >> index 2f39096..5795dbc 100644 > >> --- a/libltdl/.gitignore > >> +++ b/libltdl/.gitignore > >> @@ -2,5 +2,4 @@ > >> /Makefile.am > >> /argz.h > >> /build-aux > >> +/m4 > >> -/dummy.c > >> -/gnulib.mk > >> > > Shouldn't these last two edits be done in a separate patch? > > No, because I don't want to introduce broken revisions that cannot build > into git history. > I think there's a misunderstanding here. What I meant is: since (as far as I can see) dummy.c and gnulib.mk are not touched/moved by this patch, shouldn't any edit to `.gitignore' that involves them better be done in a separate patch? Or am I missing something?
> > Also, > > shouldn't you report the changes to file `libltdl/.gitignore' in > > the ChangeLog entry? > > That's interesting actually. Historically, we have only reported changes > to distributed files in ChangeLog, and have always omitted at least VCS > control files from the log entries. I'm still leaning slightly towards not > introducing ChangeLog noise to describe things that are only important > when you have the full git checkout available, and hence access to git log > and friends if you want to dig this sort of information out -- BUT I could > easily be persuaded to change my mind if you have a good argument for the > advantage of putting this stuff into the git log entry, which would then > eventually be put into the generated ChangeLog file... > I have no strong opinion on the matter (even if I personally prefer, when writing a ChangeLog entry, to mention any non-generated, version-controlled file that gets modified, whther distributed or not). I just wanted to make sure the lack of `.gitignore' mention in the ChangeLog wasn't the result of an overlloking. Regards, Stefano