Preventing oneself from creating merge conflicts across branches

[chillpert]

I frequently run into the following problem:

I work on some branch called feat/my-cool-feature, where I modify and commit changes to some file. The engine locks that file for me automatically. Now, I get a request to provide a bug fix or quickly prototype something on another branch. I end up modifying the same file on the other branch, unaware of the fact that it was already modified on feat/my-cool-feat. After all, I was never warned that this could be dangerous by the engine or the plugin, because the file was locked by myself. After a while, I try to merge both branches but I end up with a merge conflict because the file has diverged.

Currently, I am working on a solution to this problem. My goal is to update the source control status icon and display a notification that warns me about modifying a file. I already have a very basic proof-of-concept implementation working that involves writing each file that is locked together with the branch it was locked to a local file. However, this only works as long as locking files is done from inside the editor. I could also try solving this on the LFS executable's level instead.

When looking up this topic online, I can't find anyone else with the same problem. I wonder if I am missing a very obvious solution, but as far as I know, Git LFS does not track the branch on which a file was locked, which should be necessary to address this issue. While there are tracking branches that could technically help with this, I think they are not a good approach to this problem.

I wonder if anyone has opinions on this topic in general, or if it's something that would be relevant to other users too.

[mastercoms]

Hi! Thanks for the discussion topic. I would say please read the status branch section of the readme. https://github.com/ProjectBorealis/UEGitPlugin?tab=readme-ov-file#status-branches---conceptual-overview

For feature branches, you can read a community example of how to do this for all remote branches here: #177 (comment)

[chillpert]

I have been using status branches already but only for the main development branch. It's good to know that it supports wildcards though.

However, this does not work unless all commits in question are actually pushed to the remote, right? I usually don't push what I am working on until it's in an acceptable state, so status branches won't work here as far as I understand them. I guess it would be an acceptable solution to push all of my commits as I go, or at least remember to push before I switch branches.

Also, if I modify a file and it gets locked automatically, but then I stash it because I need to switch branches, I would also end up not getting any warning. Maye that's too much of an edge case, but I have been in this situation at least a few times.

That's why I got started on a custom solution. Since there can easily be many false-positives (e.g. stashed changes are abandoned or a commit was dropped), I would try to adjust the warning message, as in "Your file might have been modified on branch branch-name".

[mastercoms]

I guess this is mostly a problem with local development and the same user, which is an interesting problem for sure, and probably needs some more work to solve. However, unless I'm missing something I think it should be as simple as allowing for local branch checks in status branches, and then if you want to go further in terms of tracking LFS locks on certain branches, that's going to be another can of worms.