again a new branch

[markusschloesser]

@BilldarBagdar 2 questions:

1. do you think the implementLiveObjectValid branch is ready for main? Or do you want to do more regression testing?
2. I did another branch "02.04EXP" based on "implementLiveObjectValid", in which I removed ALL clip and clipslots stuff. This got rid of all related errors. Once we wanna do clips stuff again, I suggest to do it properly in a separate class/file (it wasn't working anyway). So ideally you do your regression tests against this branch

[BilldarBagdar]

Ha. I was just coming on to talk about branching and stuff.

I pulled down your earlier changes to "implementLiveObjectValid" (we should talk more about filtering . and - from names only (upper text only, hint hint) But when I compared what is currently in my local "dsplayParams" branch to "implementLiveObjectValid"; although I don't see the difference I was expecting not to see (because you had already also implemented the same code change), I do see a bunch of differences I wasn't expecting (in addition to filtering . and - which I was expecting). For example, are you still seeing [[[]]] and {{{}}} under None in the C4 LCD display on this branch? The diffs seem to be showing me that the only difference between "dsplayParams" and "master" right now is the one change you also put in "implementLiveObjectValid" AND that between "dsplayParams" and "implementLiveObjectValid" there are a bunch of differences (like still showing [[[]]] instead of the blanks on master)

I'm actually kind of guessing about how to fix what I see because it may not actually an issue except for how I'm interpreting the diffs. But I've never really played in the Sourcetree GUI before. At work, I just use the terminal more or less. So I'm learning as I go too. But if I checkout my local master, the (workspace>History) GUI shows the last commit now on master was one changed file (EncoderController) with the comment "comment cleanup, minor refactoring". If I then right click "dsplayParms" (under Branches) and select "Diff against current", the GUI shows me the only file changed (versus master) is MackieC4 and the diff shows the one change I committed there. But when I right click on "implementLiveObjectValid" and select "Diff against current", the GUI shows me several changed files and diffs like the [[[]]] stuff that have me guessing.

It makes me suspect you haven't exactly kept up with your local Pulls or branching or whatever. I can see where you branched off of "implementLiveObjectValid" to create "02.04EXP". But I recommend you stash or commit your local changes, then step back and take a health-check breath. Checkout your local master branch and do a Pull from origin (console: git checkout master followed by git pull origin master). Then checkout "implementLiveObjectValid" again and merge from (local) master (console: git checkout implementLiveObjectValid followed by git merge master). You might have conflicts to resolve before the merge will succeed. Once you've merged (the updated local) master branch changes into "implementLiveObjectValid", then checkout "02.04EXP" again and merge in again from "implementLiveObjectValid" this time. This second, final merge should go much more smoothly (just because of fewer differences since you created "02.04EXP" that need close scrutiny)

The reason I came on to talk about branches and stuff was to say I'm going to create a "shared-dev" branch and Push it up. We can use "shared-dev" as a place to pass changes back and forth (up and down) that is a sort of a "pre-master master" branch, but more about "beta testing" or whatever regressions before actually going to master with some set of changes. Some things might go straight into "shared-dev" right? Other bigger changes might stay on their own branches a awhile as we (you, me, or both of us) patch bugs or whatever. In general then, you and I would need to ensure that whenever any commits merge (get Pulled) into master and/or shared-dev at origin, we Pull them down to our local repository copies and update (like deleting branches no longer needed because they are "copies" of master anyway) before creating any new branches. It's actually kind of an easy practice, if you make a habit of checking out master (or shared-dev?) and Pulling from origin to get up-to-date before creating new branches. It also helps to just sort of habitually, regularly Pull from "master" into whatever branch you have checked out. Seeing "already up-to-date" in the console is nice reassurance.

I want to create "shared-dev" from "master" and then merge "implementLiveObjectValid" into "shared-dev" and make that the first "shared-dev commit". But I think you probably need to catch "implementLiveObjectValid" up with master, and I need to get those changes before I start "shared-dev". Right now, I'm guessing the "track block change", the "filter '.' and '-' change", and the "LiveUtils changes" would be the only differences between master and "shared-dev". and all other branches could be deleted except "02.04EXP" because you have "new (un-merged) changes" there.

Thoughts?

[markusschloesser]

I'm not sure because I'm only looking over your shoulder from the internet, but I suspect you pulled "dsplayParams" into origin/master; but then you didn't Pull origin/master down to your local master branch before you created "liveObj" branch locally, so "liveObj" branch is "behind master" in that respect (because "master" has commits "liveObj" doesn't), as well as being "ahead of master" (because "liveObj" contains commits not in "master") This is exactly a situation where it becomes easy to get lost and "lose changes" that can be difficult to recover.

wait a sec: I checked out master/main from origin/gh, then merged dsplayparam from gh to master/main (which at that point was identical to master at gh) and then pushed the updated master/main to gh.
From there I branched off liveobj, did some things and committed that to gh. You saying that's not correct?

ok, first I guess push up whatever is current in your local "liveObj" so I can get those changes too.

Already done that and was waiting for your tests.

[BilldarBagdar]

That's why I said somewhere yesterday flying and learning to fly at the same time is error prone. Maybe I'm totally confused and your local repo is not in the state it seems or seemed to be. Let me refill my coffee this (hour or two after arising) "morning" and have another look around what the SourceTree GUI shows me.

I checked out master/main from origin/gh, then merged dsplayparam from gh to master/main (which at that point was identical to master at gh) and then pushed the updated master/main to gh.
From there I branched off liveobj, did some things and committed that to gh.

There is no "main" branch. If you would like to rename master to main, we can do that, but using a name and an "unknown alias" in a technical "recipe" like this is just noise. For me, it's helpful to think about two distinct copies of the repository, the internet archive and my local copy, to think in terms of "origin" and "local", but SourceTree doesn't use the word "local". At the top level of the GUI, "Branches" = "local" and "Remotes" = "origin" ("origin" is a folder under "Remotes", and we only have one "Remote repository", so close enough) I suspect for example, "I checked out master/main from origin/gh" means Remotes/origin/master was "marked and BOLD in the GUI as your currently checked out branch after that operation. "then merged dsplayparam from gh to master/main" could mean several things, depending on the operation you actually performed, for sure your assertion that "(...at that point was identical to master at gh)" is (I suspect) not on as solid a foundation as you think.

Again, I'm still getting coffee and need to recheck today. I could be just totally confused, but it still seems possible. If you had Remotes/origin/master (currently) checked out, performed a bunch of "git things" to your checked out branch, and then didn't more-or-less immediately check out your (local) Branches/master copy/clone of (internet) Remotes/origin/master and Pull/Merge those updates down locally; yes, I'm saying you could have a "local repository" that is out-of-sync with the common internet version of the same repository.

[BilldarBagdar]

Also it is good to distinguish between changes you make "at GitHub" in a browser, that always happen at "(Remotes)/origin(GitHub)..." and changes you make in SourceTree when a "Remotes/origin(internet)..." Branch is currently checked out that also happen at "(Remotes)/origin(GitHub)..." like you did by using "gh". But I suspect the way you used "gh" above was a somewhat looser usage than strictly "I was using a browser when I performed this action"

In SourceTree, it's easy for me to tell which of my commits or "git actions" (yours too, just less obvious to me) happened where, Brandi Whiner appears to be the "author" of what I have done "locally", and BildarBagdar appears to be the "author" of what I have done "at GitHub".

You might notice I'm not mentioning PyCharm. In my experience, it's just better to keep "code writing" and "repository maintenance" as separated concerns, handled best by separate apps dedicated to those concerns. I don't necessarily use any of the "repository maintenance" tools in PyCharm except "Commit" and "Rollback" (to "erase" my changes since last commit in a file or files) If I was more of a "power user" of Idea IDEs, maybe the "source control" integrations would be more useful and understandable to me. But, again, in my experience, going outside of "Commit" and "Rollback" in the IDE has always led to "repository maintenance" headaches that need to be "recovered from" with other tools anyway. So I just use the other tools up front. (another one of those (time, effort, resources) decisions) For me, the (GitBash) command line has been the go-to place for "repository maintenance", but now I'm trying to learn how to more effectively leverage the information presented by SourceTree GUI.

[markusschloesser]

There is no "main" branch.

I'm using main/master as identical synonym, because of the current movement to not use master anymore, but I am talking about the master branch

[markusschloesser]

Also it is good to distinguish between changes you make "at GitHub" in a browser

I don't do that 😊 I've been using pycharm's gh implementation, also it shows a symbol if things at origin/gh have been changed

[BilldarBagdar]

1. checkout: Branches/master
2. Pull Remote branch master into local branch master
3. checkout: Branches/implementLiveObjectValid
4. Pull Remote branch implementLiveObjectValid into local branch implementLiveObjectValid
5. <these two branches in my local repository copy are now in sync with the common internet copies>
6. Right-click on Branches/master and select "Diff against current" (current is still implementLiveObjectValid)

This diff is showing me, there are 5 files with differences between "current and master", and if I select the EncoderController file listing, each individual difference appears to the right labelled as "Hunks 1 - 10". Do you see the same 10 "hunks of diff" if you follow the same or similar 6 step recipe? If so, I'm talking about hunks 4 and 5 specifically.

...and now I think I've figured out it was indeed me who was totally confused by what the GUI is/was showing me. My interpretation of the green and red "diff indicator" highlights was reversed, backwards. The green highlight means "this is a 'hunk from the current branch' that is different from the red highlighted "hunk" of the branch in comparison. For some reason my default interpreter jumped to "red = current" instead of "green = current" and confused the fuck out of me.

I'm going to take some time to unwind from that confused state, and reassess the situation. I suspect a "shared-dev" branch will be appearing at origin shortly...

[markusschloesser]

😊😊 All good, and interested, but I admit that I tend to be rather brief in my writing and I quite often get a "schlechtes Gewissen" because you write so much and I feel the need to match your amount of writing.
But this is also related to the fact that I often type from my phone

[BilldarBagdar]

don't worry. This project is bound to see the other side of my "relentless focus" as it were. When for example, I get more interested in playing with music and audio than writing code to support playing with music and audio. :)

[BilldarBagdar]

also - you are the one "reading/writing in a "second" language" correct? Maybe I should feel a little more "schlectes Gewissen" for subjecting you to so much written material in a "second" language... :)

