list mirror (unofficial, one of many)
 help / color / Atom feed
From: Stefan Beller <>
To: Junio C Hamano <>,
	Eric Sunshine <>,
	Johannes Schindelin <>
Cc: git <>
Subject: Re: [PATCH v2 0/6] convert part of cmd_update to C
Date: Tue, 17 Jul 2018 11:53:29 -0700
Message-ID: <> (raw)
In-Reply-To: <>

> 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.

> >>
> >>
> >> 1:  d4e1ec45740 ! 1:  bbc8697a8ca 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 <>
> >>     -    Signed-off-by: Junio C Hamano <>
> >>
> >>      diff --git a/ b/
> >>      --- a/
> 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?


  reply index

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-17  0:26 Stefan Beller
2018-07-17  0:26 ` [PATCH v2 1/6] align error reporting for update mode to use path Stefan Beller
2018-07-17  0:26 ` [PATCH v2 2/6] rename unused variables Stefan Beller
2018-07-17  0:26 ` [PATCH v2 3/6] builtin/submodule--helper: factor out submodule updating Stefan Beller
2018-07-17  0:26 ` [PATCH v2 4/6] builtin/submodule--helper: store update_clone information in a struct Stefan Beller
2018-07-17  0:26 ` [PATCH v2 5/6] builtin/submodule--helper: factor out method to update a single submodule Stefan Beller
2018-07-17  0:26 ` [PATCH v2 6/6] submodule--helper: introduce new update-module-mode helper Stefan Beller
2018-07-17  7:59   ` SZEDER Gábor
2018-07-17 21:44     ` Junio C Hamano
2018-07-17 18:39 ` [PATCH v2 0/6] convert part of cmd_update to C Junio C Hamano
2018-07-17 18:53   ` Stefan Beller [this message]
2018-07-17 18:59     ` Eric Sunshine
2018-07-18 19:34       ` Stefan Beller
2018-07-18 19:55         ` Eric Sunshine
2018-07-18 21:57           ` Junio C Hamano
2018-07-17 19:51     ` Junio C Hamano
2018-07-17 20:56       ` Stefan Beller
2018-07-17 21:39         ` Junio C Hamano
2018-07-26 10:47     ` Johannes Schindelin
2018-07-26 18:14       ` Stefan Beller

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:
       or Tor2web:

AGPL code for this site: git clone public-inbox