Re: How to create the " [PATCH 0/5]" first email?

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 15, 2012, 17:08 UTC
Message-ID: <7vzk4rz00y.fsf@alter.siamese.dyndns.org>
In-Reply-To: <F93DBBE1DDAA44A28C9020F9A58FD825@PhilipOakley>

"Philip Oakley" <philipoakley@iee.org> writes:

Show 12 quoted lines

> "Typically it will be placed in a MUA’s drafts folder, edited to add
> timely commentary that should not go in the changelog after the three
> dashes, and then sent as a message whose body, in our example, starts
> with "arch/arm config files were…". On the receiving end, readers can
> save interesting patches in a UNIX mailbox and apply them with
> git-am(1)."
>
> hides a multitude of implicit knowledge steps. Is there an extended
> description of what that would mean from a platform independent
> viewpoint? e.g. if the patches are separte files and an mbox is one
> consolidated file, how to get from one to the other so that 'it' can be
> sent by 'git send-mail'.

If you plan to use "git send-email" to send the final results out, you should consider "git send-email" as your "MUA" in the quoted paragraph. And that will be very platform independent viewpoint to see things from.

"git format-patch -o my-series/ --cover-letter ..." would treat "my-series/" directory as "MUA's drafts folder" and prepares the messages you would want to send out, and you can proof-read and edit the files in there before telling your "MUA" to send them out, with "git send-email ... my-series/*.patch" or something.

> I'm also missing an understanding of the preparation stage where one
> tries to tidy up the various commit messages becaue they weren't
> explicit, specfic nor concise enough,...

Many people usually do "rebase -i" until perfection and then a single final invocation of "format-patch". Of course, the "final" can and should further be proof-read and it is fine to do typofixes in the format-patch output files without going back to the commits before sending them out.

> ...so I suspect that there is an
> implicit `git format-patch` <-> `git am` loop of sharpening the mbox
> patches before submission to the list that I'm missing. Has this 
> described somewhere?