On 9/6/05, Junio C Hamano <[EMAIL PROTECTED]> wrote: > Ryan Anderson <[EMAIL PROTECTED]> writes: > > Sorry about that - I always export using git-format-patch using --mbox, > > and those work nicely. I'm a bit reluctant to do the [PATCH] fixup, but > > I think I will:
Thanks Ryan for the clarification! I hadn't realized it would work correctly with --mbox -- unfortunately it doesn't work very well in the one-file-per-patch (legacy?) mode. Also, telling it _not_ to prompt when it can guess it, is far better (a confirm y/n can still be a good thing if you want to ensure the user gets a chance to review the values guessed). > Martin, --mbox has the added benefit that it consistently > preserves the From: and Date: information even for your own > patches, because it implies --date and --author. By default > without --author and --date these are not preserved from the > original commits for your own patches, primarily because > format-patch without --mbox was written for reorganizing and > reordering existing patches (i.e. export, concatenate some, edit > some hunks, and eventually feed it to applymbox to make commits; > you do not typically want to keep the original author date for > this kind of use). Fair enough -- blame it on my primitive approach of only having 2 working repositories, and having some patches in them that I'm not pushing upstream. Exporting to mbox would mean that I have to edit the mbox file to remove the patches I don't intend to publish. ... and on my naive reading of git-send-email documentation -- it doesn't mention mbox format at all, so I assumed it would expect one patch per file. > Martin, is there a reason you do not want --mbox format > (e.g. format-patch --mbox spits out Subject: line undesirably > formatted while it does what you want without --mbox)? Hmmm -- that I am too lazy to keep several heads or several repos, and organize them to have a "tojunio" branch? So far I've been working on one or two files (archimport) and customizing a couple of others with strictly local changes (git-send-email for instance), so it didn't make sense to formally segregate the heads. A simple review and manual "cherrypicking" of the patches I wanted to send was enough. cheers, martin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html