Re: git format-patch escaping issues in the patch format

[Christoph Anton Mitterer <calestyo@scientia.org>]

On Mon, 2024-11-04 at 23:15 +0100, Kristoffer Haugsbakk wrote:
> It seems to me (totally naïve) that you would do something like
> 
> 1. Blank line terminates headers
> 2. Then there might be some optional commit-headers which can
> override
>    things (`From`)
> 3. Commit message
> 4. `---`
> 5. Look for a regex `^diff` line
>    • Now the indentation will tell you when it ends
> 6. `^Range-diff` and `^Interdiff` can also make an appearance in this
>    section

Well as you've seen by the follow-up, such a naive approach is not
really possible, as the commit message may also contain ---, unified
diffs, etc.



> At first I thought that it is a magic string for a reason.

I think such magic cookies can always only (safely) be used to detect a
type, but not as a separator, at least not when free text is allowed,
too.


> It did the right thing for me with this (last part) of the commit
> message:
> 
>     We should look into Pedro’s backup system.  Why does he use
> email?
> 
>         diff --git a/a.txt b/a.txt
>         index ce01362503..a32119c8aa 100644
>         --- a/a.txt
>         +++ b/a.txt
>         @@ -1 +1,2 @@
>          hello
>         +goodbye
> 
> ***

But yours look indented? I mean then it's clear it works.


> It seems like it would be nice if format-patch complained if it found
> regex `^---$` in the commit body.

Actually already when committing... cause there it's taken as valid and
then it should also work with any following tools.


> The magic string is unlikely but could happen.  The solution is to
> use
> an indented block.  Same for the diff.  (Hopefully few have to
> code-quote diffs)

As written in the other mail, there is nothing real obvious for the
user that this wouldn’t be allowed, and in fact committing and such
works.
The simple problem here is the fuzzy format which cannot be parsed
properly.




> But escaping things in this format?

Coudln't one do something like this:

If the line consisting of three - is the line that ends the commit
message, check during format-patch whether it's contained in that.
If not, generate the patch as now.
If so, use another magic timestamp and/or (since that might get lost
when sending as mail, set some X-git-patch-format: header, there adding
perhaps a flag like "escaped" and if that's set, any line that matches
the regexp:
>*---
get's another > prepended when escaping, and one removed when
unescaping (well in the latter only lines that match >+---).
* = 0..n
+ = 1..n

Or probably thinking about some more sophisticated solution or at least
a better character than > .


> > btw and shamelessly off-topic question:
> > Any chance that git format-patch / am will ever support keeping
> > track
> > of the branch/merge history of generated / applied patches?
> > That would be really neat.
> 
> What does this mean more concretely?  :)

I guess I want what's been asked there:
https://stackoverflow.com/questions/2285699/git-how-to-create-patches-for-a-merge


In short, imagine I have the following commit tree (just a simple
example with --no-ff):
*
|\
|*
|/
*

And I make a series of git format-patch patches from that, it would be
nice if git am *.patches, give back that structure (i.e. with the
branch and the merge).


Cheers,
Chris.