git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Stefan Xenos <sxenos@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git <git@vger.kernel.org>
Subject: Re: [PATCH v5 1/8] technical doc: add a design doc for the evolve command
Date: Fri, 15 Feb 2019 14:18:49 -0800	[thread overview]
Message-ID: <CAPL8ZiseLQgemzr-U2yFM815Ty+Di_cGznZ_hNAcf3sMy5mXEg@mail.gmail.com> (raw)
In-Reply-To: <xmqqlg2g6hcv.fsf@gitster-ct.c.googlers.com>

> It would really need a summary of what changed

Sure! In this iteration, I made some minor changes to the technical doc:

- Fixed a number of typos and inconsistent language.
- Removed the "replace" subcommand from the "changes" command since
the "update" command is sufficient for this purpose.
- Removed the "--continue" and "--abort" arguments from "evolve" since
I don't need them to address the initial use-cases and jrn@ proposed
some reasonable alternatives that may render them redundant. I'll put
them back in a follow-up in the event that we go this route.
- Added some clarifying text.
- Added a paragraph describing the possibility of cycles between
changes and how the evolve command will treat them.

I also changed the "git change update" subcommand to add output
describing which changes were modified by the operation. I did some
minor refactoring to collect that output.

In general, would you prefer if I keep submitting these as revisions
of the same patch series, or would it be easier if I created new
patches on top of what is currently in "pu"? Sorry, I'm new here and
am unfamiliar with the email workflow -- but I'm happy to accommodate
whatever you prefer.

> saw a few comments that say "needs further work".

Could you clarify where you saw those comments? Were they something I
wrote or did I miss a comment on this mailing list asking me to do
follow-up work that I neglected? To the best of my knowledge, I've
addressed every concern anyone brought up in the list.

> What's the intention?  Unfinished but soliciting further comments and sanity checks to help polishing the finished parts

To the best of my knowledge, the patches in this series are ready for
submission. There is further work needed to implement the "evolve"
command itself (which I haven't started), but that will build on top
of this code. I am not aware of further refinement required for these
patches. In earlier patch series I commented about the desire to make
better use of the memory pool, but I've also included those
refinements in later versions of the patch series. Does that answer
your question?

>  thanks for working on this.

And thank you for taking the time to review it and consider its inclusion!

  - Stefan


On Fri, Feb 15, 2019 at 10:23 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> sxenos@google.com writes:
>
> > From: Stefan Xenos <sxenos@google.com>
> >
> > This document describes what a change graph for
> > git would look like, the behavior of the evolve command,
> > and the changes planned for other commands.
> >
> > Signed-off-by: Stefan Xenos <sxenos@google.com>
> > ---
>
> It would really need a summary of what changed since the earlier
> rounds, if a series this size wants to be re-read by those who
> helped the previous one.
>
> I briefly looked at the patches (and the diff against the previous
> one that has been in 'pu') and saw a few comments that say "needs
> further work".  What's the intention?  Unfinished but soliciting
> further comments and sanity checks to help polishing the finished
> parts (if that is the case that is perfectly fine, but it would help
> those who want to help if you are clear about it)?
>
> I'll read them through laster today or tomorrow with fresh set of
> eyes; thanks for working on this.
>

  reply	other threads:[~2019-02-15 22:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-15  4:30 [PATCH v5 1/8] technical doc: add a design doc for the evolve command sxenos
2019-02-15  4:30 ` [PATCH v5 2/8] sha1-array: implement oid_array_readonly_contains sxenos
2019-02-15  4:31 ` [PATCH v5 3/8] ref-filter: add the metas namespace to ref-filter sxenos
2019-02-15  4:31 ` [PATCH v5 4/8] evolve: add support for parsing metacommits sxenos
2019-02-15  4:31 ` [PATCH v5 5/8] evolve: add the change-table structure sxenos
2019-02-15  4:31 ` [PATCH v5 6/8] evolve: add support for writing metacommits sxenos
2019-02-15  4:31 ` [PATCH v5 7/8] evolve: implement the git change command sxenos
2019-02-15  4:31 ` [PATCH v5 8/8] evolve: add the git change list command sxenos
2019-02-15 18:23 ` [PATCH v5 1/8] technical doc: add a design doc for the evolve command Junio C Hamano
2019-02-15 22:18   ` Stefan Xenos [this message]
2019-02-15 23:36     ` Junio C Hamano

Reply instructions:

You may reply publicly 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=CAPL8ZiseLQgemzr-U2yFM815Ty+Di_cGznZ_hNAcf3sMy5mXEg@mail.gmail.com \
    --to=sxenos@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).