From: Elijah Newren <email@example.com> To: Jonathan Nieder <firstname.lastname@example.org> Cc: Git Mailing List <email@example.com> Subject: Re: Opinions on changing add/add conflict resolution? Date: Tue, 13 Mar 2018 10:22:42 -0700 Message-ID: <CABPp-BHDVqq4atmCw=WX4KkV1C-kGh0MubowevJBw6n=qF56nA@mail.gmail.com> (raw) In-Reply-To: <CABPp-BE653uMpwN4zfCCP8teRGmZ6v5NEyASCR1PTvHhoMKE1w@mail.gmail.com> On Mon, Mar 12, 2018 at 5:38 PM, Elijah Newren <firstname.lastname@example.org> wrote: > I feel the analogy to merging binary files breaks down here in more > than one way: Actually, after mulling this over, I'm going to retract the "more than" piece of this sentence. I'm trying to figure out how to retract more, but have only figured out one piece. In particular... > 1) > > Merging binary files is more complex than you suggest here. In > particular, when creating a virtual merge base, the resolution chosen > is not the version of the file from HEAD, but the version of the file > from the merge base. Nasty problems would result otherwise for the > recursive case. > > If we tried to match how merging binary files behaved, we run into the > problem that the colliding file conflict case has no common version of > the file from a merge base. So the same strategy just doesn't apply. > The closest would be outright deleting both versions of the file for > the virtual merge base and punting to the outer merge to deal with it. > That might be okay, but seems really odd to me. I feel like it'd > unnecessarily increase the number of conflicts users will see, though > maybe it wouldn't be horrible if this was only done when the files > were considered dissimilar anyway. Thinking about this more, it really isn't that weird at all. The code is already set up to use null_oid as the "original" version when creating a virtual merge base, going back to the content from a recursive merge base is a strategy used in multiple places in recursive cases, and null is precisely the version from the recursive merge base. If two added files differ wildly, I don't think using null would increase the number of conflicts appreciably, if at all. So, the analogy to merging binary files holds just fine from this angle. So, if we could figure out how to handle the higher numbers of paths for e.g. the rename/rename cases, then perhaps this is a strategy that could work. >> Interesting. I would be tempted to resolve this inconsistency the >> other way: by doing a half-hearted two-way merge (e.g. by picking one >> of the two versions of the colliding file) and marking the path as >> conflicted in the index. That way it's more similar to edit/edit, >> too. > > Your proposal is underspecified; there are more complicated cases > where your wording could have different meanings. > <snip> > My question for your counter-proposal: > Do you record C1 or C2 as C? Or do you record the version of C from > HEAD as C? And what do you pick when creating a virtual merge base? > > Problems I see regardless of the choice in your counter-proposal: > * If you choose C from HEAD, you are ignoring 3 other versions of > "C" (as opposed to just one other version when merging a binary file); > will the user recognize that and know how to look at all four > versions? > * If you choose C1 or C2, the user will see conflict markers; will > the user recognize that this is only a _subset_ of the conflicts, and > that there's a lot of content that was completely ignored? > * There is no "merge base of C1 and C2" to use for the virtual merge > base. What will you use? For this last question, the answer is "null", and it works just fine. I don't yet have good answers to the other questions, though. If someone else does, I'd love to hear it. Oh, and by the way Jonathan, thanks very much for your feedback and alternative ideas for consideration. You gave me more angles to try to think about this problem from.
next prev parent 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 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 [this message] 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 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 \ --in-reply-to='CABPp-BHDVqq4atmCw=WX4KkV1C-kGh0MubowevJBw6n=qF56nA@mail.gmail.com' \ --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 list mirror (unofficial, 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/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox