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
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
Richard Braun [off-list ref] writes:
On Sat, Aug 07, 2010 at 08:13:39AM +0530, Ramkumar Ramachandra wrote:
quoted
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
The 07/08/10, Jakub Narebski wrote:
Richard Braun [off-list ref] writes:
quoted
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