git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Xenos <sxenos@google.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org, "Stefan Beller" <sbeller@google.com>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Jonathan Tan" <jonathantanmy@google.com>,
	"Derrick Stolee" <stolee@gmail.com>,
	"Carl Baldwin" <carl@ecbaldwin.net>,
	"Dave Borowitz" <dborowitz@google.com>
Subject: Re: [PATCH] technical doc: add a design doc for the evolve command
Date: Wed, 21 Nov 2018 11:10:10 -0800	[thread overview]
Message-ID: <CAPL8ZitRThJmqyvvf7-Cw=aSmPMcpqr8wvFVeJ3tfGY5feFH9g@mail.gmail.com> (raw)
In-Reply-To: <20181121013326.GF149929@google.com>

>   I don't have a strong opinion about whether this would go in the
> design doc.  I suppose the doc could have an "implementation plan"
> section describing temporary stopping points on the way to the final
> result, but it's not necessary to include that.

As long as this is something I'm just doing for fun and nobody needs
to coordinate anything with me, I was planning to just document the
endpoint and then work on whatever seems interesting at any given
moment. Of course, if I found a job/team that would let me do this as
my day job, I'd be more willing to commit to deliverables.

  - Stefan
On Tue, Nov 20, 2018 at 5:33 PM Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> Stefan Xenos wrote:
> > Jonathan Nieder wrote:
>
> >> putting it in the commit message is a way to
> >> experiment with the workflow without changing the object format
> >
> > As long as we're talking about a temporary state of affairs for users
> > that have opted in, and we're explicit about the fact that future
> > versions of git won't understand the change graphs that are produced
> > during that temporary state of affairs, I'm fine with using the commit
> > message. We can move it to the header prior to enabling the feature by
> > default.
>
> Yay!  I think that addresses both my and Ævar's concerns.  Also, if
> you run into an issue that requires changing the object format
> earlier, that's fine and we can handle the situation when it comes.
>
> I don't have a strong opinion about whether this would go in the
> design doc.  I suppose the doc could have an "implementation plan"
> section describing temporary stopping points on the way to the final
> result, but it's not necessary to include that.
>
> Thanks for the quick and thoughtful replies.
>
> Jonathan

  reply	other threads:[~2018-11-21 19:10 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-15  0:55 [PATCH] technical doc: add a design doc for the evolve command sxenos
2018-11-15 12:52 ` Johannes Schindelin
2018-11-17 20:30   ` Stefan Xenos
2018-11-19 15:55     ` SZEDER Gábor
2018-11-19 21:32       ` Stefan Xenos
2018-11-20  1:09         ` Jonathan Nieder
2018-11-15 15:36 ` Ævar Arnfjörð Bjarmason
2018-11-20  1:18   ` Jonathan Nieder
2018-11-20  9:43     ` Ævar Arnfjörð Bjarmason
2018-11-20 17:45       ` Stefan Xenos
2018-11-20 22:06         ` Jonathan Nieder
2018-11-20 23:45           ` Stefan Xenos
2018-11-21  1:33             ` Jonathan Nieder
2018-11-21 19:10               ` Stefan Xenos [this message]
2018-11-16 21:36 ` Derrick Stolee
2018-11-17 23:44   ` Stefan Xenos
2018-11-17  6:06 ` Duy Nguyen
2018-11-18 22:27   ` Stefan Xenos
2018-11-18 22:29     ` Stefan Xenos
2018-11-18 23:20     ` Junio C Hamano
2018-11-17  7:36 ` Junio C Hamano
2018-11-19  0:36   ` Stefan Xenos
2018-11-19  2:15     ` Junio C Hamano
2018-11-19  3:33       ` Stefan Xenos
2018-11-19  3:45         ` Junio C Hamano
2018-11-19  4:15         ` Junio C Hamano
2018-11-19 20:14           ` Stefan Xenos
2018-11-19 20:26             ` Jonathan Nieder
2018-11-20  1:03             ` Junio C Hamano
2018-11-20 17:27               ` Stefan Xenos
2018-11-20 12:18 ` Phillip Wood
2018-11-20 12:59   ` Phillip Wood
2018-11-20 20:19   ` Stefan Xenos
2019-01-15 11:16     ` Phillip Wood
2018-11-20 13:03 ` Phillip Wood
2018-11-20 20:24   ` Stefan Xenos
2018-11-21 12:14     ` Phillip Wood

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

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

  git send-email \
    --in-reply-to='CAPL8ZitRThJmqyvvf7-Cw=aSmPMcpqr8wvFVeJ3tfGY5feFH9g@mail.gmail.com' \
    --to=sxenos@google.com \
    --cc=avarab@gmail.com \
    --cc=carl@ecbaldwin.net \
    --cc=dborowitz@google.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jonathantanmy@google.com \
    --cc=jrnieder@gmail.com \
    --cc=sbeller@google.com \
    --cc=stolee@gmail.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.
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 NNTP newsgroup(s).