[both version 1.6.0.2 and git from 2009-01-24]
Folks,
I'm going to convert the FreeType CVS repository to git, using Keith
Packard's `parsecvs'. 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
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.
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'.
Werner
Hi,
[welcome on the Git list, Werner!]
On Wed, 25 Feb 2009, Werner LEMBERG wrote:
[both version 1.6.0.2 and git from 2009-01-24]
Folks,
I'm going to convert the FreeType CVS repository to git, using Keith
Packard's `parsecvs'. 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
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.
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'.
It is an intended change, for the _opposite_ case: some people thrive on
overly-long subject lines, and the change was supposed to help them.
I was not sure if it would be a good change back then, but I did not have
anything concrete I could present as an example where the behavior hurts.
In your case, I suggest using something different, though. Either use
"rebase -i" and mark the commits you want to massage as "edit", or use
"fast-export > dump", edit "dump" by hand, and then reimport the whole
thing using fast-import.
IMHO your use case is not a good candidate for format-patch, as that
program was really meant for patch submission (even if it also serves
other purposes pretty well).
Ciao,
Dscho
Werner LEMBERG wrote:
[both version 1.6.0.2 and git from 2009-01-24]
Folks,
I'm going to convert the FreeType CVS repository to git, using Keith
Packard's `parsecvs'. 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
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.
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.
-brandon
Brandon Casey [off-list ref] writes:
Werner LEMBERG wrote:
quoted
[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
quoted
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.
quoted
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.
quoted
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