list mirror (unofficial, one of many)
 help / color / Atom feed
From: Jonathan Nieder <>
To: Elijah Newren <>
Cc: Git Mailing List <>
Subject: Re: Opinions on changing add/add conflict resolution?
Date: Mon, 12 Mar 2018 11:47:34 -0700
Message-ID: <> (raw)
In-Reply-To: <>


Elijah Newren wrote:

> Hi everyone,
> I'd like to change add/add conflict resolution.  Currently when such a
> conflict occurs (say at ${path}), git unconditionally does a two-way
> merge of the two files and sticks the result in the working tree at
> ${path}.
> I would like to make it instead first check whether the two files are
> similar; if they are, then do the two-way merge, but if they're not,
> then instead write the two files out to separate paths (${path}~HEAD
> and ${path}~$MERGE, while making sure that ${path} is removed from the
> working copy).
> Thoughts?

My immediate reaction is that it seems inconsistent with the rest of
merge behavior.  Why would add/add behave this way but edit/edit not
behave this way?

Would this behavior be configurable or unconditional?  I suspect I
would want it turned off in my own use.

On the other hand, in the case of wild difference between the two
files, skipping the two-way merge and just writing one of the versions
to the worktree (like we do for binary files) sounds like something I
would like in my own use.

Can you add something more about the motivation to the commit message?
E.g. is this about performance, interaction with some tools, to
support some particular workflow, etc?

Thanks and hope that helps,

> I have a patch series[1] with more details and other changes, but
> wanted to especially get feedback on this issue even from folks that
> didn't have enough time to read the patches or even the cover letter.
> Thanks,
> Elijah
> [1]

  reply index

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-12 18:32 Elijah Newren
2018-03-12 18:47 ` Jonathan Nieder [this message]
2018-03-12 21:26   ` Elijah Newren
2018-03-12 21:35     ` Jonathan Nieder
2018-03-12 23:08       ` Hilco Wijbenga
2018-03-12 23:14         ` Jonathan Nieder
2018-03-13  0:38       ` Elijah Newren
2018-03-13 17:22         ` Elijah Newren
2018-03-13  5:30     ` Junio C Hamano
2018-03-13 18:21       ` Elijah Newren
2018-03-13 22:26         ` Junio C Hamano
2018-03-13 22:42           ` Elijah Newren
2018-03-13 22:52             ` Junio C Hamano
2018-03-13 23:04               ` Elijah Newren
2018-03-13 22:56             ` Jonathan Nieder
2018-03-13 23:14               ` Elijah Newren
2018-03-13 23:30                 ` Junio C Hamano
2018-03-12 22:19 ` Ævar Arnfjörð Bjarmason
     [not found]   ` <>
2018-03-13  2:53     ` Fwd: " Elijah Newren
2018-03-13 22:12       ` Junio C Hamano
2018-03-13  9:59     ` Ævar Arnfjörð Bjarmason
2018-03-13 17:09       ` Elijah Newren

Reply instructions:

You may reply publically 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:

  List information:

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

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone public-inbox