991862 - Allow exporting unapplied patches

Status: RESOLVED FIXED

(Developer Services :: Mercurial: bzexport, defect)

Description

[Steve Fink [:sfink] [:s:]]

I found myself wanting to bzexport an unapplied (and unappliable) patch. It was heavily bitrotten, but I wanted to upload it into a new bug to record it for whenever I (or perhaps a mentee) next get around to it.

Comment 1

[Steve Fink [:sfink] [:s:]]

Attachment: Allow exporting unapplied patches

This does end up changing the existing bug/revision inference logic a bit.

Comment 2

[Ed Morley [:emorley]]

Comment on attachment 8401503 [details] [diff] [review]
Allow exporting unapplied patches

Unfortunately this doesn't seem to apply cleanly against version-control-tools tip, I don't suppose you would mind rebasing so I can test it out?

applying bug-991862-unapplied
patching file hgext/bzexport/__init__.py
Hunk #2 FAILED at 808
1 out of 3 hunks FAILED -- saving rejects to file hgext/bzexport/__init__.py.rej
patch failed, unable to continue (try -v)
patch failed, rejects left in working dir
errors during apply, please fix and refresh bug-991862-unapplied

Comment 3

[Steve Fink [:sfink] [:s:]]

Comment on attachment 8401503 [details] [diff] [review]
Allow exporting unapplied patches

Ah, sorry. I have an |hg pushed| command that does much of the same things as mcmerge does, and it touches a lot of code. I'll reshuffle my queue.

Comment 4

[Steve Fink [:sfink] [:s:]]

Attachment: Allow exporting unapplied patches

I was wrong. The conflicts had nothing to do with the additional command. I had to rebase over a bunch of other stuff. Maybe it was a restyling commit? Dunno.

Comment 5

[Ed Morley [:emorley]]

Comment on attachment 8403063 [details] [diff] [review]
Allow exporting unapplied patches

Review of attachment 8403063 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good - the only thing that needs updating is:

        # Failing that try looking in the commit description for a bug number,
        # since orig_desc could have come from the command line instead.
        if not desc_bug_number:
            commit_firstline = repo[rev].description().decode('utf-8').split('\n', 1)[0]

-> this should now use the first line from description_from_patch, since the current patch won't find a bug number if opts['description'] is set but with no bug. This also fixes the duplication that was already present & I'd been wanting to fix anyway :-)

(In reply to Steve Fink [:sfink] from comment #4)
> I was wrong. The conflicts had nothing to do with the additional command. I
> had to rebase over a bunch of other stuff. Maybe it was a restyling commit?

It was the fix for bug 978034 afaict :-)

Comment 6

[Steve Fink [:sfink] [:s:]]

I think this may have landed. But I have since removed mq support from bzexport, so this bug is no longer valid anyway.