Re: [RFC] cover-at-tip
- Date: Fri, 10 Nov 2017 16:37:49 +0100
- From: Nicolas Morey-Chaisemartin <NMoreyChaisemartin@xxxxxxx>
- Subject: Re: [RFC] cover-at-tip
Le 10/11/2017 à 11:24, Nicolas Morey-Chaisemartin a écrit :
> I'm starting to look into the cover-at-tip topic that I found in the leftover bits (http://www.spinics.net/lists/git/msg259573.html)
> Here's a first draft of a patch that adds support for format-patch --cover-at-tip. It compiles and works in my nice and user firnedly test case.
> Just wanted to make sure I was going roughly in the right direction here.
> I was wondering where is the right place to put a commit_is_cover_at_tip() as the test will be needed in other place as the feature is extended to git am/merge/pull.
> Feel free to comment. I know the help is not clear at this point and there's still some work to do on option handling (add a config option, probably have --cover-at-tip imply --cover-letter, etc) and
> some testing :)
Leaving some more updates and questions before the week end:
I started on git am --cover-at-tip.
The proposed patch for format-patch does not output any "---" to signal the end of the commit log and the begining of the patch in the cover letter.
This means that the log summary, the diffstat and the git footer ( --\n<git version>) is seen as part of the commit log. Which is just wrong.
Removing them would solve the issue but I feel they bring some useful info (or they would not be here).
Adding a "---" between the commit log and those added infos poses another problem: git am does not see an empty patch anymore.
I would need to add "some" level of parsing to am.c to make sure the patch content is just garbage and that there are no actual hunks for that.
I did not find any public API that would allow me to do that, although apply_path/parse_chunk would fit the bill.
Is that the right way to approach this ?
My branch is here if anyone want to give a look: https://github.com/nmorey/git/tree/dev/cover-at-tip