git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] Implement git-quiltimport (take 2)

From
Eric W. Biederman <ebiederm@xmission.com>
Date
May 17, 2006, 19:20 UTC
Message-ID
<m1zmhg31cm.fsf@ebiederm.dsl.xmission.com>
In-Reply-To
<7vsln8cwn6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
Show 18 quoted lines
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> Importing a quilt patch series into git is not very difficult
>> but parsing the patch descriptions and all of the other
>> minutia take a bit of effort to get right, so this automates it.
>>
>> Since git and quilt complement each other it makes sense
>> to make it easy to go back and forth between the two.
>>
>> If a patch is encountered that it cannot derive the author
>> from the user is asked.
>
> What's the expected workflow for you to work on a 1300 patch
> series you get from Andrew in the next installment to deal with
> 88 unattributed patches?  Answer the question 88 times and make
> sure you get the answers right every time?  Or abort and
> hand-edit them to help mailinfo to notice the correct
> attribution and re-run?

For the internal consumption case it isn't a big deal. I can specify --author with something bogus and it works.

There are a few tweaks that can be made to git-mailinfo to make it better at parsing information out of patches. I cut the list down to about 49 that way. I had it all of the way down to 1. But then I realized that the first Singed-off-by really doesn't accurately reflect the author. I suspect a few of my other teaks are equally suspicious.

Show 6 quoted lines
> I know I am guilty of suggesting "going interactive", but I have
> a feeling that having an optional file that maps patch-name to
> author might be easier to work with.  If the old patches are
> recycled in the updated -mm set, you probably can reuse the
> mapping for them, adding entries for newly introduced "unnamed"
> patches as needed.

Short of getting the script where it has a sane restart in the middle mode going interactive and asking questions makes a lot of sense. Especially with smaller trees.

For Andrews tree before I play anymore with technical solutions I need to talk to Andrew and see if we can improve the situation upstream. Possibly with a quilt-audit script that finds problem patches.

Eric
Previous: Junio C HamanoNext: Junio C Hamano
Message 9 of 24 in “Implement git-quiltimport”
  1. Implement git-quiltimportEric W. Biederman, May 16, 2006
  2. Linus TorvaldsMay 16, 2006
  3. Eric W. BiedermanMay 16, 2006
  4. Junio C HamanoMay 16, 2006
  5. Eric W. BiedermanMay 17, 2006
  6. Junio C HamanoMay 17, 2006
  7. Implement git-quiltimport (take 2)Eric W. Biederman, May 17, 2006
  8. Junio C HamanoMay 17, 2006
  9. Eric W. BiedermanMay 17, 2006
  10. Junio C HamanoMay 17, 2006
  11. Eric W. BiedermanMay 18, 2006
  12. Greg KHMay 19, 2006
  13. Eric W. BiedermanMay 20, 2006
  14. Greg KHMay 20, 2006
  15. Eric W. BiedermanMay 21, 2006
  16. Junio C HamanoMay 21, 2006
  17. Eric W. BiedermanMay 21, 2006
  18. Junio C HamanoMay 21, 2006
  19. Eric W. BiedermanMay 21, 2006
  20. Greg KHJun 1, 2006
  21. Eric W. BiedermanJun 2, 2006
  22. Eric W. BiedermanMay 19, 2006
  23. Implement a --dry-run option to git-quiltimportEric W. Biederman, May 17, 2006
  24. Linus TorvaldsMay 17, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.