If you have lines in a description for a changeset that have # at the start of the line, export of that changeset and subsequent import will lose those description lines during the import. Workaround: put a space in front of # description lines in the export output before running import. example: hg init a cd a echo 0 > a hg ci -A -m 0 a echo 1 > a cat << eof > log 1 # comment for 1 eof hg ci -l log a hg log -v # observe log entry for rev 1 hg export -o p 1 cd .. hg clone -r 0 a b cd b hg import ../a/p hg log -v # observe rev 1 log missing the # line
slightly better title
Patch in crew: http://hg.intevation.org/mercurial/crew/rev/d7452292f9d3
Fixed by http://hg.intevation.org/mercurial/crew/rev/d7452292f9d3 Mads Kiilerich <mads@kiilerich.com> import: don't strip '#' lines from patch descriptions (issue 2417)
I applied this patch to 1.6.4 and it does the job. I probably shouldn't mention this, but if anyone adds a commit log entry that pastes in the comment header from hg export output, it will confuse import, too. No one should do this, but it will happen. I ran into trouble converting cvs repos to hg because someone pasted a cvs log entry directly into a commit message. There may be a better way to do import / export so the record boundaries are more clearly defined and can't be fooled by particular log entries. But it's probably more trouble than it's worth. Anyway, thanks for the fix.
jhein: In what way will CVS log entries confuse import? (I notice however that I ended up pushing a fix that can't handle a "# HG changeset patch" in the commit message.)
The cvs log pasted into a cvs log confused the convert process (cvsps had trouble finding the start/end of a cvs log message when a cvs log entry with meta-data was included in another the commit message), not import. It's not directly relevant to this bug (except as a cautionary tale perhaps where this kind of issue has been seen before). And, yes, the part you mention about the fix not handling "# HG changeset patch" in the commit message is what I was driving at with msg14004 (perhaps not very clearly). I'm still on the fence how to handle such commit messages. Before the fix, it would strip them. After the fix, it will confuse import ("patch: **** Only garbage was found in the patch input"). Both behaviors are suboptimal. The only way to cleanly handle it is an unambiguous way for import to determine beginning and end of the commit log entry. That's hard with the current export format, particularly if you don't have access to the repository containing the exported revisions (if you do, you can use hg log -r to help figure out what the log message actually is). Multiple evils to pick from here: - roll back the fix and return to stripping # lines - leave as is and count on no one using a commit log entry pasted from an export hunk (# comment lines and all) - alter the export format to unambiguously delineate start/end of exported meta-data and logs. I don't have patches for such a beast, but backwards compatibility has to be considered. We need a plan for compatibility before running off to code up this. Maybe just add an export format string. If absent, import falls back to the old way (with its drawbacks). Others? FWIW, I think random lines with # at the front are more likely than someone pasting "# HG changeset patch" in a commit message. Handling the latter could be considered unnecessary apple polishing. That said, someone, somewhere will paste export output with metadata into a commit message. Devoting time to address that eventuality in code vs. just telling users not to do that whenever it does come up (likely rarely) is the tradeoff.
Ok, yes, let's keep convert out of this. Feel free to create another issue and "nosy" me. Note that Mercurial (default branch) no longer falls back to external patch and that the "garbage" message thus no longer should occur. I just pushed a fix for msg14004 so the code now works as I had intended. I'm not sure exactly which remaining cases you are referring to. Could you give some specific examples of the problematic log entries and test them with default branch tip?
Fixed by http://hg.intevation.org/mercurial/crew/rev/80a3d1121c10 Mads Kiilerich <mads@kiilerich.com> import: only the first hg patch marker should be processed (issue2417)
--- Bug imported by bugzilla@serpentine.com 2012-05-12 09:13 EDT --- This bug was previously known as _bug_ 2417 at http://mercurial.selenic.com/bts/issue2417