Products > Computers
Perception of Git outside of softdev
golden_labels:
While inspired by EEVblog video, this thread is not about the video. Therefore I put it Computers and not in EEVblog Specific.
In the “LIVE HELP with Github/Gitlab” video(youtube:1) Dave experienced some trouble with using GitHub. For technical reasons I only seen the latter half of it: from about where he stated the line must be drawn. Some weird image emerged from that. An image, which makes me think, how people from outside of the softdev world perceive the topics touched there.
Topic #1
Dave does not himself use Git. Why did someone suggest him to put the project on GitHub? What was the motivation? The goals? To me, as a software developer, this idea sounds absurd. The only thing I could came up with, is the ability to clone or GitHub-fork and maintain the connection with Dave’s version. But I feel this is a far-fetched explanation. The VCS interaction would be almost entirely missing on Dave’s end and, where present, it would require him to put a lot of pointless effort to fit into the workflow. IMO it would be enough to put an archive on eevblog.com and using forum for bug reports and FRs.
Topic #2
There seemed to be confusion between Git and GitHub, and misunderstanding the purpose of GitHub. I felt as if Dave thought GitHub is either a standalone service offering VCS, or even a file hosting service with bells and whitles. In my life I encountered really outlandish views regarding the areas I myself know: both from talking with people, as reported by friends and from reading research. I wonder, how far it goes with Git and, independently of that, with services like GitHub.
(youtube:1)
JohanH:
In the years I've worked with version control software, people outside of software and embedded development are totally ignorant of version control. It's a hard concept and most assume it to be file storage. It's a lack of education, but still, it's mostly used within software. Dave belongs to a generation where version control wasn't mandated by companies he worked for (I assume) and in late 90's and beginning of 2000, version control was very basic. CVS just started to get around and the proprietary systems were expensive (I've experience of two different ones).
Git is a difficult concept even if you come from an older system. The best thing to do is to learn git from scratch. Learn the command line and basic commands. Then they will also understand github and similar online web interfaces.
SiliconWizard:
Already said it, but I find git a bit too complex to use past the very basic stuff, which is straigthforward. But that's nothing unexpected - Linus never expected it to take off as it did, it was mainly for the needs of the Linux kernel maintenance when he designed it.
I personally do recommend Mercurial and that's what I use when I'm not required to use git. Similar, but easier to tame and avoids shooting yourself in the foot.
Certainly something to look at for those looking for an alternative (there are others too.)
But as Johan said, I'm guessing the real question is about using version control in engineering outside of software dev, rather than about a particular tool.
And yes, this is still pretty uncommon, but it's getting there.
Of course one "hurdle" - not a dealbreaker - is that these tools are adapted to pure text. They work perfectly fine with any file format, but any diff or merge will work only on text and so is most adapted to software code. For the rest, it will just be a glorified backup system, and that's probably why it's still not that well perceived outside of software. It's useful, but not game-changing as it has been for software.
DiTBho:
I do prefer Mercurial too, which, talking about u-boot and the Linux kernel, I massively use integrated with my own patch-manager.
--- Code: ---macmini-intel /src/machine/mips/tigra/kernel/6.02.008 # ./mybuild-2023 5
4 - list all files to be patched
5 - apply patches
6 - make patches
7 - revert patches
8 - list all files in the hacked list
9 - generate the hacked list
--- End code ---
Mercurial does all the version control job, and I keep current stuff "in trunk", this way my patch-manager can operate faster, and it's very easy to migrate patches from a kernel to an other: you can comment a patch in a special "note" section, this way the patch manager can check if a patch can be applied to a different project version.
--- Code: ---# lspatch output/generated_patches/my-mm-util-c.patch
mm/util.c.note
mm/util.c
--- End code ---
Mercurial consumes resources, a lot of ram when it's used for a large project like the Linux kernel, so as trick ... Nano has been modified and when you start a new branch and then you start editing stuff, Nano can now take tracks of the original files and the modified ones; this way the patch-manager can automatically generate patches based on diff between original and current.
It consumes only 64Kbyte of ram instead of several tens of Mbyte, and since everything is always under the control of Mercurial, the patch-manager can always query Mercurial to generate the hacked file list.
--- Code: ---macmini-intel /src/machine/mips/tigra/kernel/6.02.008 # ./mybuild-2023 5 8
~ arch/mips/Kconfig
~ init/main.c
~ drivers/net/ethernet/Makefile
+ drivers/crypto/hcry.c
~ mm/util.c
~ net/core/dev.c
~ net/bridge/br_stp.c
--- End code ---
(this consumes a few Kbyte of ram)
--- Code: ---macmini-intel /src/machine/mips/tigra/kernel/6.02.008 # ./mybuild-2023 5 9
### generating ... from Mercurial db
~ arch/mips/Kconfig
~ init/main.c
~ drivers/net/ethernet/Makefile
+ drivers/crypto/hcry.c
~ mm/util.c
~ net/core/dev.c
~ net/bridge/br_stp.c
--- End code ---
(this consumes up to 40Mbyte of ram)
I can do the same with Git, but ...
- Git consumes more resources (especially when it uses external tools, including python)
- Mercurial has less dependencies, and its code is more concise
- Mercurial offers a better interface for my patch-manager
The new version offers a ncurses-based menu, so you select one/more patches to be applied or reverted.
Weird way to operate, I know, but it's very very useful for me when I have to bi-sect/hack a large project with thousand files.
brucehoult:
--- Quote from: JohanH on February 23, 2023, 07:41:17 am ---In the years I've worked with version control software, people outside of software and embedded development are totally ignorant of version control. It's a hard concept and most assume it to be file storage. It's a lack of education, but still, it's mostly used within software. Dave belongs to a generation where version control wasn't mandated by companies he worked for (I assume) and in late 90's and beginning of 2000, version control was very basic. CVS just started to get around and the proprietary systems were expensive (I've experience of two different ones).
--- End quote ---
I'm pretty sure Dave is a good 5 years younger than me. Certainly his first "experience" listed on LinkedIn (1990) is 5 years after I graduated.
CVS was first released to the public in 1986 and was put under the auspices of the FSF in 1990.
I personally didn't have anything at home that could run CVS until I started using Linux around 1997 or 1998. Before that at home I used Apple's "Projector" in MPW, and also from CodeWarrior. At work I was using things such as Visual SourceSafe and PVCS.
I started using cvs in open source projects in 1998, and in a company in 2002.
Companies were switching from cvs to svn in 2003-2006. And then to git in 2006 and on.
I've also used sccs, rcs, Perforce, and probably others my brain has blocked memories of.
I have no idea what they were doing in electrical engineering, but as a 60 year old programmer I can't remember a time after student days that I *wasn't* using version control software.
--- Quote ---Git is a difficult concept even if you come from an older system. The best thing to do is to learn git from scratch. Learn the command line and basic commands. Then they will also understand github and similar online web interfaces.
--- End quote ---
git is *worse* if you come from another system. But git is actually very simple. It's just taught very badly, and by people demonstrating bad practices.
Navigation
[0] Message Index
[#] Next page
Go to full version