From: Junio C Hamano <email@example.com> To: Elijah Newren <firstname.lastname@example.org> Cc: Ævar Arnfjörð Bjarmason <email@example.com>, Git Mailing List <firstname.lastname@example.org> Subject: Re: Fwd: Opinions on changing add/add conflict resolution? Date: Tue, 13 Mar 2018 15:12:14 -0700 Message-ID: <email@example.com> (raw) In-Reply-To: <CABPp-BFsiWBiDYYvz=cOofECUHUMJs8x8RuMXqeCF1qP5HzGoQ@mail.gmail.com> Elijah Newren <firstname.lastname@example.org> writes: > As currently implemented, yes. However, I was more concerned the idea > of handling files differently based on whether or not they were > similar, rather than on what the precise definition of "similar" is > for this context. > > As far as the definition of similarity goes, estimate_similarity() is > currently used by rename detection to compare files recorded at > different pathnames. By contrast, in this context, we are comparing > two files which were recorded with the same pathname. That suggests > the heuristic could be a bit different and use more than just > estimate_similarity(). (e.g. "We consider these files similar IF more > than 50% of the lines match OR both files are less than 2K.") Yeah, I think there is similar difference between similarity score that is used by diffcore-rename and dissimilarity score that is used by diffcore-break exactly for that reason. If you start from a 100-line original file and grow it to 100-line one by adding 900 lines, as long as you kept the original 100 lines, it is easier to view the change within the same path as a continued development, instead of saying they are so dissimilar. In any case, I think the way the stage #2 and stage #3 (i.e. ours and theirs) contents are externalized during a conflicted mergy operation should be consistent across edit/edit and add/add conflict, so if we are adding a new way to write out extra temporary files out of these higher stage index entries, it should be made applicable not only to add/add conflict (i.e. there shounld't be a code that says "oh, let's see, this lacks stage #1, so do this different thing"). Personally, I think it is best to leave it all outside of the core and make "git mergetool" to be responsible for the job of externalizing higher stage index entries to temporary working tree files. They already need to do so in order to work with external tools that do not read directly from our index file anyway, no?
next prev parent reply index Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-03-12 18:32 Elijah Newren 2018-03-12 18:47 ` Jonathan Nieder 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] ` <CABPp-BHDOimDoLxWxS=BDOBkm6CUTrXTzD16=TSkWGN-HOiU2g@mail.gmail.com> 2018-03-13 2:53 ` Fwd: " Elijah Newren 2018-03-13 22:12 ` Junio C Hamano [this message] 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: 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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.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
firstname.lastname@example.org mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git 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: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox