git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 0/6] git-submodule.sh: convert part of cmd_update to C

From
Stefan Beller <sbeller@google.com>
Date
Jul 17, 2018, 20:56 UTC
Message-ID
<CAGZ79kbYtws-HhX_kQ5Gb4FeAfgRjbCfVbPS1Gcow4xfN-04XQ@mail.gmail.com>
In-Reply-To
<xmqqa7qpod29.fsf@gitster-ct.c.googlers.com>
On Tue, Jul 17, 2018 at 12:52 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 12 quoted lines
> > (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"),

and here is where our thoughts did not align. I imagined a git-pull as of today (fetch + merge), where you in the role of the maintainer tells me in the role of an author to base my series on top of $X, such that there is no need for rebase on your end, (you would also not sign off each commit, but only the resulting merge) Even merge conflicts could be handed off to the authors instead of burdening you.

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

I think all needed information would still be there, but there would be an actual change as authors would be committers (as they commit locally and we keep it all in Git to get it to you and you keep it in Git to put it into the blessed repository)

Show 7 quoted lines
> 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.

I do not view it as work around, but "another proper workflow that has advantages and disadvantages, one of the advantages is that it would enable us to work with this tool".

>  One side
> having a sign-off while the other side does not is inherent to what
> we actively want,
[in the current workflow that has proven good for 10 years]
> and you are letting your tail wag your dog by
> suggesting to discard it, which is disappointing.

I am suggesting to continue thinking about workflows in general, as there are many; all of them having advantages and disadvantages. I am not sure if workflows can be adapted easily via improving the current workflow continually or if sometimes a workflow has to be rethought to to changes in the landscape of available tools.

When the Git project started, an email based workflow was chosen, precisely because Git was not available.

Now that it has gained wide spread adoption (among its developers at least) the workflow could adapt to that.

Show 7 quoted lines
> > 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

Ah, that is an interesting workflow. Do you keep patch files/emails around locally, only to (long after) add a message and resend it? I try to keep any contribution of mine in Git as long as possible as that helps me tracking and fixing errors in my code and log messages.

Show 7 quoted lines
> > (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.

Yes, I imagined this is the approach we'll be taking. I think we would want to give %(trailers:none) or rather "ignore-sign-offs" to the inner diffs.

Thanks, Stefan

Previous: Junio C HamanoNext: Junio C Hamano
Message 17 of 20 in “git-submodule.sh: convert part of cmd_update to C”
  1. 0/6 git-submodule.sh: convert part of cmd_update to CStefan Beller, Jul 17, 2018
  2. 1/6 git-submodule.sh: align error reporting for update mode to use pathStefan Beller, Jul 17, 2018
  3. 2/6 git-submodule.sh: rename unused variablesStefan Beller, Jul 17, 2018
  4. 3/6 builtin/submodule--helper: factor out submodule updatingStefan Beller, Jul 17, 2018
  5. 4/6 builtin/submodule--helper: store update_clone information in a structStefan Beller, Jul 17, 2018
  6. 5/6 builtin/submodule--helper: factor out method to update a single submoduleStefan Beller, Jul 17, 2018
  7. 6/6 submodule--helper: introduce new update-module-mode helperStefan Beller, Jul 17, 2018
  8. SZEDER GáborJul 17, 2018
  9. Junio C HamanoJul 17, 2018
  10. Junio C HamanoJul 17, 2018
  11. Stefan BellerJul 17, 2018
  12. Eric SunshineJul 17, 2018
  13. Stefan BellerJul 18, 2018
  14. Eric SunshineJul 18, 2018
  15. Junio C HamanoJul 18, 2018
  16. Junio C HamanoJul 17, 2018
  17. Stefan BellerJul 17, 2018
  18. Junio C HamanoJul 17, 2018
  19. Johannes SchindelinJul 26, 2018
  20. Stefan BellerJul 26, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.