Incorrect, there are tons of git repos that get synced via git commands. Just look at Github.Because you can't sync git in git (nor any other SCM afaik).
Incorrect, there are tons of git repos that get synced via git commands. Just look at Github.Because you can't sync git in git (nor any other SCM afaik).
I'm not sure I understand your point. My example is the "git" is WORK, you make changes on machine A, commit and push, then on machine B you git pull. Not really complicated at all. It just depends on "what" the OP needs to sync. If it's just data, lots of solutions, git, rsync, cvs, rcs, svn etc. If it's the entire machine including OS that is different and at least to me, raises the question "Do you really need to keep OS level in sync?". A lot of times the answer is no.Yeah mer, good example of how complicated this can get. Because you can't sync git in git (nor any other SCM afaik).
I think that this is what OP is angling for... But that's imposssible to know unless OP confirms.astyle Interesting point. For me, my editing is just text (code, writing quick start things, engineering cya papers) so "whatever version of emacs or vi is installed is fine". spreadsheets, formatted documents, agree that everyone either needs to use the same versions or have agreement on the minimum version.
Incorrect, there are tons of git repos that get synced via git commands. Just look at Github.
I'm not sure I understand your point.
But even so, one can have subprojects in git. I have git repo for A (can be home directory or just a work thing). Under A I can have a git repo for B. (this is real life example from my $WORK). What happens is I do work in B, changes, testing, commits but it does not affect A. At some point I'm in A and want to pull in the changes from B. In git repo A I have done a "git clone B"; but in A, repo B is last time I did cd A/B && git pull. git status in A shows B is changed and needs to be comitted.Sorry I may've gone astray to scenario where whole home dir is under source control. You were speaking about just using git to track same version of work files.
I'm not a fan of that approach. If I were in your shoes, mer , I'd put in the effort to keep private and work-related repos as separate as possible, to the point of having completely different repos, with different URLs for each purpose. Yeah, that's more work in some respects, but mixing personal and work-related stuff is just not a good idea.But even so, one can have subprojects in git. I have git repo for A (can be home directory or just a work thing). Under A I can have a git repo for B. (this is real life example from my $WORK). What happens is I do work in B, changes, testing, commits but it does not affect A. At some point I'm in A and want to pull in the changes from B. In git repo A I have done a "git clone B"; but in A, repo B is last time I did cd A/B && git pull. git status in A shows B is changed and needs to be comitted.
So whole home directory under git with things under home being git sub projects, one can change home directory and keep subprojects unchanged and others can change the subprojects without you pulling them into your home directory .
Confusing? Sure. Useful? Sure. But leads me back to "You must decide what you need. If you ask for help from 3rd parties, you must make clear what you wish to accomplish"
Me? I've always been "my data is the important piece"
Anyway, I'd like the OP to let us know more about the important pieces so we don't speculate.
I've got a friend who swears by nextcloud, I need to try it out some time, it sounds useful.I'm pretty happy myself with my own Nextcloud instance. My work machines may not be identical, but the bulk of my files lives in there and is readily available with native clients for everything I use. Pictures I take using my phone go there almost instantly, great for snapping diagrams off whiteboards and getting them on my desktop.
Keeping the basic software like editors/libreoffice in sync so that you use the same version on both machines - now that is a nice idea, but very hard to pull off. Hell, at one point, I tried to have same version of KDE on different machines. But no matter the amount of research I put in, no matter what I tried - that proved beyond me - for purely technical reasons.
Trust me I do. My example was really "work repo A that has work repo B as a subproject" but I extended it to what Zare was thinking of "my $HOME is a git repo that has other git repos as subprojects"I'm not a fan of that approach. If I were in your shoes, mer , I'd put in the effort to keep private and work-related repos as separate as possible, to the point of having completely different repos, with different URLs for each purpose. Yeah, that's more work in some respects, but mixing personal and work-related stuff is just not a good idea.
Sorry, it looks like I confused $HOME with 'private repo that has has nothing to do with $WORK'...Trust me I do. My example was really "work repo A that has work repo B as a subproject" but I extended it to what Zare was thinking of "my $HOME is a git repo that has other git repos as subprojects"
My $work stuff is done on $work systems ($work is linux I ssh from my FreeBSD to them), so yes separated.
If one machine gets the security patches on a regular basis while the other one does not (due to not being used very much, as per OP's scenario), at some point, they will just diverge too far to be able to accept each other's pre-compiled packages. And it really sounds like OP would prefer to avoid replicating the compilation efforts. Why else would OP look at syncing options and explore what's possible with them?Just install the same package file on both machines? Trivial if you build yourself or you fish it out of pkg on one machine.
I didn't know that had a name! Runescape has a quest that presents that puzzle (chicken, grain, fox), and the wiki mentions it being a variant of "Fox, goose and bag of beans" puzzle (that redirects to the main wolf, goat, cabbage pageI think that OP probably has a wolf, goat, cabbage situation