> A tangent. > > Because this "-- " is a conventional signature separator, MUAs like > Emacs message-mode seems to omit everything below it from the quote > while responding, making it cumbersome to comment on the tbdiff. > > Something to think about if somebody is contemplating on adding more > to format-patch's cover letter. +cc Eric who needs to think about this tangent, then. https://public-inbox.org/git/20180530080325.37520-1-sunshine@xxxxxxxxxxxxxx/ > > >> 2.18.0.203.gfac676dfb9-goog > >> > >> 1: d4e1ec45740 ! 1: bbc8697a8ca git-submodule.sh: align error reporting for update mode to use path > >> @@ -6,7 +6,6 @@ > >> on its path, so let's do that for invalid update modes, too. > >> > >> Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx> > >> - Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> > >> > >> diff --git a/git-submodule.sh b/git-submodule.sh > >> --- a/git-submodule.sh > > This is quite unfortunate. I wonder if it is easy to tell > range-diff that certain differences in the log message are to be > ignored so that we can show that the first patch is unchanged in a > case like this. This series has 4 really changed ones with 2 > otherwise unchanged ones shown all as changed, which is not too bad, > but for a series like sb/diff-colro-move-more reroll that has 9 > patches, out of only two have real updated patches, showing > otherwise unchanged 7 as changed like this hunk does would make the > cover letter useless. It is a shame that adding range-diff to the > cover does have so much potential. Actually I thought it was really cool, i.e. when using your queued branch instead of my last sent branch, I can see any edits *you* did (including fixing up typos or applying at slightly different bases). The sign offs are a bit unfortunate as they are repetitive. I have two conflicting points of view on that: (A) This sign off is inherent to the workflow. So we could change the workflow, i.e. you pull series instead of applying them. I think this "more in git, less in email" workflow would find supporters, such as DScho (cc'd). The downside is that (1) you'd have to change your workflow, i.e. instead of applying the patches at the base you think is best for maintenance you'd have to tell the author "please rebase to $X"; but that also has upsides, such as "If you want to have your series integrated please merge with $Y and $Z" (looking at the object store stuff). The other (2) downside is that everyone else (authors, reviewers) have to adapt as well. For authors this might be easy to adapt (push instead of sending email sounds like a win). For reviewers we'd need to have an easy way to review things "stored in git" and not exposed via email, which is not obvious how to do. (B) The other point of view that I can offer is that we teach range-diff to ignore certain patterns. Maybe in combination with interpret-trailers this can be an easy configurable thing, or even a default to ignore all sign offs? Thanks, Stefan
