All of lore.kernel.org
 help / color / mirror / Atom feed
From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: "Martin Ågren" <martin.agren@gmail.com>,
	"Git Mailing List" <git@vger.kernel.org>,
	"Jeff King" <peff@peff.net>,
	"Derrick Stolee" <dstolee@microsoft.com>,
	"Junio C Hamano" <gitster@pobox.com>
Subject: Re: [PATCH 2/3] builtin/commit-graph.c: introduce '--input=<source>'
Date: Thu, 13 Feb 2020 12:48:00 +0100	[thread overview]
Message-ID: <20200213114800.GP10482@szeder.dev> (raw)
In-Reply-To: <20200213113313.GO10482@szeder.dev>

On Thu, Feb 13, 2020 at 12:33:13PM +0100, SZEDER Gábor wrote:
> On Mon, Feb 03, 2020 at 08:51:24PM -0800, Taylor Blau wrote:
> > On Fri, Jan 31, 2020 at 08:34:41PM +0100, Martin Ågren wrote:
> > > On Fri, 31 Jan 2020 at 01:30, Taylor Blau <me@ttaylorr.com> wrote:
> > > > The 'write' mode of the 'commit-graph' supports input from a number of
> 
> s/mode/subcommand/
> 
> > > > different sources:
> 
> I note that you use the word "sources" here, in the subject line as
> well (as '--input=<source>'), and in the code as well (e.g.  the in
> the error message "unrecognized --input source, %s").  I like this
> word, I think the words "input" and "source" go really well together.
> 
> > > > pack indexes over stdin, commits over stdin, commits
> > > > reachable from all references, and so on.
> 
> It's interesting to see that you stopped listing and went for "and so
> on" right when it got interesting/controversial with '--append'... :)
> 
> > > > Each of these options are
> > > > specified with a unique option: '--stdin-packs', '--stdin-commits', etc.
> 
> It also supports the very inefficient scanning through all objects in
> all pack files to find commit objects, which, sadly, ended up being
> the default, and thus doesn't have its own --option.  Should there be
> a corresponding '--input=<source>' as well?  (Note that I don't mean
> this as a suggestion to add one; on the contrary, the less exposure it
> gets the better.)
> 
> > > > Similar to our replacement of 'git config [--<type>]' with 'git config
> > > > [--type=<type>]' (c.f., fb0dc3bac1 (builtin/config.c: support
> > > > `--type=<type>` as preferred alias for `--<type>`, 2018-04-18)), softly
> > > > deprecate '[--<input>]' in favor of '[--input=<source>]'.
> > > >
> > > > This makes it more clear to implement new options that are combinations
> > > > of other options (such as, for example, "none", a combination of the old
> > > > "--append" and a new sentinel to specify to _not_ look in other packs,
> > > > which we will implement in a future patch).
> > >
> > > Makes sense.
> > >
> > > > Unfortunately, the new enumerated type is a bitfield, even though it
> > > > makes much more sense as '0, 1, 2, ...'. Even though *almost* all
> > > > options are pairwise exclusive, '--stdin-{packs,commits}' *is*
> > > > compatible with '--append'. For this reason, use a bitfield.
> > >
> > > > -With the `--append` option, include all commits that are present in the
> > > > -existing commit-graph file.
> > > > +With the `--input=append` option, include all commits that are present
> > > > +in the existing commit-graph file.
> > >
> > > Would it be too crazy to call this `--input=existing` instead, and have
> > > it be the same as `--append`? I find that `--append` makes a lot of
> > > sense (it's a mode we can turn on or off), whereas "input = append"
> > > seems more odd.
> > 
> > Hmm. When I wrote this, I was thinking of introducing equivalent options
> > that are identical in name and functionality as '--input=<mode>' instead
> > of '--<mode>'. So, I guess that is to say that I didn't spend an awful
> > amount of time thinking about whether or not '--input=append' made sense
> > given anything else.
> > 
> > So, I don't think that '--input=existing' is a bad idea at all, but I do
> > worry about advertising this deprecation as "'--<mode>' becomes
> > '--input=<mode>', except when your mode is 'append', in which case it
> > becomes '--input=existing'".
> 
> But here you suddenly start using the word "mode" both in
> '--input=<mode>' and in '--<mode>'.
> 
> On one hand, I don't think that the word "mode" goes as well with
> "input" as "source" does.
> 
> On the other, is '--append' really a source/mode, like '--reachable'
> and '--stdin-commits' are?

Well, re-reading this question got me confused right after sending it,
so let me try to rephrase.

Is '--append' really a "source", like '--reachable' and
'--stdin-commits' are?  No:

>  Source, no: from wordsmithing perspective
> it doesn't fit with "source", and being orthogonal to the "real"
> source options while they are mutually exclusive seems to be a clear
> indication that it isn't.

Or is it a "mode" modifying how other options are handled?  Yes:

> Mode, yes: it's a mode of operation where
> no longer reachable/present commits are not discarded from the
> commit-graph.
> 
> So I don't think that adding '--input=append' is a good idea, even if
> we were call it differently, e.g. '--input=existing' as suggested
> above.
> 
> However, I do think that '--input=existing' would better express what
> '--input=none' in the next patch wants to achieve.
> 

  reply	other threads:[~2020-02-13 11:48 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31  0:28 [PATCH 0/3] builtin/commit-graph.c: new split/merge options Taylor Blau
2020-01-31  0:28 ` [PATCH 1/3] builtin/commit-graph.c: support '--split[=<strategy>]' Taylor Blau
2020-01-31 14:19   ` Derrick Stolee
2020-02-04  3:47     ` Taylor Blau
2020-01-31 19:27   ` Martin Ågren
2020-02-04  4:06     ` Taylor Blau
2020-02-06 19:15       ` Martin Ågren
2020-02-09 23:27         ` Taylor Blau
2020-01-31 23:34   ` SZEDER Gábor
2020-02-01 21:25     ` Johannes Schindelin
2020-02-03 10:47       ` SZEDER Gábor
2020-02-03 11:11         ` Jeff King
2020-02-04  3:58           ` Taylor Blau
2020-02-04 14:14             ` Jeff King
2020-02-04  3:59       ` Taylor Blau
2020-02-04  3:59     ` Taylor Blau
2020-01-31  0:28 ` [PATCH 2/3] builtin/commit-graph.c: introduce '--input=<source>' Taylor Blau
2020-01-31 14:40   ` Derrick Stolee
2020-02-04  4:21     ` Taylor Blau
2020-01-31 19:34   ` Martin Ågren
2020-02-04  4:51     ` Taylor Blau
2020-02-13 11:33       ` SZEDER Gábor
2020-02-13 11:48         ` SZEDER Gábor [this message]
2020-02-13 17:56           ` Taylor Blau
2020-01-31  0:28 ` [PATCH 3/3] builtin/commit-graph.c: support '--input=none' Taylor Blau
2020-01-31 14:40   ` Derrick Stolee
2020-01-31 19:45   ` Martin Ågren
2020-02-04  5:01     ` Taylor Blau
2020-01-31  0:32 ` [PATCH 0/3] builtin/commit-graph.c: new split/merge options Taylor Blau
2020-01-31 13:26   ` Derrick Stolee
2020-01-31 14:41 ` Derrick Stolee
2020-02-04 23:44 ` Junio C Hamano
2020-02-05  0:30   ` Taylor Blau
2020-02-05  0:28 ` [PATCH v2 " Taylor Blau
2020-02-05  0:28   ` [PATCH v2 1/3] builtin/commit-graph.c: support '--split[=<strategy>]' Taylor Blau
2020-02-06 19:41     ` Martin Ågren
2020-02-07 15:48       ` Derrick Stolee
2020-02-09 23:32         ` Taylor Blau
2020-02-12  6:03         ` Martin Ågren
2020-02-12 20:50           ` Taylor Blau
2020-02-09 23:30       ` Taylor Blau
2020-02-05  0:28   ` [PATCH v2 2/3] builtin/commit-graph.c: introduce '--input=<source>' Taylor Blau
2020-02-05  0:28   ` [PATCH v2 3/3] builtin/commit-graph.c: support '--input=none' Taylor Blau
2020-02-06 19:50     ` Martin Ågren
2020-02-09 23:32       ` Taylor Blau
2020-02-05 20:07   ` [PATCH v2 0/3] builtin/commit-graph.c: new split/merge options Junio C Hamano
2020-02-12  5:47 ` [PATCH v3 " Taylor Blau
2020-02-12  5:47   ` [PATCH v3 1/3] builtin/commit-graph.c: support '--split[=<strategy>]' Taylor Blau
2020-02-12  5:47   ` [PATCH v3 2/3] builtin/commit-graph.c: introduce '--input=<source>' Taylor Blau
2020-02-12  5:47   ` [PATCH v3 3/3] builtin/commit-graph.c: support '--input=none' Taylor Blau
2020-02-13 11:39     ` SZEDER Gábor
2020-02-13 12:31     ` SZEDER Gábor
2020-02-13 16:08       ` Junio C Hamano
2020-02-13 17:58         ` Taylor Blau
2020-02-13 17:56       ` Taylor Blau
2020-02-12 18:19   ` [PATCH v3 0/3] builtin/commit-graph.c: new split/merge options Junio C Hamano
2020-02-13 17:41     ` Taylor Blau
2020-02-17 18:24   ` Martin Ågren

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=20200213114800.GP10482@szeder.dev \
    --to=szeder.dev@gmail.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=martin.agren@gmail.com \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    /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.