From: Duy Nguyen Date: Mon, 15 Aug 2016 09:40:51 GMT Subject: Re: storing cover letter of a patch series? Message-ID: In-Reply-To: On Mon, Aug 15, 2016 at 1:28 PM, Stefan Beller wrote: > On Sun, Aug 14, 2016 at 12:15 AM, Jacob Keller wrote: >> On Sat, Aug 13, 2016 at 1:49 AM, Duy Nguyen wrote: >>> On Tue, Aug 9, 2016 at 12:27 AM, Stefan Beller 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