Show diff on conflict before deciding if overwrite or skip interactively

[yajo]

When the user is asked interactively if he would want to overwrite or skip a conflicting file, he has no way to know what's the good answer.

This relies on the expectation that the subproject will be git-tracked and thus the user is able to inspect the diff afterwards. But, if that's not the case (for example a git-ignored file with secrets within), he cannot safely decide.

In the case where it is git-tracked, anyway being able to inspect the diff interactively still seems to be a good UX enhancement.

[pawamoy]

Would be nice indeed, that's what cruft is doing (it does more than that and allows to pick parts of a diff, I think it runs git add -p or similar). With syntax highlighting it would be great 😄 If it uses git, maybe git's config will be used to show the diff (and so delta or diff-so-fancy could be used).

[ppo]

Great ideas 😀

I was thinking about that when submitting my issue. That said…

If the files are versioned, I guess it's easier to check the changes after the update; using the tools you're used too.

The only problem is obviously for files that are not versioned.

The only way to solve the problem of git-ignored files containing auto-generated/random content is to allow to cherry-pick the lines you want to update.

[yajo]

That's probably gonna be too much work for little benefit.

It'll be easier to give option of storing diff in a separate file. Otherwise you can also just copy the term output and paste it elsewhere.

[ppo]

Could we find an agreement regarding the desired behavior, "what would be the best solution", and put that as a target/an open task?

If it's too much work or nobody wants to implement it, we can find a "temporary solution" until the really desired solution is done.

And the plan C would be to just document the problem with options to solve it (manually).

[yajo]

Yes, what I mean is that, once there is a conflict, you get a message such as:

conflict some-file.txt  overwrite? [y=yes / n=no / d=see diff / r=save .rej file]

In case the user chooses d, then the diff is printed and the question is asked again.

Does that look good?

[BradHolmes]

I'm not sure if the internals of copier's conflict resolution are amenable to this suggestion, but it seems to me that producing git conflict markers would work well with popular IDEs. Is that possible?

[yajo]

That seems like a separate issue.

[suprememoocow]

I'm not sure if the internals of copier's conflict resolution are amenable to this suggestion, but it seems to me that producing git conflict markers would work well with popular IDEs. Is that possible?

I'm using copier to perform automated updates (using Renovate Bot), and having conflict markers would be preferable for my use-case too. In our case, we'd actually commit the conflict markers, and have GitLab's interactive conflict editor resolve them from the merge request widget.

[yajo]

El mié, 22 de jun de 2022 a las 00:05:42 AM, Andrew Newdigate ***@***.***> escribió:

I'm using copier to perform automated updates (using Renovate Bot <https://docs.renovatebot.com/>), and having conflict markers would be preferable for my use-case too.

Cool! Is there some plugin for that bot to do the copier update?

In our case, we'd actually commit the conflict markers, and have GitLab's interactive conflict editor resolve them from the merge request widget.

That's a use case I never thought about, but looks very nice.

[pawamoy]

Related: two-way merge PR (which links to a three-way merge PR as well).

Also, just thought about something: showing a diff on conflict might be confusing for users. Indeed, Copier might first overwrite a file which has a conflict, but it will later re-apply the diff it calculated between a clean-generated project and the current project. It means that sometimes, you see "conflicts", you overwrite, but at the end of the update, the conflicting files didn't change at all. I guess that should be taken into account.

[yajo]

Yes, I have to improve that too. Maybe I can just overwrite everything. After all, only git-tracked repos can be updated, and you can rollback anything before committing. El mié, 22 jun 2022 10:24, Timothée Mazzucotelli ***@***.***> escribió:

…

Related: two-way merge PR <#627> (which links to a three-way merge PR as well). Also, just thought about something: showing a diff on conflict might be confusing for users. Indeed, Copier might first overwrite a file which has a conflict, but it will later re-apply the diff it calculated between a clean-generated project and the current project. It means that sometimes, you see "conflicts", you overwrite, but at the end of the update, the conflicting files didn't change at all. I guess that should be taken into account. — Reply to this email directly, view it on GitHub <#343 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHNXDJ3BXQS7SKEGPUWB63VQLLVZANCNFSM4W6GNWVA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[pawamoy]

That's personally what I do, yes, overwriting everything all the time, then dealing with diffs in VSCode.

[suprememoocow]

Cool! Is there some plugin for that bot to do the copier update?

Unfortunately not, but we've hacked this in using Renovate's regular expression manager, and a special file that we keep in the repository, alongside .copier-answer, called .copier-version.

The configuration that we use for this is here: https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/blob/main/renovate-common.json#L46-54 (this is where we configure the Regular Expression manager) and here https://gitlab.com/gitlab-com/gl-infra/common-ci-tasks/-/blob/main/renovate-common.json#L142-159 ( where we tell copier to perform the update)

[yajo]

After the analysis we made here and after seeing #741 arise as a yet another bug based in this approach, I'm going to close this feature request in favour of fixing #741 by applying #343 (comment).