From: Elijah Newren <firstname.lastname@example.org> To: Ævar Arnfjörð Bjarmason <email@example.com> Cc: Git Mailing List <firstname.lastname@example.org> Subject: Re: Opinions on changing add/add conflict resolution? Date: Tue, 13 Mar 2018 10:09:01 -0700 Message-ID: <CABPp-BEOi6GAoHUZyfcJdd-eLwPLoyRMOiS-J1dvkjqm7VGj9Q@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Tue, Mar 13, 2018 at 2:59 AM, Ævar Arnfjörð Bjarmason <firstname.lastname@example.org> wrote: > On Tue, Mar 13 2018, Elijah Newren jotted: >> However, I'm far more concerned with the three collision conflict types >> having consistent behavior than I am with changing add/add conflict >> handling. And if your two concerns or Jonathan's concern would prevent you >> from wanting to use the new merge strategy (and possibly prevent it from >> becoming the default in the future), I'd much rather just modify rename/add >> and rename/rename to behave like add/add. Would that be more to your >> liking? > > I don't really object to these changes, I don't know enough about this > area, I skimmed your patches and 90% of it is over my head (although I > could keep digging...). > > I'm just chiming in because it seems to me from upthread that you're > purely focusing on the use-case of the user of git who's using git at > the abstraction of using a dumb editor that doesn't do anything to help > them with conflict markers to resolve conflicts. Yeah, that's totally why I started this separate thread; I was worried the original would push away folks who weren't familiar enough with merge-recursive or were just overwhelmed by all the different changes and rationale, but I really wanted to get feedback on at least the piece that people were likely to hit in practice and would understand. Thanks for doing so; your, and Jonathan's, and Junio's comments have provided some good context. > Also another caveat: Since these are new side-files what happens when > you're in a conflict and run `git clean -dxf`, are these new files wiped > away, or are they somehow known to the index? A git clean would wipe them out...and if that scares you (and I can totally see how it might), then rest assured that the situation is a whole lot worse: this isn't limited to rename/add and rename/rename(2to1) conflicts. There are several paths in merge-recursive.c that call unique_path() to get a temporary filename that is in no way tracked in the index but which is used for storing content relevant to the merge. These include directory/file conflicts, untracked files being in the way of putting a renamed file where it belongs, untracked files being in the way of a modify/delete, untracked files being in the way of simple adds on the other side of history, rename/rename(1to2)/add/add, and maybe others. In all cases, a git clean is going to wipe out the files that were written to different temporary locations. My rewrite I'm trying to find time to work on would get rid of the code paths involving untracked files being in the way of other stuff, but would do nothing for the other cases. I would love to get rid of all of them, but don't have a clue how to do so.
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 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 [this message]
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-BEOi6GAoHUZyfcJdd-eLwPLoyRMOiS-J1dvkjqm7VGj9Q@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