On Sun, Aug 14, 2016 at 12:15 AM, Jacob Keller <jacob.kel...@gmail.com> wrote:
> On Sat, Aug 13, 2016 at 1:49 AM, Duy Nguyen <pclo...@gmail.com> wrote:
>> On Tue, Aug 9, 2016 at 12:27 AM, Stefan Beller <sbel...@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?

5) create a branch for them? (such as $(date)-${subject})

My gut reaction doesn't like 5 either.

>> --
>> Duy
> Also, what about the case where a branch already has a description
> such as is the case for something other than an integration branch.
> How does git-am know the difference and ensure it doesn't overwrite
> anything? Not everyone uses separate branches for each patch and such.

I would imagine this is similar to the pull requests on the linux
mailing list, i.e.
how it is with merges. Back in the time we did not open the editor for you to
talk about the merge you just did, and then we started doing that.

So what to do when the description already exists?

We could amend the description separated by a

     # comment, below was added:

line or such and then open the editor asked for user input.


> Thanks,
> Jake
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to