Re: "breaking" command output message parsing (was: [RFC PATCH] vreportf: ensure sensible ordering of normal and error output)

> On Tue, Nov 30 2021, Eric Sunshine wrote:
> > On Tue, Nov 30, 2021 at 9:05 AM Eric Sunshine <sunshine@sunshineco.com> wrote:
> >> (2) With git-worktree being four or five years old, for
> >> backward-compatibility concerns, I worry that "that ship has sailed",
> >> where 'that' is the freedom to relocate those status-like messages
> >> from stdout to stderr. I don't want to break tooling which exists
> >> around git-worktree.
> >>
> >> I'd be happy to be wrong on the second point -- indeed, git-worktree
> >> is still marked "experimental" in the man-page, but that may not mean
> >> anything this late in the game -- and submit a patch which places
> >> git-worktree's status-like messages on stderr instead of stdout.
> >> Thoughts?
> >
> > If that ship has indeed sailed, then perhaps the best and safest thing
> > to do is admit that git-worktree is an outlier in terms of sending
> > status-like messages to stdout, and just sprinkle the necessary
> > fflush(stdout) around in builtin/worktree.c and live with that
> > localized ugliness. Thoughts?
>
> I really don't think that ship has sailed at all. We're at full liberty
> to change these error messages, and have even done so for some plumbing
> in the past (being sensitive to what sort of messages, sometimes they
> are important).

> From some brief skimming of the worktree.c code that doesn't seem to
> apply, i.e. it's just chattyness.
>
> I doubt anyone cares if it's blathering about "preparing a worktree" or
> whatever, it just matters if "git worktree add" and the like fail with
> non-zero, but perhaps there's cases of conflated states, as in that case
> of "git remote" and "git pull".