A version control system for embedded work, which doesn't need a PhD

[newbrain]

That's what I do regularly. I'll be working on something in R:\project\working and have a  bright idea or want to test something so create R:\project\temp.

But, allow me to say, if you are using this strategy with git "you are holding it wrong".

The easiest way is to create a new branch from where you are, and use it for your tests and experimentation.
The mantra with git is "branching is cheap".

If you are happy with the results, the experimental branch can be easily merged back into the main one.
If not, it's enough to checkout again the main one, then you can delete it - but it's often better to keep it around (maybe there was some good idea).
If you are only partly happy there are a number of alternatives, depending on the cases: cherry pick the commits you like into the main branch, pick just some files etc.

If in the time you work on your idea the main branch has progressed, you can merge it every now and then to keep current, or rebase on it (with some caveats).

PERL has been my preferred  method for abstract interfacing any of them...

you know.. things change over time and it is very good keep sanity

PERL and sanity, what a strange combination .

[brucehoult]

Or create a bare repo somewhere on your local filesystem or network, add it as a remote, and then push to it from time to time, obviously.

That is what I do, but push to it every time. Obviously. And that allows it to get backed up properly too. But since that's exactly how and why I use svn, I'm wondering why this is better when it takes more steps, leaves more debris and isn't the way it's meant to be used.

If you push to it every time then do it the way I showed, with repo and checkout in different places.

[PKTKS]

PERL has been my preferred  method for abstract interfacing any of them...

you know.. things change over time and it is very good keep sanity

PERL and sanity, what a strange combination .

Yep...  took me awhile (circa early 90s start dealing w/PERL..)...

But after a steep initial crank ... make no mistake about PERL.

It is currently the most powerful and wise method to achieve from simple to complex tasks close *very close* to a POSIX OS.  Fast absolutely concise and way smarter than above others..

Frequently you find talks about replacing POSIX shells w/PERL.

Benefits of having OO integrated binding to TCL/Gtk/Qt and almost any wrapper you can think of already in CPAN.

Still today I wonder how damn smart is PERL above other alternatives

A COMPILER frequently kicks in discussion.. (OR JIT) but that will just make things worse as you can manage a perl site way smarter without such things..

It takes time to manage. I am not even close the masters ..
Frequently I wonder how damn powerful some things can be easily done in it.

Paul

[magic]

That's what I do regularly. I'll be working on something in R:\project\working and have a  bright idea or want to test something so create R:\project\temp.

But, allow me to say, if you are using this strategy with git "you are holding it wrong".

The easiest way is to create a new branch from where you are, and use it for your tests and experimentation.
The mantra with git is "branching is cheap".

Branch switching is fun until you want to work on multiple branches simultaneously for a prolonged time and perhaps even have many of them opened in the editor at the same time. Constant recompilation of all the files that differ between branches isn't fun either.

[DiTBho]

Branch switching is fun until you want to work on multiple branches simultaneously for a prolonged time and perhaps even have many of them opened in the editor at the same time. Constant recompilation of all the files that differ between branches isn't fun either.

What the frog do you have to version?
and how do you resolve merge conflicts in a Git repository?

[rsjsouza]

Clearcase was indeed brutal.

[magic]

What the frog do you have to version?
and how do you resolve merge conflicts in a Git repository?

Well, any project which keeps stable release branches around and supports them with bug fixes. As the old releases diverge from master it can become quite tedious to switch branches and recompile everything to chase an old bug. Bonus if there is urgent work on master to do at the same time.

Or maybe you work with something like gerrit where features are developed on side branches, reviewed and then merged to master. The features may be independent so there are no merge conflicts, or they may be interdependent and then the developers need to coordinate. At any rate, if you participate in the development of several features, you want several branches and this is more convenient to manage with several checkouts.

Or perhaps you have a few versions of Linux-the-kernel to maintain and deploy on various systems. You want separate build directory for each one because stable releases only receive small fixes most of the time and incremental build saves time. But you want to share .git between them because the thing has grown to a few gigs in size nowadays.

[PlainName]

But, allow me to say, if you are using this strategy with git "you are holding it wrong".

Feel free, and you are right

The easiest way is to create a new branch from where you are, and use it for your tests and experimentation.
The mantra with git is "branching is cheap".

Yes, the new one might well be a branch (or might not - depends on circumstance). But that doesn't change anything: I will have multiple working folders and most, if not all, of them will be vaped at some point.

Yes, I could keep checking in and out to the same working folder, but for various reasons I will drop in and out of editing/viewing/breaking them, sometimes on a whim. I might use one purely as a reference if it's a big project. And, of course, there are times when I am supremely lazy and the hassle of having to tidy up the current stuff, check in, out, view, check out, let the editor figure out it's symbols table is skewiff... nah, can't be arsed this time.

Contrast all that with a massive and lengthy file.. open.. MRU pick. Or even just alt-tab because with multiple directories I can have multiple editor instances at the same time. Strangely, that seems to be news to some developers!

[PlainName]

If you push to it every time then do it the way I showed, with repo and checkout in different places.

Sorry, I overlooked the critical detail of that one.

Edit: mostly because I can't seem to get it to happen on Windows.

[brucehoult]

If you push to it every time then do it the way I showed, with repo and checkout in different places.

Sorry, I overlooked the critical detail of that one.

Edit: mostly because I can't seem to get it to happen on Windows.

I have no idea why, because that specifically uses a text file (called ".git") in your project directory that contains the path of the actual git repo in plain text. There is no use of symlinks or hard links or other Unix-isms.

[magic]

Other than working on Wind0ze, it's no better than symlinking. You still end up sharing one HEAD state, which means that changing branch in one working directory changes it for all the others too

[brucehoult]

Other than working on Wind0ze, it's no better than symlinking. You still end up sharing one HEAD state, which means that changing branch in one working directory changes it for all the others too

The threat model he was concerned about was rm -rf'ing the source code checkout directory and losing all history.

If you want multiple checkouts then you make a master repo somewhere (which you probably want to be "bare" i.e. without a source code checkout) and use git clone to make each working directory. If the master repo is on the same filesystem then the working directory copies will hard link to the master repo rather than duplicating all the data.

[peter-h]

The notable point is that while a VCS enables you to do all sorts of clever stuff e.g. go back to version current minus x to see where you broke something (which is a great thing to have) it doesn't get around the need to back "something" up whole, and to that regularly.

All that changes is that instead of backing up the project, and the IDE app (in this case ST Cube IDE) configuration (which is likely spread all around the place; in this case in c:\st\...\Configuration) and doing this at each significant point in the development, you now have to do the same thing with the VCS repository.

The repo needs to be copied (but not automatically mirrored, for obvious reasons) to another piece of hardware. My experience is that no matter what quality parts you use to build a machine (and I have built many more than I could remember) what tends to happen is that the power supply blows up and takes out not just the motherboard but the HD, and the HD controller. When I build a machine I buy two motherboards for this reason, but have stopped using RAID because both HDs tend to go, or just the controller goes and unless you can get an identical RAID controller you have lost all the data anyway.

So, as with so many things in "IT" e.g. "cloud storage" all you are doing is moving the "backup policy" from one place to another.

[magic]

The threat model he was concerned about was rm -rf'ing the source code checkout directory

... while deleting the checkouts of abandoned branches.

If you want multiple checkouts then you make a master repo somewhere (which you probably want to be "bare" i.e. without a source code checkout) and use git clone to make each working directory. If the master repo is on the same filesystem then the working directory copies will hard link to the master repo rather than duplicating all the data.

I suppose it will stay that way till the first background run of the repacker in either repository
And won't apply to subsequent fetches from other remotes.

[H.O]

Don't think it has been mentioned so thought I would: https://www.fossil-scm.org/

[newbrain]

Don't think it has been mentioned so thought I would: https://www.fossil-scm.org/

It was, some posts above:

https://www.fossil-scm.org/home/doc/trunk/www/index.wiki

