# Maildir ordering in git-mailsplit (was: Using mutt as a git maintainer) 4 messages from 2010-08-07 to 2010-08-10. Participants: Ramkumar Ramachandra, Richard Braun, Jakub Narebski, Nicolas Sebrecht. Thread: https://gitlist.dev/t/24656 ## Ramkumar Ramachandra, 2010-08-07 02:43 Subject: Maildir ordering in git-mailsplit (was: Using mutt as a git maintainer) Message-ID: <20100807024337.GA15410@kytes> URL: https://gitlist.dev/e/20100807024337.GA15410%40kytes In-Reply-To: <20100806222847.GA4240@sceen.net> ``` Hi Richard, Richard Braun writes: > I'm currently setting up several git repositories, both for personal stuff > and at work, and I also am an avid Mutt user. But I have a problem with the > "braindamaged" git-mailsplit program and how it interacts badly with how > Mutt does some things. > > The specific case that troubles me is when using git send-email with several > patches, say around 10, then getting those in my lovely Mutt as one thread, > with chainreplyto set to false because i'm a nice person who RTFM. Until now > everything looks perfect. Then I tag the thread and copy it out to a > temporary mailbox so that I can run git am and do something else with my > life. Problem: I use Maildir mailboxes, and with several files, mutt doesn't > preserve the order of the patches. As git-mailsplit uses a raw opendir() > to access patches in Maildir format, and doesn't try to sort anything after, > some patch series just won't apply simply. Ah, it looks like this problem went unnoticed probably because everyone uses mboxes. One possible solution would be to teach `git-mailsplit` to order the emails correctly. You can reply with an RFC patch; I've CC'ed the Git list on this email. > I'm using git 1.5.6.5 and Mutt 1.5.18 (from Debian lenny), pretty old but > after checking the most recent source code, it just seems to be the same. Yeah, I don't think git-mailsplit has changed in some time. -- Ram ``` ## Richard Braun, 2010-08-07 11:21 Subject: Re: Maildir ordering in git-mailsplit (was: Using mutt as a git maintainer) Message-ID: <20100807112159.GA12015@sceen.net> URL: https://gitlist.dev/e/20100807112159.GA12015%40sceen.net In-Reply-To: <20100807024337.GA15410@kytes> ``` On Sat, Aug 07, 2010 at 08:13:39AM +0530, Ramkumar Ramachandra wrote: > Hi Richard, > > Ah, it looks like this problem went unnoticed probably because > everyone uses mboxes. One possible solution would be to teach > `git-mailsplit` to order the emails correctly. You can reply with an > RFC patch; I've CC'ed the Git list on this email. Well, if everybody else has survived for five years with mbox patch series, I guess I can do that too. With some not-so-difficult work, I managed to have Mutt do what I wanted (that is, saving patch series in mbox files in one macro and keep everything else with Maildir folders untouched). After some digging in the code, it doesn't look like a git issue. When a Maildir folder is processed, its entries are actually sorted, unlike what I first thought. populate_maildir_list() calls string_list_insert() (in string-list.c) which does insertion sort through its static add_entry() and get_entry_index() functions which use a bare strcmp() to compare file names (it was path-list.c back in Git 1.5, same code). When copying a threaded patch series in a Maildir folder with Mutt, here are the names created: 1281177008.8677_101.myhostname:2, 1281177008.8677_103.myhostname:2, 1281177008.8677_105.myhostname:2, 1281177008.8677_107.myhostname:2, 1281177008.8677_109.myhostname:2, 1281177008.8677_111.myhostname:2, 1281177008.8677_113.myhostname:2, 1281177008.8677_11.myhostname:2, 1281177008.8677_13.myhostname:2, 1281177008.8677_15.myhostname:2, 1281177008.8677_17.myhostname:2, 1281177008.8677_19.myhostname:2, 1281177008.8677_1.myhostname:2, 1281177008.8677_21.myhostname:2, 1281177008.8677_23.myhostname:2, And for such names, git am determines that e.g. "1281177008.8677_107.myhostname:2", should be applied before "1281177008.8677_17.myhostname:2,", which is obviously wrong. I'm not sure about what depends on string-list.c, but based on the output of a raw grep, it doesn't seem like a good idea to change the way strings are sorted, especially if almost noone uses Maildir for patch series. The best solution IMO would be a Mutt hook to alter the file names or something like that. A good workaround is configuring it to use mbox as the default format and keep existing folders as Maildirs (that's what I'm doing now). I guess the only file to patch in any case is Documentation/SubmittingPatches, adding an entry for Mutt in the MUA hints part (if possible with the renaming hook if someone knows how to do that - I'll search a bit on my side - or with an explanation of the issue and the simple mbox workaround). -- Richard Braun ``` ## Jakub Narebski, 2010-08-07 13:23 Subject: Re: Maildir ordering in git-mailsplit (was: Using mutt as a git maintainer) Message-ID: URL: https://gitlist.dev/e/m3eieao8uh.fsf%40localhost.localdomain In-Reply-To: <20100807112159.GA12015@sceen.net> ``` Richard Braun writes: > On Sat, Aug 07, 2010 at 08:13:39AM +0530, Ramkumar Ramachandra wrote: > > > > Ah, it looks like this problem went unnoticed probably because > > everyone uses mboxes. One possible solution would be to teach > > `git-mailsplit` to order the emails correctly. You can reply with an > > RFC patch; I've CC'ed the Git list on this email. > > Well, if everybody else has survived for five years with mbox patch > series, I guess I can do that too. With some not-so-difficult work, I > managed to have Mutt do what I wanted (that is, saving patch series in > mbox files in one macro and keep everything else with Maildir folders > untouched). > > After some digging in the code, it doesn't look like a git issue. When > a Maildir folder is processed, its entries are actually sorted, unlike > what I first thought. populate_maildir_list() calls string_list_insert() > (in string-list.c) which does insertion sort through its static > add_entry() and get_entry_index() functions which use a bare strcmp() to > compare file names (it was path-list.c back in Git 1.5, same code). > When copying a threaded patch series in a Maildir folder with Mutt, here > are the names created: > 1281177008.8677_101.myhostname:2, > 1281177008.8677_103.myhostname:2, [...] > 1281177008.8677_11.myhostname:2, > 1281177008.8677_13.myhostname:2, > 1281177008.8677_15.myhostname:2, > 1281177008.8677_17.myhostname:2, > 1281177008.8677_19.myhostname:2, > 1281177008.8677_1.myhostname:2, > 1281177008.8677_21.myhostname:2, > 1281177008.8677_23.myhostname:2, > > And for such names, git am determines that e.g. > "1281177008.8677_107.myhostname:2", should be applied before > "1281177008.8677_17.myhostname:2,", which is obviously wrong. > > I'm not sure about what depends on string-list.c, but based on the > output of a raw grep, it doesn't seem like a good idea to change the > way strings are sorted, especially if almost noone uses Maildir for > patch series. [...] Would it be really that difficult to implement "version sort" in git (like 'ls -v' / 'ls --sort=version' does), using strverscmp (and provide fallback in compat/), and use it in git-am? -- Jakub Narebski Poland ShadeHawk on #git ``` ## Nicolas Sebrecht, 2010-08-10 17:54 Subject: Re: Maildir ordering in git-mailsplit (was: Using mutt as a git maintainer) Message-ID: <20100810175411.GA13084@vidovic> URL: https://gitlist.dev/e/20100810175411.GA13084%40vidovic In-Reply-To: ``` The 07/08/10, Jakub Narebski wrote: > Richard Braun writes: > > > > I'm not sure about what depends on string-list.c, but based on the > > output of a raw grep, it doesn't seem like a good idea to change the > > way strings are sorted, especially if almost noone uses Maildir for > > patch series. [...] I do use maildir but never hit this problem (or never seen it, at least) probably because I often purge the maildir "_patches" where I store patch series. > Would it be really that difficult to implement "version sort" in git > (like 'ls -v' / 'ls --sort=version' does), using strverscmp (and > provide fallback in compat/), and use it in git-am? Yeah, it would be nice to fix this bug. I don't have time these days but I'm marking this thread to look further later. -- Nicolas Sebrecht ```