Maildir ordering in git-mailsplit (was: Using mutt as a git maintainer)

Maildir ordering in git-mailsplit (was: Using mutt as a git maintainer)

[Ramkumar Ramachandra]

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

Re: Maildir ordering in git-mailsplit (was: Using mutt as a git maintainer)

[Richard Braun]

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

Re: Maildir ordering in git-mailsplit (was: Using mutt as a git maintainer)

[Jakub Narebski]

Richard Braun <rbraun@sceen.net> 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

Re: Maildir ordering in git-mailsplit (was: Using mutt as a git maintainer)

[Nicolas Sebrecht]

The 07/08/10, Jakub Narebski wrote:
> Richard Braun <rbraun@sceen.net> 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