provide a subcommand to convert a git sha to ubuntu patch

Bug #1673714 reported by Christian Ehrhardt  on 2017-03-17
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

I know these are clearly feature requests, but I tried to outline my usual manual steps in bugs to provide us a chance to make usd even better.

Another thing I often to after adding an upstream repo (see bug 1673710) is converting a sha of the upstream git into a dquilt patch.
That is mostly useful for SRU work but can also be handy on merges if you want Debian plus a bit from upstream.

I happened to realize I do too often things like:
git show ABC > /tmp/foo.patch
dquilt push -a
dquilt import -P ubuntu/newname-from-patch-subject.patch /tmp/foo.patch
dquilt push
# resolve issues if needed
dquilt pop -a
git add debian/patches/series debian/patches/ubuntu/newname-from-patch-subject.patch
git commit -s -m "similar to patch subject plus LP ref (LP: #12345)"
Then I go for the changelog, but even that could partially be created by the patch content and knowing the patch filename - maybe one could specify a LP number as well.

Surely can be done in other ways (e.g. use format-patch for the names)

Everything that people type often might be worth to automate, and this is one.
If I missed a git tool that mostly does that for me please let me know.
Otherwise I'd think a "usd sha-to-dquilt hash LP12345" command might be handy for more than just me.

Nish Aravamudan (nacc) wrote :

What is 'dquilt'?

Nish Aravamudan (nacc) on 2017-04-07
Changed in usd-importer:
status: New → Incomplete

dquilt info
Feel free to ping for discussion as needed.

Changed in usd-importer:
status: Incomplete → New
Nish Aravamudan (nacc) on 2017-08-02
Changed in usd-importer:
importance: Undecided → Wishlist
milestone: none → future
status: New → Triaged
status: Triaged → Confirmed
Robie Basak (racb) on 2017-08-02
tags: added: workflow
Robie Basak (racb) wrote :

How about something like this:

git ubuntu quilt is a new subcommand to do rich quilt operations, where by rich I mean that it's smart about being in a git ubuntu repository.

git ubuntu quilt cherry-pick <commitish> could then do the equivalent of "quilt new". It could add some dep3 headers by default (eg. Last-Update) and, with optional arguments, also put in the Bug URLs and so forth. It could potentially even do "Origin: upstream, <hash>" if it can be heuristically determined that the commitish provided corresponds to upstream, for example is there is a remote called upstream, upstream/master exists and the commitish is reachable from upstream/master.

I totally like the suggestion, but I'd want to add one thing - please let the default be a "this is what I'd do - Y/N"

So it would do it's heuristics and could have provide an output like:

Would add this patch:
Control Content
--desc Description: foo
--longdesc Bar
             Bar Bar
--bug Bug-Ubuntu: http...
--date Last-Updated:
--origin Origin: http://foo/bar.patch or commit §$%& from $%&/

Do you want to commit this change Y/N

So you'd
a) see before things are done
b) directly see which control helps you to override heuristics

And for this operation I think this mode should be the default.
An --non-interactive is fine, but the default should help to avoid small mistakes that then have to be corrected with more effort than needed if we'd modify it before the commit.

Robie Basak (racb) wrote :

I like the idea of making it clear what the heuristic proposes and telling the user exactly what option to override.

I'm not so keen on the user interaction for the command to complete. Of course I could add a -y flag for scripting purposes, but that's an additional thing and divergent behaviour from the other commands that don't currently prompt.

What if I print all of that, commit it instead of prompting, but also print the correct "git reset --hard" command to undo, ready to copy and paste if the user is not happy with the heuristic result?

Robie Basak (racb) wrote :

To be clear, I don't intend on working on this soon. I was just driving past and I like to have features defined. Then anybody can implement :)

While I'd prefer the default to be prompting I'm not on a mission to zealously convince you.
I think I could live with Report what has been done + "if you want to modify use git reset ...".
BTW - The actual diff content can be shortened on this btw, mostly interested on headers and lets say one hunk.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers