All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Stefan Xenos <sxenos@google.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: Tue, 20 Nov 2018 14:06:26 -0800	[thread overview]
Message-ID: <20181120220626.GB149929@google.com> (raw)
In-Reply-To: <CAPL8Zis6Jz3=Jb0JxuSyHczYQrrrqP3JGiov1ZuH2A_0x=dpVQ@mail.gmail.com>

Stefan Xenos wrote:
> On Tue, Nov 20, 2018 at 1:43 AM Ævar Arnfjörð Bjarmason
> <avarab@gmail.com> wrote:

>> I think it sounds better to just make it, in the header:
>>
>>     x-evolve-pt content
>>     x-evolve-pt obsolete
>>     x-evolve-pt origin
>>
>> Where "pt = parent-type", we could of course spell that out too, but in
>> this case it's "x-evolve-pt" is the exact same number of bytes as
>> "parent-type", so nobody can object that it takes more space:)
>>
>> We'd then carry some documentation where we say everything except "x-*-"
>> is reserved, and that we'd like to know about new "*" there before it's
>> used, so it can be documented.
[...]
>                                                      that should
> probably be the subject of a separate proposal (who owns the content
> of a namespace, what is the process for adding a new namespace or a
> new attribute within a namespace, what order should the header
> attributes appear in, what problem is namespacing there to solve, when
> do we use a namespaced attribute versus a "reserved" attribute, etc.).

Agreed.  There are reasons that I prefer not to go in this direction,
but regardless, it would be the subject of a separate thread if you want
to pursue it.

>> Putting it in the commit message just sounds like a hack around not
>> having namespaced headers. If we'd like to keep this then tools would
>> need to parse both (potentially unpacking a lot of the commit message
>> object, it can be quite big in some cases...).

On the contrary: putting it in the commit message is a way to
experiment with the workflow without changing the object format at
all.

I don't think we should underestimate the value of that ability.

I don't understand what you're referring to by parsing both.  Are you
saying that if the experiment proves successful, we wouldn't be able
to migrate completely to a new format?  That sounds worrying to me ---
I want the ability to experiment and to act on what we learn from an
experiment, including when it touches on formats.

Thanks,
Jonathan

  reply	other threads:[~2018-11-20 22:06 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 [this message]
2018-11-20 23:45           ` Stefan Xenos
2018-11-21  1:33             ` Jonathan Nieder
2018-11-21 19:10               ` Stefan Xenos
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=20181120220626.GB149929@google.com \
    --to=jrnieder@gmail.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=sbeller@google.com \
    --cc=stolee@gmail.com \
    --cc=sxenos@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.