Overcoming git conflicts

[mikematos84]

What would be the best way of overcoming git conflicts with actions-template-sync? I have a few files in my last template sync attempt that have conflicts and I am unsure of the best way about going and resolving them.

Any thoughts?

[AndreasAugustin]

Hi @mikematos84
one way of solving those conflicts is to pull them to a local machine

git fetch
git checkout <branch_pr_source_name>

locally you can use an IDE or any text editor to fix the conflicts. After the conflicts are fixed, commit the changes and push them to the branch

# pro hint: sign commits with -S option https://dev.to/andreasaugustin/git-how-and-why-to-sign-commits-35dn
git commit <-S>
git push

Remark:
If there are issues with files you do not want to change, add them into a .templatesyncignore file located within the root or .github/ folder of the repository.

I hope I understood the question and the proposed solution helps a bit.

[mikematos84]

Oh my apologies. Yes I did solve the problem already. Thanks.

[AndreasAugustin]

Perfect :) thanks for the answer 👍

[shubov]

@AndreasAugustin I would like to add to this discussion.

The current behaviour of creating the pull request is to accept the template's version by default (parameter -X theirs of git_remote_pull_params here).

But if I don't want the conflicts to be resolved this way, I have just a few options:

1. replace it with -X ours which doesn't recognise any changes from the template and is therefore useless
2. or to remove -X theirs completely - then the pull request is created with merge conflict markers and it is a pain to remove it by hand. Because GitHub then doesn't recognise them as conflicts anymore, it will not allow to resolve them in the interface of the GitHub app or IDE.

What could you advise if I would like to resolve the conflicts by myself?

[AndreasAugustin]

@shubov thank you for the question.
Unfortunatly I do not have a solution for your problem.
Currently you see the changes within the opened pull request and you are able to adjust them to your needs. This can also be done within the github editor.

Maybe it is possible to pull the remote changes and commit them with the unresolved merge conflicts (think this is possibe, have something in my memory but am currently not able to reveal this part). Maybe a force commit can help (needs a small adjustment within this action).

Will try to find some time to think about the issue. Would be nice to contact if you find a solution meanwhile. If you want to play around with the action and you are a bit into docker, maybe the docker images can help (this won't interfer with your local environment). Unfortunately this is not documented (yet #254 )

[shubov]

Thank you for the answer, @AndreasAugustin!
For now, I decided to manually pull updates from my template repo, until I find a better solution. The merge conflicts appear when I pull from the template repo (before creating the commit) and it is convenient to resolve them manually at that point (JetBrains IDEs or VS Code provide the UI to have an overview of the changes and resolve them fast).
If I find a better way, I will send a message as well.

[JessicaS11]

A related question: we have the -X theirs flag set, but conflicted files are completely excluded from the PR (with the notice Automatic merge went well; stopped before committing as requested). Any idea what might be happening (action file here)?

[AndreasAugustin]

A related question: we have the -X theirs flag set, but conflicted files are completely excluded from the PR (with the notice Automatic merge went well; stopped before committing as requested). Any idea what might be happening (action file here)?

Hi @JessicaS11 most likely the conda/*lock changes are not taken because they are excluded within the .templatesyncignore.

Related to book/preliminary/git.md I do not have an idea (yet).
If you like to debug, there is a docker image available. Or you execute the related commands on a local computer.

[JessicaS11]

Hi @JessicaS11 most likely the conda/*lock changes are not taken because they are excluded within the .templatesyncignore.

Makes sense. Thanks for pointing that out!

Related to book/preliminary/git.md I do not have an idea (yet).

This is definitely the file we were concerned about! No debugging time for this on my end ATM; had just wanted to document it and make sure we weren't missing anything obvious.

[AndreasAugustin]

Hi @JessicaS11 ,

the issue is not related to the git pull it is related to the handling of templatesyncignore.

The issue:

☁  IS2-website-2024 [tmp] ⚡  cat .templatesyncignore | awk NF | xargs echo           
# THIS FILE CANNOT BE SYNCED # use glob patterns as in .gitignore # recommend listing non-basics tutorial directories here # configuration files cookiecutter.yaml # environment lock files conda/*lock.yml # team member files team/*-* # book files (configuration, usage-specific) book/_config.yml # event-specific tutorials

the commented lines are not removed. Came in with #510 or was already present before.
As a intermediate action please remove the comments.
Will be tracked with #536

[herrwusel]

I'm hijacking this question since mine is of a similar nature: I'm syncing files that need to be reverted to the targets state. First, I thought that I use fixup commits and squash them to keep the commit history small. But that would let the action believe that the template is not synced, wouldn't it?

[AndreasAugustin]

@herrwusel
Sorry for late response.
Even if you squash a commit git will keep some information about the commits made. Those are so called dangling commits.
git will clean them up after some time (AFAIK or never like GitHub is configured ) with a gc (garbage collection).

The action is using git cat-file to check if the template is already synced (related your discussion #535).
There is a parameter to bypass this setting is_force_push_pr.

[herrwusel]

Thank you for your response. You always teach me something new. I did not know about danling commits :)

By default actions/checkout has the fetch depth set to 1. Would that not implicate that dangling commits are missing?