git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	Elijah Newren <newren@gmail.com>,
	Christian Couder <christian.couder@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Christian Couder <chriscool@tuxfamily.org>,
	Taylor Blau <me@ttaylorr.com>
Subject: Re: [RFC PATCH 0/2] Introduce new merge-tree-ort command
Date: Tue, 11 Jan 2022 18:00:51 +0100	[thread overview]
Message-ID: <220111.86mtk2xb1y.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <nycvar.QRO.7.76.6.2201111439190.1081@tvgsbejvaqbjf.bet>


On Tue, Jan 11 2022, Johannes Schindelin wrote:

> Hi Junio,
>
> On Mon, 10 Jan 2022, Junio C Hamano wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>> > I am against a new command for what essentially serves the original
>> > purpose of `merge-tree`.
>> >
>> > The fact that `merge-tree` has not seen any work in almost 12 years is
>> > testament not only to how hard it was to disentangle the work-tree
>> > requirement from the recursive merge (it is one of my favorite
>> > counterexamples when anybody claims that you can easily prototype code in
>> > a script and then convert it to C), but the fact that there is no user
>> > within Git itself (apart from t/t4300-merge-tree.sh, which does not count)
>> > speaks volumes about the design of that `merge-tree` tool.
>> >
>> > So it's only fair to breathe life into it by letting it do what it was
>> > meant to do all along.
>>
>> My "Yup" would not weigh as much as one that Linus (whose original
>> merge-tree survived this long without seeing much enhancements)
>> might give us, but he is busy elsewhere so you guys have to live
>> with mine ;-)
>>
>> As to its output, I do agree that "we give a tree when it is already
>> usable to record in a new commit" is a valuable option to have.  The
>> original behaviour should be made available somehow, for those who
>> built their workflow (including scripts) around it, though.
>
> No, I don't think it is a good idea to keep the original behavior around
> indefinitely, when it is totally unclear whether there actually _is_ any
> user of this feature out there.

For what it's worth I've used it for some automation at an ex-employer
at least once. Grepping through my #*git* IRC logs there's a few
mentions of it, and likewise for StackOverflow.

I'm not opposed to replacing it, and I think that probably in-the-wild
users of it are almost certainly just grepping for the conflict markers
to see if there's conflicts, or parsing which files have them etc.

So if we can provide a better interface that they can use (or even make
git merge-tree a thin wrapper...).

> We intentionally broke any existing users of `git-parse-remote.sh` by
> removing it, when that feature was much more likely to be used in scripts
> than `git merge-tree`. We cannot say on the one hand that we will get rid
> of some useful script just because we don't want the maintenance burden
> when on the other hand trying to keep support for an operation that is
> unlikely to have any users. That does not compute.  (And don't get hung up
> on the specific example of `git-parse-remote.sh`[...]

The specific example or case really matters. We don't have some generic
flowchart for deprecating things that applies in all cases.

I removed git-parse-remote.sh in a89a2fbfccd (parse-remote: remove this
now-unused library, 2020-11-14) and had the opposite impression you're
expressing here.

I.e. searching around for in-the-wild uses via search engines, stack
overflow etc. either found nothing interesting, or just a reflection of
ourselves (i.e. generated manpages etc.).

That along with its history, i.e. it wasn't *really* meant for
out-of-tree exposure if you look at the history of how it came about, it
was just made at a time when similar libraries had similar manpages
etc. added as a template.

Maybe that was the right thing to do, maybe not, but it went out with
v2.30.0 and the lack of complaints since then would seem to suggest that
I was right that removing it wouldn't be a big deal.

Of course it may have broken someone's script somewhere.

But an important distinction is that they can get it working again by
just copy/pasting that ~100 line shell library into their own script, or
calling the underlying commands it was invoking themselves.

Which doesn't apply to "git merge-tree" unless we come up with a
replacement, and even then a 1=1 port of some in-the-wild code might be
much harder, i.e. if it's deeply coupled to parsing the specific output
it emits now.

So I'd personally be much more hesitant to remove or change that, but of
course we might still come up with good reasons for why it's worth it,
especially with some advertised deprecation period.

And isn't any doubt around that even more reason to just go with
Elijah's plan of introducing new plumbing? I.e. is it really costing us
to just leave these "legacy merge" plumbing built-ins and
merge-recursive.c etc. in place?

  reply	other threads:[~2022-01-11 20:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-05 16:33 [RFC PATCH 0/2] Introduce new merge-tree-ort command Christian Couder
2022-01-05 16:33 ` [RFC PATCH 1/2] merge-ort: add " Christian Couder
2022-01-05 17:08   ` Elijah Newren
2022-01-05 16:33 ` [RFC PATCH 2/2] merge-ort: add t/t4310-merge-tree-ort.sh Christian Couder
2022-01-05 17:29   ` Elijah Newren
2022-01-05 16:53 ` [RFC PATCH 0/2] Introduce new merge-tree-ort command Elijah Newren
2022-01-05 17:32   ` Elijah Newren
2022-01-07 17:58   ` Christian Couder
2022-01-07 19:06     ` Elijah Newren
2022-01-10 13:49       ` Johannes Schindelin
2022-01-10 17:56         ` Junio C Hamano
2022-01-11 13:47           ` Johannes Schindelin
2022-01-11 17:00             ` Ævar Arnfjörð Bjarmason [this message]
2022-01-11 22:25               ` Elijah Newren
2022-01-12 18:06                 ` Junio C Hamano
2022-01-12 20:06                   ` Elijah Newren
2022-01-13  6:08                     ` Junio C Hamano
2022-01-13  8:01                       ` Elijah Newren
2022-01-13  9:26                     ` Ævar Arnfjörð Bjarmason
2022-01-12 17:54               ` Junio C Hamano
2022-01-13  9:22                 ` Ævar Arnfjörð Bjarmason
2022-01-10 17:59         ` Elijah Newren
2022-01-11 21:15           ` Elijah Newren
2022-02-22 13:08             ` Johannes Schindelin
2022-01-11 22:30           ` Johannes Schindelin
2022-01-12  0:41             ` Elijah Newren
2022-02-22 12:44               ` Johannes Schindelin
2022-01-07 19:54     ` Johannes Schindelin

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=220111.86mtk2xb1y.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=chriscool@tuxfamily.org \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=newren@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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).