git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Jakub Narebski <jnareb@gmail.com>,
	Finn Arne Gangstad <finnag@pvv.org>,
	"git@vger.kernel.org List" <git@vger.kernel.org>
Subject: [PATCH/RFC eb/double-convert-before-merge 0/6] merge -Xrenormalize
Date: Tue, 3 Aug 2010 22:19:35 -0500	[thread overview]
Message-ID: <20100804031935.GA19699@burratino> (raw)
In-Reply-To: <cover.1278093311.git.eyvind.bernhardsen@gmail.com>

Hi Eyvind,

Eyvind Bernhardsen wrote:

> Here's a new version of the merge normalization series that renames the
> configuration variable.  Since "merge.renormalize" got the best
> response, I went with that.

I have no idea how the following branch happened in my local git tree,
but it’s here now so maybe it’s worth something.  Somehow I got the
idea that the merge_renormalize variable was a nice short-term
protection but long-term scary, and so a few patches emerged to
banish it.

Please let me emphasize that in their current form I do not think
these patches should be very usable.

But for later, they tell a nice story.  The idea is that the
"merge.renormalize" is not really about the behavior of the "git
merge" command but about the merge-recursive driver; and so it
should be usable everywhere else that driver is used, too.

So in an ideal world, you would be able to, e.g.:

	git checkout -m -Xrenormalize otherbranch

or

	git revert -Xrenormalize otherpatch

or

	git pull --rebase -Xrenormalize

Of course, the plumbing is not all there yet; many commands that
use merge drivers cannot pass through arbitrary options through
yet.

Well, enough talking.  Here are the patches; what do you think?

Patch 1 teaches blob_unchanged() to stop paying attention to the
merge_recursive variable.  It uses a parameter instead.  So from then
on, it can watch, bemused, a neutral party.

Patch 2 adds and respects a renormalize option in the merge_options
struct.  It defaults to the value of the merge_recursive global to
save callers (in particular, "git merge") the pain of adjusting.

Patch 3 lets ll_merge merge callers decide whether to renormalize,
too.  Most callers never renormalize, since they are not "git merge"
(and this is noted in new comments).

Patch 4 is a sort of a digression.  It makes "git rerere" produce nice
help output with the "git rerere -h" option.

Patch 5 lets rerere callers decide whether to renormalize, too.  Most
callers never renormalize.  But looking at that patch reveals a
serious problem: there are all kinds of other merge options (e.g.,
-Xsubtree) that rerere callers are unable to control.

Following the principle that scripted users should have about as
much power as internal ones, patch 5 reluctantly exposes the
renormalize option to rerere as a new --renormalize option.  It
should be -Xrenormalize instead.

Patch 6 eliminates the merge_recursive global once and for all, by
teaching merge_recursive callers to set the renormalize merge option
appropriately (and removing the backward-compatibility default).
Callers that are not "git merge" still never use renormalize.

Following the principle that scripted users should have as much
power as internal ones, it also exposes the nice interface of an
-Xrenormalize option.  Some redundancy between builtin/merge and
builtin/merge-recursive is noticed but left for another topic.

Jonathan Nieder (6):
  merge-trees: push choice to renormalize away from low level
  merge-trees: let caller decide whether to renormalize
  ll-merge: let caller decide whether to renormalize
  rerere: migrate to parse-options API
  rerere: let caller decide whether to renormalize
  merge-recursive: add -Xrenormalize option

 Documentation/merge-strategies.txt |    8 +++++
 builtin/checkout.c                 |   13 ++++++++-
 builtin/commit.c                   |    4 ++
 builtin/merge-recursive.c          |    2 +
 builtin/merge.c                    |   24 +++++++++++----
 builtin/rerere.c                   |   56 ++++++++++++++++++++---------------
 builtin/revert.c                   |   18 ++++++++++-
 cache.h                            |    1 -
 environment.c                      |    1 -
 ll-merge.c                         |    4 +-
 ll-merge.h                         |    2 +-
 merge-file.c                       |    2 +-
 merge-recursive.c                  |   11 ++++--
 merge-recursive.h                  |    1 +
 rerere.c                           |   20 ++++++++----
 rerere.h                           |    1 +
 16 files changed, 117 insertions(+), 51 deletions(-)

-- 
1.7.2.1.544.ga752d.dirty

  parent reply	other threads:[~2010-08-04  3:21 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 ` Jonathan Nieder [this message]
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
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=20100804031935.GA19699@burratino \
    --to=jrnieder@gmail.com \
    --cc=eyvind.bernhardsen@gmail.com \
    --cc=finnag@pvv.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@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).