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

[newbrain]

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.

I'm not so convinced.
I never saw much evangelism for git (but that's just me, maybe).

My idea is that git (flawed, as all the others are in a way or another) has spread so much because, in its basic form, you can make do with very few commands, and later add sophistication to your use.
The initial learning curve is not at all steep (it gets worse, though).

This allowed it to snowball, and the current picture is that there are tutorials everywhere, all IDEs and editors integrate it in a simple way (well, not Eclipse, of course - but I'm repeating myself) and if one has a question any git on any forum can usually answer.

At this point, it's a self sustaining process: if one is at least a bit into FOSS, they are bound to come in contact with it, and then, why invest time and effort in learning something else, unless really warranted by some special need?

Personally, I don't feel any urge, and, TBH,  I'm a bit annoyed when some piece of FOSS I need force me to use something else (so I need to look up syntax and WoW that I'll promptly forget).

[magic]

SiliconWizard is onto something. This was Linus' secret weapon: he made it appeal to gits, and software developers in general are gits. So yes, you will be assimilated

I like git and I think it's the least evil VCS. It's stupidly simple (hint hint) and unlike a lot of software, one can quickly learn how it works and then all else becomes a matter of RTFM on as-needed basis. Yes, the individual commands were designed ad-hoc and sometimes suck, but if you understand what you want to achieve, it's not that hard to find the one that does it. It's a working programmer's VCS and that's how it mostly obliterated the others, particularly those designed for "UX" and "ease for newcomers". (Who gives a damn about those bastards, we want some job security too )

Well, maybe hg would make a good VCS for university courses just like many of them teach Pascal instead of C, but one day you graduate and move on

[DiTBho]

• 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.

these two are bad

[brucehoult]

• 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.

these two are bad

I don't agree.

The first one simply isn't true. Diff the merge commit with its parents and you see exactly which branch changes came from.

The second is like complaining about the existence of the "Empty Trash" command on Mac or Windows, or /tmp on *nix.

[Bassman59]

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.

I thought that the main reason for git's widespread adoption was because "it's used with the Linux kernel." Hence "if it's good enough for the kernel, then anything else in the FOSS world should use git, too." It's the basic network effect (a real-life tautology) ... everyone uses it because everyone uses it. And nobody will switch to something else because nobody uses anything else.

We use Subversion. We have been using it for a long time. The main (indeed only) company repository is served by a Linux box in a rack in a closet. We came up with a workable repo structure. The repo gets backed up automatically every night. We don't see any compelling reason to switch to git. I mean, I look at git regularly (every vendor now has a GitHub repo for their libraries and such) but for the way we work -- each engineer works on their own projects -- there's nothing offered by git that is a must-have.

Everyone's mileage (kilometer-age) varies, of course. The point is that everyone doing firmware/software development should just pick an SCCS and start using it.

[brucehoult]

SVN was for sure the best VCS in 2004 and I switched employers and a few open source projects from CVS to SVN over the next couple of years.

Where I worked, by mid 2007 other employees were sucking the official SVN repo into git and using that for their feature development and for pushing in-progress stuff to each other, only committing finished things to SVN.

As the SVN-master I resisted for a while, but the writing was on the wall. git was clearly superior in almost every way.

The main sticking point was that a really nice tool called CVSzilla had been developed at my 2002-2004 employer, which integrated CVS (and later SVN) with Bugzilla and ViewCVS (later ViewVC when SVN support was added). CVSzilla added a commit-hook which created atomic transactions in its own database (not needed with SVN) and added a bugzilla comment for each commit, with a URL to browse the commit. That kind of tooling didn't exist for git at the start. I evangelised CVSzilla into my 2004 and 2006-2009 employers as well as open source projects such as Gwydion Dylan.

SVN's reign was about three years. I can't imagine using it for a new project now. It would feel like some kind of perversion.

[hamster_nz]

I just stumbled over this in the ACCU's Overload magazine, which seems applicable.

See https://accu.org/journals/overload/29/164/overload164.pdf for the full (free to read) magazine.

[PlainName]

the ACCU's Overload magazine

Interesting that he says, "the tool is not the problem, the workflow is". To me that's arse about face - we have tools to help us, not get in the way and screw up how we do things.

The obvious road ahead, from that, is competing tools demanding you do stuff their way and stuff the other tools' way. Which to bow down to...

[voltsandjolts]

• Merge history is not preserved. After you merge a branch, you cannot determine which branch changes were done on.

You got that wrong.

[magic]

This works because you use sensible merge commit messages. If your message was simply "lol, let's merge dat shit now" then you wouldn't know what the branch was called after you deleted it.

That post probably came from a Mercurial fanboy

[voltsandjolts]

This works because you use sensible merge commit messages. If your message was simply "lol, let's merge dat shit now" then you wouldn't know what the branch was called after you deleted it.

That post probably came from a Mercurial fanboy

Wrong, on both counts, mr magic.
Sourcetree works with git and mercurial (which I have never used, but read good things about it, perhaps closest competitor to git?)

[DiTBho]

The first one simply isn't true

Ah, the disinformation effect. I don't like it when people spread fake news like that 

Yesterday I woke up early in the morning, took my road bicycle and went to the lake and spent the day there. Nice plan, but it's 160 km there and back. So I was a little tired when I got home and I opened the tablet to see what was going on here.

I felt a little worried about these two points. Especially the first one made me seriously worried about Git, a field I'm not an expert in, my skill are basics with Git because I tend to use it for basic operations, and usually for single person projects or LaTex documents, and you can guess why ... I tend to avoid merging too many things that might have conflicts, but it happens so I have a bad feeling because the history of merging really needs to be truly preserved.

Thanks for the answer, it averted possible and catastrophic disasters 

[DiTBho]

Umm, looking at its dependencies ... I see
- bash-completion
- curl
- mozsha1  or ppcsha1 (opts+=" BLK_SHA1=YesPlease" / opts+=" PPC_SHA1=YesPlease")
- threads
- cpio                          (why? isn't tar enough?)
- nls
- "-lpcre" (yes, it tries to link this library)

which are somehow fine, but
- perl? for things like HTML-Tree?!? DateTime-Format-ISO8601?!?
- MediaWiki?!?!?
- emacs?
- python? for things like pygtksourceview?!?
- tk?
- svn?
- cvs?
- gnome-keyring?!?



and a lot of patches, Git, at the source level, looks something weird

[magic]

Wrong, on both counts, mr magic.

I'm never wrong. I meant the post which you responded to - that one came from the camp of  "omg no edit my histories please"

Show how your sourctree helps in this case:

Code: [Select]

git init x
cd x
git commit --allow-empty -m x
git checkout -b y
git commit --allow-empty -m y
git checkout master
git commit --allow-empty -m z
git merge y -m 'merge dat shit lol'
git branch -d yTask: figure out what was the name of the branch that commit y came from. Yes, any tool will tell you that it came from some branch merge, but which one?

Mercurial takes care of that, fossil presumably too. I would still use git.

[newbrain]

- perl? for things like HTML-Tree?!? DateTime-Format-ISO8601?!?
- MediaWiki?!?!?
- emacs?
- python? for things like pygtksourceview?!?
- tk?
- svn?
- cvs?
- gnome-keyring?!?

I would not want o come out as a git fanboy, as to me it's just a tool that happens to be handy and working as expected (for the most part) on all the platforms I use (Linux, Windows, FreeBSD, a little Mac), but:
Most of the above are either for interworking (cvs, svn) or for the graphical client (tk, probably python) or for extensions and APIs (probably perl, emacs, gnome-keyring).

[voltsandjolts]

I'm never wrong.

Hmm, nice oxymoron.

Show how your sourcetree helps in this case:

I'm lazy, I just use Sourcetree for all my git interactions and it just works.
I'll leave you to sort out your own mess.

[DiTBho]

( @newbrain, yup ... I am doing something really "insane", like distilling the minimal setup to compile Git on my PDA; the family 1.6.* of Git looks the best candidate because it's the one with less patches and less "options" to be manually configured ........ also it's the one when if you disable Perl and Python, it doesn't run any test .... and this saves precious building time; will this minimal configuration be *enough* for my basic needs? let's check it out  )

[brucehoult]

Wrong, on both counts, mr magic.

I'm never wrong. I meant the post which you responded to - that one came from the camp of  "omg no edit my histories please"

Show how your sourctree helps in this case:

Code: [Select]

git init x
cd x
git commit --allow-empty -m x
git checkout -b y
git commit --allow-empty -m y
git checkout master
git commit --allow-empty -m z
git merge y -m 'merge dat shit lol'
git branch -d yTask: figure out what was the name of the branch that commit y came from. Yes, any tool will tell you that it came from some branch merge, but which one?

Mercurial takes care of that, fossil presumably too. I would still use git.

"figure out what was the name of the branch"

Of what possible relevance is that? The name can be changed at any time. Hell -- I can make some chained commits and then merge them without ever making a named branch.

It's the contents of the commits that matter.

[PlainName]

It's the contents of the commits that matter.

To a point. Knowing that the commit fixes some specific bug or implements some specific feature is perhaps as important when going through history. You might be trying to determine if this version has that fix, and knowing that some weirdo code has changed to some other weirdo form doesn't help that along much.

[PlainName]

I just use Sourcetree

Any idea why you need an account at Atlassian to use Sourcetree? Can they decide not to let you use it (and stop it working), get telemetry or whatever from it? Do you have to be online for it to work?

[DiTBho]

even mercurial has interesting dependencies
- chg -> support mercurial command server/client (is it mandatory?!?)
- emacs
- gpg (why?!?)
- tk (for what ?!?)
- zsh-completion
- python (for what?!?)

this is also interesting:

If you want to convert repositories from other tools using convert extension please install correct tool
- cvs
- darcs
- git
- monotone
- subversion

darcs?!? monotone?!? never heard about

[voltsandjolts]

Any idea why you need an account at Atlassian to use Sourcetree?

Atlassian own Sourcetree and they provide it free of charge, but they would like you to use their services (bitbucket), so it's their way of pulling you in.
After initial setup you are free to use any repo service or your own.
Bitbucket service works fine but the web interface isn't nearly as good as github.

Can they decide not to let you use it (and stop it working), get telemetry or whatever from it?

Probably. Maybe they could lock it to bitbucket someday, if they were willing to piss off customers. Regards telemetry, I don't know.

Do you have to be online for it to work?

No

[PlainName]

Thanks

Shit program, though. Installs to Appdata without asking or warning, and when uninstalled doesn't actually remove any of the shit that it's filled the system with.

[Inhibit]

That topic got deep, fast .

I'll toss my opinion in the ring for Git as a simple backup-of-my-work repository. Once you've created a new Git repo all you'll be doing is commit of the current branch to the repo for backup purposes.

Although you probably want to verify you're using the correct commands it's really only a single one to back up the entire working directory to the repository you've created. And then a single command should you ever need to restore that (current version) backup to a different system.

Just use it as a simple fire-and-forget backup that could possibly be automated. For which Git (in my opinion and similar use case) works brilliantly. You'll get the versioning added for no additional effort.

You can always figure out reverting to Mondays commit later if it ever comes up as desirable.

And if you want *really* simple, rsync to a datestamped directory on some backup medium, local network, or cloud service. No inherent versioning but it doesn't get much simpler.

[PlainName]

If you use git like that, why not just use zips and a backup folder?