[markusschloesser]

also - you are the one "reading/writing in a "second" language" correct? Maybe I should feel a little more "schlectes Gewissen" for subjecting you to so much written material in a "second" language... :)

don't worry about that, I do more reading in English than here 🤓
There was a time when I spoke English for 12 hrs a day in addition to consuming all TV series and books in English as well. And hey I am a huge Sorkin fan, so I am used to shitloads of text 😂😂

[markusschloesser]

1. checkout: Branches/master
2. Pull Remote branch master into local branch master

I don't do those 2, I just checkout master from origin

3. checkout: Branches/implementLiveObjectValid
4. Pull Remote branch implementLiveObjectValid into local branch implementLiveObjectValid

same

[BilldarBagdar]

Ok Ok Ok... :) Even the "Graph" in the GUI is making some sense to me now.

"shared-dev" is 8 commits ahead of "master" (the same 8 commits that implementLiveObjectValid is ahead) and I pushed "shared-dev" up to origin. I deleted all "my" branches from origin and all branches from my local except "master" and "shared-dev".

I'm thinking we should treat the "master" branch like the "release" branch, even though we haven't "released" anything yet; and then we treat "shared-dev" like our "wip master". If you feel like your current "unit of work" is complete and "shared-dev" is ready to release, then it's ready for "master". On the other hand, if we're still not really on the release bandwagon, frequent "updates to the master branch" (the "fake release" version we pointed people to on the wiki) can wait until we see evidence we're not alone here. :)

