Re: storing cover letter of a patch series?

[Duy Nguyen <pclouds@gmail.com>]

On Mon, Aug 15, 2016 at 1:28 PM, Stefan Beller <sbeller@google.com> wrote:
> On Sun, Aug 14, 2016 at 12:15 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
>> On Sat, Aug 13, 2016 at 1:49 AM, Duy Nguyen <pclouds@gmail.com> wrote:
>>> On Tue, Aug 9, 2016 at 12:27 AM, Stefan Beller <sbeller@google.com> wrote:
>>>> is what you want. Maybe we want to see a patch that adds the reverse
>>>> functionality as well, i.e. git-am will store the the cover letter as the
>>>> branch description and git-merge will propose the branch description for
>>>> the merge commit.
>>>
>>> I almost suggested the same, but there is a problem with this
>>> approach: if you're are on a detached head, where does git-am save it?
>
> What would the user expect? We can have a range of expectations:
> 1) reject and error out git-am
> 2) warn about not saving branch.description and continue with am
> 3) have a (maybe special) branch.HEAD.description thing, same for FETCH_HEAD etc
> 4) have a config option to choose between 1 and 2, if unset default to 1
>
> I think 3 is a bad choice.
> 4 seems reasonable to me, though I wonder if some people use git-am in
> a scripted workflow with a detached head and then create the branch afterwards?
> So
>
> 5) create a branch for them? (such as $(date)-${subject})
>
> My gut reaction doesn't like 5 either.

I'm starting to think option 6 (storing cover latter as an empty
commit at tip then git-merge replaces it with a merge commit in a
permanent history) may be the way to go. It handles detached heads
just fine, we have reflog to store older cover letters. Though it will
not play nice with 'git commit --amend' and 'git reset' for people who
rewrites history heavily during development, but maybe 'git rebase -i
--autosquash' would be an ok workflow alternative.
-- 
Duy