Re: [PATCH v5 1/8] technical doc: add a design doc for the evolve command

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> 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@xxxxxxxxx> wrote:
>
> sxenos@xxxxxxxxxx writes:
>
> > From: Stefan Xenos <sxenos@xxxxxxxxxx>
> >
> > 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@xxxxxxxxxx>
> > ---
>
> 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.
>



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux