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

Stefan Beller <> writes:

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

Absolutely.  I did not say that there needs a mode to ignore log

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

Sign-off is inherent to the project, in the sense that we want to
see how the change flowed recorded in the commits.

With a pull-request based workflow, until Git is somehow improved so
that a "pull" becomes "fetch and rebase what got fetched on top of
my stuff, and add my sign-off while at it" (which is the opposite of
the usual "pull --rebase"), we would lose the ability to fully "use"
Git to run this project, as we would lose most sign-offs, unlike the
e-mail based workflow, which we can use Git fully to have it do its
job of recording necessary information.

And much more importantly, when "pull-request" based workflow is
improved enough so that your original without my sign-off (and you
shouldn't, unless you are relaying my changes) becomes what I
pulled, which does have my sign-off, range-diff that compares both
histories does need to deal with a pair of commits with only one
side having a sign-off.  So switching the tool is not a proper
solution to work around the "sign-off noise" we observed.  One side
having a sign-off while the other side does not is inherent to what
we actively want, and you are letting your tail wag your dog by
suggesting to discard it, which is disappointing.

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

As I most often edit the log message and material below three-dash
lines (long) _after_ format-patch produced files, I do not think it
is a win to force me to push and ask to pull.

> (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?

That indicates the same direction as I alluded to in the message you
are responding to, I guess, which is a good thing.

  parent 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
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 [this message]
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 \ \ \ \ \ \ \

* 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