Brandon Casey <casey@xxxxxxxxxxxxxxx> writes: > Werner LEMBERG wrote: > > [both version 1.6.0.2 and git from 2009-01-24] > > > > I'm going to convert the FreeType CVS repository to git, using Keith > > Packard's `parsecvs'. >From what I understand it is not maintained, is not incremental, and requires access to *,v files. Why not use more modern and actively developed cvs2git tool from cvs2svn project[1]? [1] http://cvs2svn.tigris.org [2] http://git.or.cz/gitwiki/InterfacesFrontendsAndTools "Interaction with other Revision Control Systems" section > > It sometimes happens that there are git entries > > titled > > > > *** empty log message *** > > > > I want to massage the git repository before publishing it, replacing > > those entries with something more meaningful. > > > > The last time I tested this (using git 1.5.something, I no longer > > remember the exact version) I did the following: > > > > . git format-patch <start>..HEAD > > git reset --hard <start> > > > > . Edit the `Subject:' field in the created *.patch files where > > necessary. > > > > . git am --whitespace=nowarn *.patch You can use the following alternate solutions: * git rebase --interactive (perhaps with --root option if your git supports it, or cherry-pick root commit by hand if it does not), changing 'pick' to 'edit' for patches (commits) that you want to modify commit message. * if you can automate the changes, i.e. if you can script it, the best solution would be to use git-filter-branch instead; or use fast-export / fast-import pair with your filter in the middle. > > > > Unfortunately, this no longer works as before, and since I can't find > > a hint in the docs about this change I wonder whether it is a bug. > > > > With git 1.5.something, if the first paragraph of the commit message > > (as output by parsecvs) looks like this > > > > foo foo foo foo > > bar bar bar bar > > baz baz baz baz > > > > it is emitted exactly as-is (after `git format-patch' & `git am'); > > gitk shows `foo foo foo foo' as the first line. However, git version > > 1.6.0.2 and the current git both convert newlines to spaces in the > > first paragraph! I now get > > > > foo foo foo foo bar bar bar bar baz baz baz baz > > > > as the beginning of the commit message which is VERY bad since > > CVS-style entries often have a long first paragraph, causing > > ugly-looking, overlong lines. This is caused by the fact that git-am assumes that subject line goes as first line of commit message, with empty line separating it from the rest of commit message which comes from the body of email. It used to preserve line breaking in Subject: line, if it was broken into lines using continuation style for email headers, but that was wrong solution in the intended use case (applying patches from email, patches conforming to git commit message conventions), as Subject: line could have been broken into multiple lines by the _transport_ layer, and not intended to be broken. > > > > In case this is an intended change I ask you urgently to provide an > > option to get back the old behaviour of `git format-patch' & `git am'. > > I was not aware of this behavior, but it looks like the '-k' option for > both format-patch and git-am is what you want to use. It will prevent > mailinfo from munging the commit message. I think you want undocumented but for the git-am usage (e.g. 'git am -h') --rebasing option to git-am, which makes git-am preserve Subject: line formatting, _including_ line breaking (I think that -k/--keep does preserve subject, but does not preserve line breaking; I haven't checked this, though). Note that in this case you would have to make git-format-patch to not output subject prefix ([PATCH]). See how git-rebase.sh does it. -- Jakub Narebski Poland ShadeHawk on #git -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
