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.
