Configuration version control on a modified machine.

[edwilliams16]

My hard disk is cluttered with Marlin versions with my corresponding configuration files. Now I know enough git to be dangerous, I'm thing of trying to version control this.
To be concrete, I have a modified Rigidbot and that to derive my configuration from the Marlin example requires maybe a dozen changes.
Should I fork this repo and add a my_Rigidbot branch? I would need to make a script to build Marlin with the configuration pulled from here - easy enough for the current code, but I'm not sure how I would wind back both Marlin and Configurations to a common point in the past if I wanted to build an older version.
Alternatively, I could make a my_Rigidbot branch in my Marlin repo, but then it's not clear to me how I would pull in upstream changes to configuration.h. Are those changes totally reflected in the Marlin default configuration.h, so I could attempt to apply the diff in that file to my custom configuration.h? Or are the changes made to the files in this repo machine dependent?

This is an obvious enough problem that I'm sure others have come up with good solutions.

[Roxy-3D]

For sure... Git offers good solutions if you know a lot about Git. My Git skills are pretty weak.

So... I just have a big hard disk. And I keep a folder with each machine's name. I put a complete copy of every version of firmware in the proper folder with a name that has the title formatted as: date-Marlin_version-Title.

And then... rather than use Git to do comparisons and move code blocks around, I use ExamDiff Pro.
Personally.... This works very well for me.

When I need to find a particular code block or merge things... ExamDiff Pro lets me easily move things around. (AstroGrep is a big help doing searches for particular things across many versions of the firmware.)

[thinkyhead]

The methodology here is still under development, but it shouldn't affect how you maintain your Marlin configurations.

The way that I keep my configs in order is by keeping a separate branch in my Marlin fork for each machine. The only thing that differs in each one is the contents of the configuration files. Then when I want to update one of those branches to the newest Marlin I just merge in the changes from upstream/2.0.x and push the updated branch to my fork. This approach still works with the example configurations having been moved here. (Though we still have to make better accommodations for deltabots.)

This repo is meant to make it easy to see the options that have been altered from the defaults, and with the diffs clearly in hand, we will also be experimenting with alternative layouts.

[NezSez]

Sry for the lengthy necro-bump post, but not sry enough to not post it :)

I'm not ready to contribute, so I clone to my local machine (not GitHub) and branch using git directly in VSCode's terminal git (which does everything I need more or less, so I don't use GitHub Desktop, tortoise, etc). Separate clone for Marlin/Configurations, which I don't modify at all. On both clones I set a bogus git remote set-url --push origin no_push so I can't gorilla-pointer click the wrong button in VSCode and push via the teeny-tiny "Synchronize Changes" icon accidentally :)

In VSCode I make a Marlin "Workspace", I add the Marlin FW repo project, and the Marlin Configurations repos dir, which allows me to diff/cmp/merge the examples configs with my current Marlin configs across the repos.

In local Marlin repo I create a branch per machine (which will NOT pull/push/track from origin or the local by default, more on that later). I don't ever push/merge back into the original local Marlin repo, I pull into it from origin/upstream (actual Marlin GitHub repo) then git switch <my-branch> and git pull . bugfix-2.0.x (or 2.0.x etc), cd to the Configurations dir, switch to branch, pull ( which is also from upstream Marlin Github). If either of these hork on merge (due to rebasing, upstream commits, etc), I don't bother with an actual merge triage, I just git fetch <branch> ; git reset --hard origin/<branch> so that they are sync'd with master (as it were).

Then I switch to my personal machine branch in Marlin repo, diff/merge my-configuration.h and my-configuration_adv.h (actual file names I added with comment annotations for why I changed a setting; unique names so they don't get clobbered from upstream while I experiment with local branch tracking) with Configurations/default/*.h and with Configurations/examples/<machine>/<whatever-variants>/*.h configs. Then I merge those changes into the actual configuration.h, configuration_adv.h (without all the comments to preserve line# sync with originals for use when posting/discussing with others) when I'm ready to build. I git stash any changes (without staging is easiest, although stash has a flag for dealing with staged changes too) if I need to pull from origin/upstream, then just git apply ; git commit -m "<message here>" then autobuild.

In the config files, I use the STRING_CONFIG_H_AUTHOR setting with my username, machine/board-name, and the date that I edited it, and sometimes a feature keyword like "BLTouch" or "Dual-Z-Steppers", so I can search/grep/bifurcate for those elements and easily find a commit hash based on the date, as well as correlate (to some degree) with the publish date on Marlin Github repo. I played with some options modifying the version stuff in the marlin config files, but they would get clobbered, so stuck with something designed to not be clobbered. Most projects I've worked with before actually used "release"/"dev" branches and/or actual "minor" version numbers in the branch names which was easier to skim than ".x" or commit hashes, I've thought about just making a new branch off the custom branch like "bugfix-2.0.13" with odd# being rc type and even# being release/working (like linux kernel for example), just so I could easily spot working commits for rebuilding, but I currently just do that in the commit messages and just continuously use the same working branch.

I clean my builds, and do not archive the the binaries. I just checkout the commit I need and rebuild (and yes that could bite me if libs/VSCode/AutoBuild, etc change); I'll just upgrade, pull current and rebuild if I have to and go from there.

In spite of various IntarWebs advice, I have not gotten a local branch to properly track another local branch yet. I did mange to convolute/pollute my git .config to within epsilon of pristine chaos though . This would only benefit me by giving me status info on my feature/custom branchs' drift from the local at whatever commit I've left the local sync'd to without having to switch branches, which is exactly the behavior I want. No biggie, I just switch to the local branch set to origin/upstream (which is the Marlin Github repo) and type git status and switch back without pull/merging into the branch; just a pain to switch branches all the time just to check how many commits i'm behind.

Which brings me to...

GIT WORKTREE, which has actually been around for some years. This is supposed to allow some optimization (at some cost of course) of sync, non clobbering/merge-able branches, and disk space but I haven't quite got my head wrapped around the significance of the workflow benefit/caveat/perils of it yet. Of course local branch tracking has been touted to work since something like 2011 or so and although the settings took, none of the options actually worked for me, they always went to origin/upstream even if set to a local file://<repo-dir/branch> or reported a non-valid repo. And yes I played with git branch/remote flags, absolute vs relative paths, /branch vs /branch/.git vs /branch.git, etc but have not gone through all the permutations yet.
My "search filter bubble" made it difficult to even find any info at all about tracking a local repo....searches returned about how to track/add/remove a REMOTE branch (which is easy and why everyone and their house-plant blogs about it). I literally found only two posts, both on stackexchange I think.

I'll have to rework my workflow, like actually pushing to a GitHub clone of Marlin, if I ever get the chutzpah to actually submit code, use the marlin scripts, and issue a PR, but as a non-contributing user for now, I'd like to get more examples of git workflows, especially with enough detail to help anyone jump in quickly and get involved. Any advice on setting up tracking a local branch (not the tracked local branchs' origin/upstream urls, but to it itself only) from a local branch of that branch, or info on the workflows or benefits of using git worktree would be appreciated.

Again, I apologize for length.

[thinkyhead]

This Issue Queue is for Marlin bug reports and development-related issues, and we prefer not to handle user-support questions here. (As noted on this page.) For best results getting help with configuration and troubleshooting, please use the following resources:

• Marlin Discord server. Join link: https://discord.gg/n5NJ59y
• Facebook Group "Marlin Firmware"
• Facebook Group "Marlin Firmware for 3D Printers"
• MarlinFW.org Marlin Documentation
• Marlin Configuration on YouTube
• Tom's 3D Forums
• RepRap.org Marlin Forum