From: Junio C Hamano <gitster@pobox.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>,
Jakub Narebski <jnareb@gmail.com>,
Finn Arne Gangstad <finnag@pvv.org>,
"git\@vger.kernel.org List" <git@vger.kernel.org>
Subject: Re: [PATCH 5/6] rerere: let caller decide whether to renormalize
Date: Wed, 04 Aug 2010 11:12:31 -0700 [thread overview]
Message-ID: <7vocdifdrk.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: 20100804032338.GF19699@burratino
Jonathan Nieder <jrnieder@gmail.com> writes:
> NEEDSWORK: this is a step in the wrong direction. rerere needs
> an -s option to use an arbitrary merge strategy and a -X option to
> pass arbitrary options to that driver.
If you are talking about "rerere", I strongly disagree with that.
1. "-s"
A "merge strategy" deals with the shape of the history (e.g. common
ancestor selection or synthesis for the purpose of 3-way merge) and the
shape of the trees (e.g. rename detection, subtree shifting). Starting
from two commits, it decides, based on the shape of the history, what
three trees your tree-level 3-way merge would operate on, and then
based on the shape of the trees, decides the pairing of blobs to run
the 3-way merge at the file-content level.
When "rerere" is invoked, a strategy already has dealt with all of the
above, and "rerere" only works on the (half-completed) result of that.
It is purely a three-way merge at the file-contents level and there is
no room for a "strategy" to get involved. It makes direct calls to
ll_merge() exactly for this reason.
2. "-X"
In the "merge -X<opt>" syntax, "-X" does not stand for "low level
details"; it just means "eXternal callout". It is there just to tell
the "merge" front-end "You may not understand this yourself, but the
program you call does, so just pass it along".
IOW, we want to be able to pass --<opt> through the frontend to the
backend, without having to tell all the options any possible backends
may know to the frontend. Just to make it easier to parse and tell
which ones are the front-end options and which ones are not (for both
machines and humans), we say -X<opt> to the frontend. Then "merge"
turns that -X<opt> into "--<opt>" and give it to the strategy.
A command that natively knows about an option is correct to take an
option as "--<option>", e.g. "merge--recursive --renormalize". You
trigger it by saying "merge -Xrenormalize" from the frontend.
To recap: it is absolutely the right thing to do to introduce a new
"rerere --renormalize" option, like your patch did. Doing anything else
IS a step in the wrong direction.
next prev parent reply other threads:[~2010-08-04 18:12 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-02 19:20 [PATCH v6 0/3] Merge renormalization, config renamed Eyvind Bernhardsen
2010-07-02 19:20 ` [PATCH v6 1/3] Avoid conflicts when merging branches with mixed normalization Eyvind Bernhardsen
2010-07-02 19:20 ` [PATCH v6 2/3] Try normalizing files to avoid delete/modify conflicts when merging Eyvind Bernhardsen
2010-07-02 19:20 ` [PATCH v6 3/3] Don't expand CRLFs when normalizing text during merge Eyvind Bernhardsen
2010-07-02 22:46 ` [PATCH v6 0/3] Merge renormalization, config renamed Junio C Hamano
2010-08-04 3:19 ` [PATCH/RFC eb/double-convert-before-merge 0/6] merge -Xrenormalize Jonathan Nieder
2010-08-04 3:20 ` [PATCH 1/6] merge-trees: push choice to renormalize away from low level Jonathan Nieder
2010-08-04 3:21 ` [PATCH 2/6] merge-trees: let caller decide whether to renormalize Jonathan Nieder
2010-08-04 3:21 ` [PATCH 3/6] ll-merge: " Jonathan Nieder
2010-08-04 18:12 ` Junio C Hamano
2010-08-04 3:22 ` [PATCH 4/6] rerere: migrate to parse-options API Jonathan Nieder
2010-08-04 3:23 ` [PATCH 5/6] rerere: let caller decide whether to renormalize Jonathan Nieder
2010-08-04 18:12 ` Junio C Hamano [this message]
2010-08-05 11:08 ` [PATCH/RFC v2 0/12] " Jonathan Nieder
2010-08-05 11:09 ` [PATCH 01/12] t6038 (merge.renormalize): style nitpicks Jonathan Nieder
2010-08-05 11:41 ` Ævar Arnfjörð Bjarmason
2010-08-05 11:54 ` Jonathan Nieder
2010-08-05 11:11 ` [PATCH 02/12] t6038 (merge.renormalize): try checkout -m and cherry-pick Jonathan Nieder
2010-08-05 11:13 ` [PATCH 03/12] t6038 (merge.renormalize): check that it can be turned off Jonathan Nieder
2010-08-05 11:13 ` [PATCH 04/12] merge-trees: push choice to renormalize away from low level Jonathan Nieder
2010-08-05 11:15 ` [PATCH 05/12] merge-trees: let caller decide whether to renormalize Jonathan Nieder
2010-08-05 11:16 ` [PATCH 06/12] Documentation/technical: document ll_merge Jonathan Nieder
2010-08-05 11:17 ` [PATCH 07/12] ll-merge: make flag easier to populate Jonathan Nieder
2010-08-05 12:12 ` Bert Wesarg
2010-08-05 12:16 ` Jonathan Nieder
2010-08-05 13:05 ` Bert Wesarg
2010-08-05 13:11 ` Jonathan Nieder
2010-08-05 11:24 ` [PATCH 08/12] ll-merge: let caller decide whether to renormalize Jonathan Nieder
2010-08-05 11:25 ` [PATCH 09/12] t4200 (rerere): modernize style Jonathan Nieder
2010-08-05 11:28 ` [PATCH 10/12] rerere: migrate to parse-options API Jonathan Nieder
2010-08-05 11:30 ` [PATCH 11/12] rerere: never renormalize Jonathan Nieder
2010-08-05 11:32 ` [PATCH 12/12] merge-recursive --renormalize Jonathan Nieder
2010-08-05 19:02 ` [PATCH/RFC v2 0/12] Re: rerere: let caller decide whether to renormalize Eyvind Bernhardsen
2010-08-04 3:29 ` [PATCH 6/6] merge-recursive: add -Xrenormalize option Jonathan Nieder
2010-08-04 18:10 ` [PATCH/RFC eb/double-convert-before-merge 0/6] merge -Xrenormalize Junio C Hamano
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=7vocdifdrk.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=eyvind.bernhardsen@gmail.com \
--cc=finnag@pvv.org \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=jrnieder@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).