The concept and philosophy behind it might be interesting (though their "git vs. fossil" page is really biased*), but there's a fundamental objection to this SCM, and to all non-git ones:
Stackoverflow survey 2021.

I don't think this to be a case of "million of flies" - these are people who use tools for productive work, both independent workers or enterprise employees.

Possibly an exception could be made for mercurial or subversion, but in my personal experience, their user bases are also shrinking.
E.g: for work, I was recently involved in the migration of a (quite niche) FOSS from mercurial to git.
It went really smoothly, and both users and devs were happier in the end.
There was some internal initial resistance to the move from a couple of developers, mostly due to adapting to slightly different way of working, but nothing major.
One of them, in fact, was then tasked with laying out the new way of working with git (branching, tagging, and merging strategies) - and they made an excellent job.


* But they admit it. In Italy we say "oste, è buono il vino?" ("innkeeper, is your wine good?"), what answer do you expect?

[SiliconWizard]

* But they admit it. In Italy we say "oste, è buono il vino?" ("innkeeper, is your wine good?"), what answer do you expect?

Absolutely.

[dferyance]

Git is a horrible version control system -- but I use it all the time. Yeah, something being popular can be a good reason to use it.

I've long been a fan of DVCS but git was the one I didn't want to win -- so of course it did.

• The name "git" is just bad. There is something very wrong with professionals using a version control system named after an insult.
• The command-line interface is confusing and inconsistent. Never feel bad if it is confusing to you.
• It isn't even really a program, it is C code with a bunch of scripts and shell dependencies. Git for Windows is a mess of things hacked together.
• git LFS is a hack.
• Merge history is not preserved. After you merge a branch, you cannot determine which branch changes were done on.
• Garbage collection can and will decide to throw away commits you've done. This only happens if something isn't tagged or branched but a version control system should never throw away history.

[magic]

Git means "ok" or "fine" over here. Americans will always find something to complain about

[Kjelt]

If git was perfect they would have called it god 

[PlainName]

noun British informal an unpleasant or contemptible person: that mean old git | a warped, twisted little git.

– origin 1940s: variant of get (sense 2 of the noun):
British informal or dialect a person whom the speaker dislikes or despises.

[magic]

Speaking of Americans

Code: [Select]

hint: Using 'master' as the name for the initial branch. This default branch nam
e
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint:   git config --global init.defaultBranch <name>The genius who made this commit also apparently tried to format the message so that the lines don't wrap but failed to account for the prefix added by git

[dferyance]

Git means "ok" or "fine" over here. Americans will always find something to complain about

Words always have context. Linus Torvalds didn't pick a name that meant "ok" or "fine". That's not his style. It's pretty well documented that he intended the insult. He wanted to name it something stupid. I'm not personally bothered by something like this, but as an engineer, communication matters. Having something childish like this doesn't help when trying to represent the new and growing software field to others who don't understand it.

[SiliconWizard]

Interestingly, there's something similarly wrong with the "Rust" name for the Rust language.

I agree that communication matters. And actually, as you mentioned, Linus *did* pick the name for a reason. The reason itself does say something about what his intent was. And his intending the insult is sort of reflected in how defensive git proponents usually become when you start criticizing it.

But Linus is well known for this kind of behavior. Don't get me wrong, I think he's a great guy overall and has done a lot of good, but his attitude has always been pretty much offensive and self-centered. The name of "Linux" should give you a hint as well.

Ok we're digressing a bit here, but not so much. Many people seem to agree on the fact git has its flaws, but that they'll still use it because it has become so widely used. The very success of git, compared to other systems that are objectively good as well, is likely due not just to its merits, but to the aggressiveness with which it has been imposed by those deploying it.

[rsjsouza]

The name of "Linux" should give you a hint as well.

Regardless of Torvalds' motivations and personality, if I was creating something that I thought was pretty new I would also have found a way to tag my name to it. Besides, his name goes along quite well as an anagram of the master system Unix and very few people can dissociate the product from the name of its creator. Genius!