If I were to now Pull down your "04.02EXP" Branch from origin. I think our repositories would be in sync in terms of having each other's latest work. Would you agree from your perspective? If so, then both "23.03.2021" and "implementLiveObjectValid" branches can be deleted from origin without any "current work" being "lost". True?

I hope so, but I will stop there after one more comment. IMHO, you could have chosen branch names that contain more information. I know hindsight is 20-20, but what if you had Pushed (to origin) a first branch named "cutLiveUtils" and a second branch named "cutClipsAndSlots". I could easily be accused of being a pot blaming a kettle for being "cookware" because I struggle with "good branch naming" myself. Especially before I have even got my hands dirty. I don't know what a good name will be because I don't know exactly what I'm going to do.

If anything is different, let me know...

[BilldarBagdar]

I was planning to implementLiveObjectValid, and I did.

:) (How do you put the smilies directly in a post? Is it markup?)

Ok - translation issue on my end I think. Did you use "pseudo-German verb-at-the-end form" English and the name means, "implement a valid Live Object"? If so, now that I recognize the form, I have no problem with the informational content level of names like that. If I understood correctly, other names that retain the form but might be more immediately recognizable would be "makeLiveObjectValid" or "requireLiveObjectValid". Not necessarily better choices, and zero difference in information content IMHO, just possibly more quickly grasped by readers like me.

[markusschloesser]

those 😇? Those are emojis and can be done on Windows by "win+." don't know about OSX or Linux

Ok - translation issue on my end I think. Did you use "pseudo-German verb-at-the-end form" English and the name means, "implement a valid Live Object"?

No I was actually referring to "LiveObjValid". Did you check the LOM and stub? I also invited you to the AbletonScript repository. Do a search on liveobj_valid

[BilldarBagdar]

LOL, I'm really behind. I will just shut up about names and information content...

I've never used "standard Windows emojis". When I do WindowsKey +"+/=" key, the whole desktop screen zooms in. (and Win + "-/_" key zooms back out.)

[markusschloesser]

it's Windows + the dot/period

[markusschloesser]

LOL, I'm really behind. I will just shut up about names and information content...

😂 don't worry, I like your (complicated) way of thinking and seeing patterns/interpreting