what do y'all use for version control?

Using Arduino Programming Questions
1

I've been trying to use git, and frankly it confuses the heck out of me :slight_smile: I think I understand how to use it ... and then something odd happens and I realise I don't. I grew up with rcs and then cvs (but have forgotten most of what I once knew about 'em), and git seems strangely complicated. Maybe I'm just getting old...

Anyway, without ever intending to or knowing why, I seem to have got into some kind of recursive situation where I have "a repository inside your repository" and am wondering how to undo this without
deleting any of my precious working code... and the "easy GUI" git tools like GitKraken are almost more obscure than the CLI. I couldn't even get SourceTree to finish installing :slight_smile:

So I have a few questions:
is there a really, really basic cookbook online for git? I mean, "for dummies" stuff?
are there easier interfaces to git than the cmd line?
is git even the flavour of the month any more? is there some newer/cooler rev control system out there that I should know about?

I'm just a solo developer so I'm not needing to merge changes from multiple devs or anything fancy, just want to checkpoint my work now and then and insure against catastrophic things happening to my hard drive. I do local backups in triplicate of course, but a remote network backup is always comforting.

thoughts? sure would be nice if the ARDUINO IDE incorporated cvs :slight_smile: with change tracking on every Save... (dear devs, don't throw anything at me)

2

I'm just a solo developer so I'm not needing to merge changes from multiple devs or anything fancy, just want to checkpoint my work now and then and insure against catastrophic things happening to my hard drive. I do local backups in triplicate of course, but a remote network backup is always comforting.

I've been using the Sloeber Eclipse plugin for writing my own Arduino code lately. Eclipse interacts pretty nicely with Git by itself. You get to a point and then you make a commit and it asks if you want to push to github or somewhere and you can if you want.

I almost don't like it because it has kept me from really learning anything about how git really works. So it sounds like it might be just what you are looking for.

3

Github for Dummies would be a best seller, but unfortunately that book is not (yet) in the 'for dummies' series. However googling that phrase brings up dozens of tutorial sites.

4

I also did this: I put in each of my projects a header called "git_version.h" which has a single line with a #define defining "git_version" with the first however many (i can't remember right now) characters of the hash for the current commit. I wrote a little shell program that I put into the extra programs that Eclipse runs when it compiles that grabs the git hash from the current commit and writes it to that header (the header is NOT part of the repository obviously) before it compiles the code and then I can have a print line in setup somewhere that will output that. This way I can grab a board I haven't seen in forever and still figure out which version of which program it is running.

5

Tazling:
I seem to have got into some kind of recursive situation where I have "a repository inside your repository" and am wondering how to undo this without
deleting any of my precious working code.

If you want to post a link to an online repo or attach a .zip file of it here, I'll take a look.

Tazling:
is there a really, really basic cookbook online for git? I mean, "for dummies" stuff?

I tried the most popular ones, but none of them appealed to me. In the end, my learning process with Git has been task driven: I need to do something I don't now how to do so I start researching until I find the solution and stop there. I always start with the Git manual but that is not very beginner friendly. Quite often I end up finding my solution on Stack Overflow, which seems very well suited to answering this sort of question. After finding the solution. I write down the set of steps required and then refer back to my own notes when I need to do that task again (usually these are things that I do so rarely that I've forgotten by the next time).

Tazling:
are there easier interfaces to git than the cmd line?

I started with GitHub desktop. That provided a very beginner-friendly interface. Although it's well integrated with GitHub, you can use it with your local repositories or repositories hosted elsewhere. I will say that has been some years since I last used GitHub Desktop so I don't know how it is now. My only annoyance was that they were regularly making significant changes to the interface and pushing these out without any warning. GitHub Desktop provided the basic functionality I need every day without the beginner unfriendly interface that would be required to provide the more advanced features needed less often. As a beginner that was exactly what I wanted. However, as I became more of an advanced user, Over time, I found myself resorting to the command line more and more often for the tasks GitHub Desktop didn't do. I feel that a GUI is often more efficient than a command line for manually executed tasks. I went on a huge search for the perfect Git client software. I installed all the common options that supported Windows. I was extremely unimpressed with the ones that had been highly recommended to me, such as GitKraken. They seemed to be mainly focused on a "beautiful" interface rather than actual functionality. For me, software is not about making a fashion statement. I only care about how well it works. For an advanced user, the best option by far is Git Extensions:

Tazling:
is git even the flavour of the month any more? is there some newer/cooler rev control system out there that I should know about?

Git is the most popular by far. If you're contributing to modern open source software projects, you're most likely going to need to use Git. Probably the competitor for "flavour of the month" is Mercurial.

Tazling:
sure would be nice if the ARDUINO IDE incorporated cvs :slight_smile: with change tracking on every Save...

It has been requested but I don't know. I feel that it would end up making the IDE less beginner friendly while not providing the functionality needed by advanced users. I prefer to have my version control software separate from the IDE. That way I can use the same Git client software for all my projects, rather than having one system for Arduino sketches and another for everything else.

6

Tazling:
is there a really, really basic cookbook online for git? I mean, "for dummies" stuff?

Likes this?
http://forum.arduino.cc/index.php?topic=416526.0

are there easier interfaces to git than the cmd line?

TortoiseGit.

7

I've never figured out Git of any of the other version control systems. They all seem to require me to me more disciplined than I am and to do lots of stuff I don't want to do or don't need to do - as well as all the work of learning them.

I have written a short Python program to compile and upload my code and it makes an archive containing all the code (including external libraries) when it uploads a program and includes in setup() in the .ino file a print line with the name of the archive.

I also wrote the Python program so I can use relative references to files such as #include "./myStuff.h"

...R

8

I still use rcs for local single-person projects, but have been putting more and more stuff on github - sharing, backup, cloud access, bug tracking, AND version control...

I found a nice git MOOC - will update when Iā€™m at a desktop.

9

My version control is mostly retrospective... as in oh cr@p, wish I'd done a Save As 10 minutes ago.

10

Delta_G:
I've been using the Sloeber Eclipse plugin for writing my own Arduino code lately. Eclipse interacts pretty nicely with Git by itself.

Me too. When you create a new repository for an Eclipse project do you just let it put in all the files it wants? Or, do you selectively ignore / delete any files from the repository?

In my mind, all I should have to save in the repo is source code that I've written. Anything project-related and any generated object code could, ideally, be excluded from the repo. Eclipse should be able to recreate all that stuff when I build. But, I've run into problems getting too aggressive with this philosophy. If I remove the project from Eclipse (but not the repo) and then try to import it again, it's unable to build.

11

I am perpetually impressed by the way that my stupid questions asked here reliably lead to intelligent and interesting discussions. It's very nice of y'all to take the time.

I will look into Sloeber Eclipse. In the meantime I have learned the power of deleting the .git file in a folder :slight_smile: which seems to nuke the version control while leaving my precious source files untouched.

I used to like cvs for day2day use but... setting it up from scratch was always a bit of a puzzler. Git seems easier to initiate (git init and so on) but harder when you want to add folders or otherwise rearrange the dir hierarchy. I have got the hang of the push (to remote repo), so I have makefiles that do this for me. I think it's really the structural housekeeping that gets me tangled up in git; deciding at what level of the hierarchy to establish the repo, then getting into trouble if I change my mind about that.

Anyway, very interesting discussion and I will certainly have a look at Eclipse.

12

I've been trying to use git, and frankly it confuses the heck out of me :slight_smile: I think I understand how to use it ... and then something odd happens and I realise I don't. I grew up with rcs and then cvs (but have forgotten most of what I once knew about 'em), and git seems strangely complicated. Maybe I'm just getting old...

Haha! I thought I was the only one that never could understand git.

Even in the old "professional" days, I never was able to really work out how to run version control systems. So complicated and non-interesting. But, there was always someone around who did and would just tell what to click on to make it go.

Actually.. Same with any sort of IDE.. I still live in dread of having to set up a new development system.

I find that git is very handy as a way to pass my code from home to the shop. I just keep hitting the upload button whenever I stop. Then, when I swap locations, I click download and VOOM! Back on track, ready to go.

Most of the other functions always seem to do things I really don't expect, and are a bit terrifying in the potential destruction they may perform. Forking and pulling is just massive confusion to me. When someone asks me to check/test their "fork" of some code I'm always like.. "Err.. ok I guess? Gulp!"

-jim lee

13

Tazling:
...harder when you want to add folders...

I believe git add {folder name} works to add everything from a folder. You may have to append a \. to that.

Tazling:
...or otherwise rearrange the dir hierarchy...

git mv from the command line (Git Move) works a treat.

14

I'm a big believer in version control. I've used pretty much everything (sccs, rcs, cvs, svn, mercurial, git) and have been diligently using version control on everything since the early 80's.
Back then it was sccs and it pales in comparison to more modern tools like git.

At this point, I'd recommend using git.
For the most part, version control is about being able to easily track changes and do things like tell which files have changed and what you have changed, and tag things for future reference. The new/modern systems allow remote repositories and that is a huge win as you can use this like offsite storage.
git is particularly useful as it solves many of the issues around branches and branch management that many of the older systems could handle or didnt' handle very well.
git also easily supports local as well as remote repositories and the full repository is all contained locally so you don't have to have a network connection to track changes, do comparisons, or commit new changes, even if the repository is remote on a server.

IMO, the key to making a version control system easy to use is to use one that has plugings that integrate into the operating system's GUI file manager. That way you simply navigate using the built in file manager like caja, nautilus, windows explorer etc, that you already know how to use and that allows easily doing version control management directly from the file manager.
My favorite tools are rabbitvcs for linux and if you happen to still be using windows, tortoisegit
With those, the file icons will change to indicate various statuses of the files and you can right click to perform various version control actions. You can also right click on a file to look at changes that have been made in the file and do all the typical version/file related things like, commit, move, rename, tag, delete, push, pull, etc...

Yes I still do some git things from the command line but it isn't very often as the typical work flow can all be handled from the extensions added to the GUI file manager. About the only time I use the command line is if need to do something out of the ordinary like undo something.

One thing that can be an issue when using git is trying to break the old mentality and some of the habits from using other systems like rcs/cvs/svn. Things like revision tags/keywords within files simply don't exist in git as git revisioning uses a different methodology. Once you start to think in terms of assigning a revision to an entire group of files or project rather than doing revisions on individual files, things can become easier and make a bit more sense.

--- bill

15

gfvalvo:
Me too. When you create a new repository for an Eclipse project do you just let it put in all the files it wants? Or, do you selectively ignore / delete any files from the repository?

In my mind, all I should have to save in the repo is source code that I've written. Anything project-related and any generated object code could, ideally, be excluded from the repo. Eclipse should be able to recreate all that stuff when I build. But, I've run into problems getting too aggressive with this philosophy. If I remove the project from Eclipse (but not the repo) and then try to import it again, it's unable to build.

I ignore all that build stuff and the eclipse files. I only repo the source. Sometimes I'll copy libraries into the repo if I think they might become version issues later. I can't remember right now exactly how I go about rebuilding a project from a repo. But it is something I can usually re-figure out pretty quick. I do it every couple of years when I update versions of eclipse. The process involves creating the project with some empty files and then pulling from the repository on git. It acts just like you just wrote that code. You'll have to rebuild the git.ignore file and stuff like that but the gui in eclipse makes it pretty easy. You have to link your libraries back to the project again and that can be a pain to figure out the first time. You use "Import" from one of the menus I think. I would know if I saw the dialog. If you really really want I can look when I get home.

16

bperrybap:
I'm a big believer in version control.

This is not a complaint or a criticism. And I am not expecting a Reply or an attempt at further explanation.

When I read through your Reply #13 almost none of it is meaningful to me. There is clearly some high-level concept in your head that I have never managed to get into mine :slight_smile:

...R

17

Ok, since were on the subject.

What's the best way to set up repositories? Right now I have one big one basically everything Arduino. I'm wondering if the idea would work better if I had one per library folder that I own/manage?

-jim lee

18

jimLee:
I'm wondering if the idea would work better if I had one per library folder that I own/manage?

One repository for each project is ideal. Each project should be a logical group of files. "Everything Arduino" is not a logical group. "My Weather Station" is a reasonable logical group.

Smaller project specific repositories allow you to make the best use of branching, tagging, and merging.

Larger multi-project repositories make it difficult to manage branches / tags and impossible to merge.

19

Robin2:
When I read through your Reply #13 almost none of it is meaningful to me. There is clearly some high-level concept in your head that I have never managed to get into mine :slight_smile:

I had a similar reaction to all the Git tutorials I tried. As a hobbyist, I just wasn't that dedicated to learning the topic from the foundations. So I gave up on that and just started using it, first via the simplified and limited GitHub web interface, then on to the slightly more powerful GitHub Desktop. Instead of learning Git just for the sake of learning Git, I was able to get hooked on this incredibly useful tool with very little effort, then learn what I needed in little bits as I went along. For a professional, this is probably not the efficient way to do it. But for someone like you who is having trouble seeing the benefits of moving on from caveman-style version control, I think it would be a good path.

20

jimLee:
I'm wondering if the idea would work better if I had one per library folder that I own/manage?

Much better. The mega-repo approach is going to lead to a messy commit history that's impossible to follow. The only reason I you should even consider doing something like that is if I was working with multiple libraries that are closely coupled, where a change to one often requires a change to the other in the same commit. Even then, it's a bad idea because the ideal Arduino library repository is to have a single library in the root of the repository. That makes it easy to install. It's also required if you want to add your library to the Library Manager index. All the official Arduino libraries are structured this way. The 3rd party Arduino repositories that are not structured that way are a frequent cause of confusion for beginners. Prime examples being: