From: "Duy Nguyen" <pclouds@xxxxxxxxx>
On Mon, Aug 15, 2016 at 1:28 PM, Stefan Beller <sbeller@xxxxxxxxxx> wrote:
On Sun, Aug 14, 2016 at 12:15 AM, Jacob Keller <jacob.keller@xxxxxxxxx>
wrote:
On Sat, Aug 13, 2016 at 1:49 AM, Duy Nguyen <pclouds@xxxxxxxxx> wrote:
On Tue, Aug 9, 2016 at 12:27 AM, Stefan Beller <sbeller@xxxxxxxxxx>
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.
--
[sorry if this is not the right place to 'drop in'..]
I appreciate there has been a lot of discussion, but it mainly appears to be
about an upstream / integration viewpoint.
I'd hate it if there was a one size fits all solution that was only focused
on one important use case, rather than having at least a simple fallback for
simple folk.
Personally I liked the idea that I could start my patch series branch with a
simple 'empty' commit with a commit message that read "cover! <subject of
the series>" and continue with the cover letter. It's essentially the same
as the fixup! and squash! idea (more the latter - it's squash! without a
predecessor). For moderate size series a simple 'git rebase master..' is
sufficient to see the whole series and decide which need editing, rewording,
swapping, checking the fixups, etc.
Format-patch would then be taught to spot that the first commit in the
series is "cover! <subject>" and create the usual 0/N cover letter. Git Gui
may need to be taught to recognise cover! (haven't checked if it recognises
an empty commit squash!). Possibly 'git commit' may want a --cover option to
massage the commit message and add --allow-empty, but that's finesse.
I've no problem with more extensive methods for those preparing very big
patch series, or with those needing to merge together a lot of series and
want to keep the cover letters, but ensuring that a simple flow is possible
should still be there.
--
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html