Re: [PATCH v6 04/15] sequencer: introduce new commands to reset the revision

Hi Johannes,

Johannes Schindelin [off-list ref] writes:

Hi Sergey,

On Wed, 11 Apr 2018, Sergey Organov wrote:

quoted

Johannes Schindelin [off-list ref] writes:

[...]

quoted

We disallow '#' as label because that character will be used as
separator in the upcoming `merge` command.

Please consider to use # not only in `merge` and `reset`, but in the
rest of the commands as well, to unify this new syntax. I.e., right now
it seems to be:

pick  abcd A commit message
merge beaf # B commit message

I suggest to turn it to:

pick  abcd # A commit message
merge beaf # B commit message

First of all, that alignment of pick's and merge's first arguments?

As if it has anything to do with the topic of the issue!

Just a nice look. Let it be:

pick abcd # A commit message
merge beaf # B commit message

if it's that essential indeed.

That does not exist. If you want aligned arguments, you have to use the
rebase.abbreviateCommands feature.

It's changing the subject.

Second: this change would break backwards-compatibility. For almost eleven
years, we generated `pick abcdef0123 A commit message`.

I thought we already agreed that you have no backward compatibility
issues with this new feature, as it's a new feature, complete re-design,
as you put it yourself:

"This design flaw cannot be fixed. Not without a complete re-design, at
least. This patch series offers such a re-design."

At least could you please answer plain yes/no to this simple question: is
this feature a complete re-design or not? yes/no, please!

Even if there are no scripts that rely on this form, power users have
gotten used to it, and I can tell you from experience how unsettling
even minor visual changes are in everyday operations.
In short: no, we cannot do that.

You can do that, provided it's complete re-design indeed. You don't wish
to, but you can. Nothing will break and things will be at least a little
bit cleaner.

Each directive having its own dedicated syntax... gosh! No luck getting
syntax description, I'm afraid.

Just like your proposal to conflate the `merge` and `pick` commands

There was never such proposal. The proposal was not to introduce new
`merge` command when there is already `pick` that could simply be
extended to pick any commit, whatever number of parents it happens to
have.

But provided you decline to even put a # before the commit message...
that proposal is simply a pie in the sky.

for some perception of consistency: The user experience is more
important than individual persons' sense of elegance (that might not
even be shared with the majority).

It's about consistency indeed. Consistent handling of commits is
essential. Consistency is one of the things that bring positive user
experience. You disagree?

Besides, it was bad user experience that forced you to re-design, isn't
it? I'm afraid you miss good opportunity to fix some of your former
mistakes and you make some new. As the discussion goes, it seems you'd
never admit it, the design is set in stone, and my attempts are in fact
pointless.

Overall, I hereby withdraw all my pending suggestions to improve this
patch series.

-- Sergey