markusschloesser / MackieC4_P3

A Mackie C4 Midi Remote Script for Ableton 11
20 stars 2 forks source link

Ms stable #26

Closed markusschloesser closed 3 years ago

markusschloesser commented 3 years ago

is this how to do it?

markusschloesser commented 3 years ago

how do we resolve these code conflicts?

BilldarBagdar commented 3 years ago

I reviewed the changes (changed files tab here) and they don't look like they would generate any substantial conflicts.

As a guess, I suspect you didn't "Pull from origin master" into your local master before you checked out and started making changes to your stable branch. Now there is some conflict between what is already in origin/master and what you want to Pull in from your stable branch. First off, making new branches and "pushing / pulling" them around is the correct "way" to be using git. So, good job there. Like I said, I don't think the conflict is substantial, maybe two places. I haven't actually asked git or PyCharm to show me any conflicts, but I can see here that all conflicts are in the one file, and that's the one file where I made a couple of changes that you "pulled into master", and I expect that's what is "conflicting".

Git is very good about only "merging" what is demonstrably safe to merge, and marking everything else as a conflict.

Unfortunately, "conflict resolution" is something I can't give you a clear "lesson" on, because I don't really know it well enough myself. Personally, in this case, I think I would checkout master locally, pull in origin/master, checkout stable locally, and then pull in (local) master. You should get the same conflicts, and PyCharm can then show you the local conflicts "in one file". Resolve any conflicts locally, and push another commit (which will go straight into this Pull request) and then you should be able to merge into origin/master here because any conflicts already got resolved.

The basic way I understand the resolution process is (when I am looking at "conflicted merge files" in my IDE) git surrounds the conflicts with symbols that mean "these lines here (in origin/master for example) are the latest HEAD revision" and "these lines here (in the branch you want to Pull in) are from an older HEAD revision", and you the human need to make the decision about which code (your branch, what git thinks is newer, or some combination) should win the conflict. You fix the conflict(s) by deleting the "git marker symbols" and the code that should go away, and keeping only the code that should stay. Then you do a "conflict resolution commit" or whatever and the Pull should then finish successfully.

I could do it, and I definitely still need practice because I "work alone" in my repos at work, (and I try to avoid creating conflicts) so I don't see enough to have a good handle on resolving them. But I suspect you need even more "conflict resolution" practice, and this looks like it could be an easy resolution to reach.

Also, if you haven't pulled in my "folders branch" (to origin/master and your local branches) and it sounds like you want to restructure the repo like that, definitely take care of Pulling in that branch too at the same time and bring your local branch revisions up to "origin revision" across the board. Save aside your latest .py files (out of git's control) before you start so you can comfortably let the repo "folder structure" update without worrying about any of your latest work getting overwritten or destroyed. (After the repo is (branches are) all updated, if any of your code is "missing" when you checkout a new branch, just paste your latest "changes" back in from the backup files)

Can I reassign this Pull request back to you? If you really want me to resolve the conflicts here in this Pull request, I will. Just say you want to "learn another time" or whatever.

BilldarBagdar commented 3 years ago

closing as discussed.