GIT Time again - what am I missing?
-
I'm just trying to understand the FUD pushing git. Where does your source code live?
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
The source code lives on remote servers and locally - we have local repositories we work from and we then push to, pull from, fetch from, merge to the Git remote server repositories. We clone from the remote repositories to local repositories and work on the local repositories.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
The source code lives on remote servers and locally - we have local repositories we work from and we then push to, pull from, fetch from, merge to the Git remote server repositories. We clone from the remote repositories to local repositories and work on the local repositories.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
see my last comment - I think I see the big difference between GIT and SVN. GIT allows *all* work locally and then will put it back together on the backend, where that might be.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
see my last comment - I think I see the big difference between GIT and SVN. GIT allows *all* work locally and then will put it back together on the backend, where that might be.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
When we were using SVN, I still have it on my local machine, we could do all the work locally too. Perhaps an advantage of Git, which I missed is the concept of the PR (Pull Request). With SVN we were able to commit to trunk without any sort of approval. So I could get changes through to production without anyone else seeing the changes. With Git nothing get's merged into Main unless it has been code reviewed and the PR has been approved. This is a really useful safety net meaning at least one other person has looked at our changes before they are allowed to be merged into Main/Trunk.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
So, as a side project, I've been delving into the git source control world (triggered by Visual Studio incorporating it), and I'm smelling something nasty. As in, what's the point, other than preference? I've insisted all of my development projects be in source control since the mid 80s. Back then, we were heavily developing on VMS, the version control system was CMS. I'm not sure back then we had the concept of branches and what not, but we could tag the code base for a specific release. I ran into one developer who kept his changes as file versions - it's a VMS thing. All it took was one purge command to lose ALL of the history.. shudder. Anyway.... So in the years to follow, I've motored through PVCS, ClearCase (shudder), VSS and SVN. After VSS burned me badly (there are many unflattering stories out there) due to a network outage, I transitioned all of my source control to svn. Supports concurrent development, tags, branches and merging and is far more robust than VSS. This would be about 15 years ago or so. Along comes this git upstart. And all of the comparisons between it and svn generally say git is better for concurrent development, blah blah blah. Oh and it's a distributed model. And it allows for branching, etc. Just like SVN. Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me. Appreciate your thoughts.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
I am not a big fan of Git but that's what we use. I guess the good news is GitHub is not the sole provider of the service - there are others such as BitBucket which what we use and it integrates with VisualStudio reasonably well.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
-
In the past year or so, at work, we moved to Git from SVN for all of our work. Is it better? I can't see anything that it does better than SVN. Is it worse? I can't see anything that it does worse than SVN. Why use it? Github has some nice features, although I will admit that I actually found it easier to navigate the commit history through TortoiseSVN, but I think that's partly a learning process for me and the Github UI is very poorly designed in places. So if you like SVN stick with it, but it's always useful to have some experience of something like Git so that you can understand what other people are talking about when they mention "pull requests" etc.(another poorly named feature in Git)
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
SourceTree (if it's still around) had a pretty nice and buttony UI. Web Git is maybe also a bit different than Azure DevOps on-prem Git. Not sure. But ADO traversal of history (or VS) works pretty decent depending on what you're after. May need a VS extension, I can't recall if it's built-in or not.
-
"Old crusty people refuse change and to continue learning." Now be nice. :). You also seem to be a bit bitchy this morning. There was no intent to start a cat fight. My question was serious, as all of the articles extolling the virtues of GIT vs. SVN leave me picking my nose and pondering their argument. Old crusty people tend to run development groups and what not, so before fragging the dev process, there needs be justification. My post was not a GIT sucks question - I actually have only tinkered with it. Since VS2*** has buried it into the menus and behavior, I thought I might learn something.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
You also seem to be a bit bitchy this morning. There was no intent to start a cat fight.
:laugh: :laugh: :laugh: You're right, I swear it wasn't you or your post. I'm just holding on to crap from a ton of bad experiences on CP.
Jeremy Falcon
-
It's not quite the same. Changes are stored as deltas locally with GIT. So, everything you have is local. The central server is the accumulation point of these deltas. Now try the second part of what I said - undo a history item, and then rebuild any check in from that point. GIT makes this relatively trivial.
-
Jeremy - this smells like a branch? I'm just not seeing the difference other than git renaming basic source code control concepts. Wait, see my post at the end of the comment section... I think I might have had an epiphany. Might be gas though.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
Jeremy - this smells like a branch?
Talking about working with history. That's not the same thing as a branch. What happens if history gets messed up after a branch is merged for instance?
charlieg wrote:
Wait, see my post at the end of the comment section... I think I might have had an epiphany. Might be gas though.
Me go check it out...
Jeremy Falcon
-
RickZeeland wrote:
We are very pleased with Git, after going through a painful learning curve of course
And that's the real reason you find some people reject it... they don't want to learn.
Jeremy Falcon
-
charlieg wrote:
You also seem to be a bit bitchy this morning. There was no intent to start a cat fight.
:laugh: :laugh: :laugh: You're right, I swear it wasn't you or your post. I'm just holding on to crap from a ton of bad experiences on CP.
Jeremy Falcon
upvoted. All I care about is source control and the release process. Trying to understand the next great thing.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
charlieg wrote:
Jeremy - this smells like a branch?
Talking about working with history. That's not the same thing as a branch. What happens if history gets messed up after a branch is merged for instance?
charlieg wrote:
Wait, see my post at the end of the comment section... I think I might have had an epiphany. Might be gas though.
Me go check it out...
Jeremy Falcon
-
I am not a big fan of Git but that's what we use. I guess the good news is GitHub is not the sole provider of the service - there are others such as BitBucket which what we use and it integrates with VisualStudio reasonably well.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
See that's the other thing. I would NEVER have company code out on GitHub. Source code is the Crown Jewels and the jewels stay on the premises. I do know you can set up your own server locally, or I think I read about that.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
So, as a side project, I've been delving into the git source control world (triggered by Visual Studio incorporating it), and I'm smelling something nasty. As in, what's the point, other than preference? I've insisted all of my development projects be in source control since the mid 80s. Back then, we were heavily developing on VMS, the version control system was CMS. I'm not sure back then we had the concept of branches and what not, but we could tag the code base for a specific release. I ran into one developer who kept his changes as file versions - it's a VMS thing. All it took was one purge command to lose ALL of the history.. shudder. Anyway.... So in the years to follow, I've motored through PVCS, ClearCase (shudder), VSS and SVN. After VSS burned me badly (there are many unflattering stories out there) due to a network outage, I transitioned all of my source control to svn. Supports concurrent development, tags, branches and merging and is far more robust than VSS. This would be about 15 years ago or so. Along comes this git upstart. And all of the comparisons between it and svn generally say git is better for concurrent development, blah blah blah. Oh and it's a distributed model. And it allows for branching, etc. Just like SVN. Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not. I nod to preferences, but can anyone provide real world examples of how git solved a version control problem better than svn? The most common "feature" articles say about git is some mumbling about not needing a central repo which makes no sense to me. Appreciate your thoughts.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not
The origination of GIT was specifically aimed at online open source projects. Git - A Short History of Git[^] The only significant problem I have encountered with git is that it does not work well with Enterprise development. In an ideal Enterprise world one would have the following - Strict boundary breakdowns - Teams working on libraries - Applications using libraries by version For git the above works well because a library is then just a repo. And a deliverable. However that ideal is not what happens. Even modestly sized business multiple applications (product or service is still an application) are a norm. With SVN that works as follows. - library code goes into its own folder tree - Apps each go into their own folder - An app folder and associated folders is labeled for a build. The means that the library code moves forward but it is labeled independently for each app. It is NOT possible to do the above with GIT. There is one label for the entire repo. So one often ends up with a mix of idioms. Perhaps one library in its own repo. But other libraries might be copied. Or two or more apps end up in the same repo. And a repo explosion without tracking can also occur. Where one offs end up in their own repo. With SVN it would just go in a new folder. Of course people will complain that that last case is a problem. So it is. But creating new GIT repos every single time without any coherent tracking is also a problem. (I have seen developers create repos just to experiment and then the repo gets abandoned.) --------------------------------------------------------- As for losing source control due to problems with a specific source control solution ... Long ago losing databases was also a problem. Forums would always have someone asking how to restore corrupted databases. That was true for every database vendor. I haven't seen anything like that for years. But also true that now people always back up their databases. Source control is NOT a back up. But many places treat it has such. Even now.
-
Okay, based on Jeremy's and other comments, I think I may be close to understanding what GIT does better than SVN or any other centralized server system... When a developer wants to do work, they pull a working copy. It's local to their machine. All of their work - commits and what not occur to the local copy. The changes do NOT go back to the repo until they push. When they push, the code changes, the history, etc go with the push. Do I have this correct? Going to go read some GIT doc.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
Do I have this correct? Going to go read some GIT doc.
You are 100% correct.
Jeremy Falcon
-
Okay, based on Jeremy's and other comments, I think I may be close to understanding what GIT does better than SVN or any other centralized server system... When a developer wants to do work, they pull a working copy. It's local to their machine. All of their work - commits and what not occur to the local copy. The changes do NOT go back to the repo until they push. When they push, the code changes, the history, etc go with the push. Do I have this correct? Going to go read some GIT doc.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
charlieg wrote:
The changes do NOT go back to the repo until they push.
Oh, I'd also add to that, that in git-land, to help untrusted code not make its way into the mainline and since merges happen like crazy (a good thing), a pull request is a common thing. So, if someone pushes a change to a remote repo, you could set it up to require a code review. You can technically do this in SVN-land, it's just more of a pain to pull off.
Jeremy Falcon
-
charlieg wrote:
Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not
The origination of GIT was specifically aimed at online open source projects. Git - A Short History of Git[^] The only significant problem I have encountered with git is that it does not work well with Enterprise development. In an ideal Enterprise world one would have the following - Strict boundary breakdowns - Teams working on libraries - Applications using libraries by version For git the above works well because a library is then just a repo. And a deliverable. However that ideal is not what happens. Even modestly sized business multiple applications (product or service is still an application) are a norm. With SVN that works as follows. - library code goes into its own folder tree - Apps each go into their own folder - An app folder and associated folders is labeled for a build. The means that the library code moves forward but it is labeled independently for each app. It is NOT possible to do the above with GIT. There is one label for the entire repo. So one often ends up with a mix of idioms. Perhaps one library in its own repo. But other libraries might be copied. Or two or more apps end up in the same repo. And a repo explosion without tracking can also occur. Where one offs end up in their own repo. With SVN it would just go in a new folder. Of course people will complain that that last case is a problem. So it is. But creating new GIT repos every single time without any coherent tracking is also a problem. (I have seen developers create repos just to experiment and then the repo gets abandoned.) --------------------------------------------------------- As for losing source control due to problems with a specific source control solution ... Long ago losing databases was also a problem. Forums would always have someone asking how to restore corrupted databases. That was true for every database vendor. I haven't seen anything like that for years. But also true that now people always back up their databases. Source control is NOT a back up. But many places treat it has such. Even now.
-
charlieg wrote:
Exactly what am I missing? I simply do not see anything significant git brings to the table that svn does not
The origination of GIT was specifically aimed at online open source projects. Git - A Short History of Git[^] The only significant problem I have encountered with git is that it does not work well with Enterprise development. In an ideal Enterprise world one would have the following - Strict boundary breakdowns - Teams working on libraries - Applications using libraries by version For git the above works well because a library is then just a repo. And a deliverable. However that ideal is not what happens. Even modestly sized business multiple applications (product or service is still an application) are a norm. With SVN that works as follows. - library code goes into its own folder tree - Apps each go into their own folder - An app folder and associated folders is labeled for a build. The means that the library code moves forward but it is labeled independently for each app. It is NOT possible to do the above with GIT. There is one label for the entire repo. So one often ends up with a mix of idioms. Perhaps one library in its own repo. But other libraries might be copied. Or two or more apps end up in the same repo. And a repo explosion without tracking can also occur. Where one offs end up in their own repo. With SVN it would just go in a new folder. Of course people will complain that that last case is a problem. So it is. But creating new GIT repos every single time without any coherent tracking is also a problem. (I have seen developers create repos just to experiment and then the repo gets abandoned.) --------------------------------------------------------- As for losing source control due to problems with a specific source control solution ... Long ago losing databases was also a problem. Forums would always have someone asking how to restore corrupted databases. That was true for every database vendor. I haven't seen anything like that for years. But also true that now people always back up their databases. Source control is NOT a back up. But many places treat it has such. Even now.
"source control is not a backup" true words. But I have it on IT's assurance that they are imaging the VM server hosting our code. Years ago, I submitted an IT ticket to verify our backups. This created a tornado of panic. What do you mean the backup is bad? No, I asked you how do you know it's good. As for your other comments about libraries and common code bases, well I gave up on that 10 years ago. ctrl-c/ctrl-v is our inheritance process :(. I'll admit that we're a very embedded product oriented shop, but I'd still like to see common code isolated to one area. Like I do, but I lost that battle long ago.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
-
See that's the other thing. I would NEVER have company code out on GitHub. Source code is the Crown Jewels and the jewels stay on the premises. I do know you can set up your own server locally, or I think I read about that.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
GitHub does allow for private repos btw. If that's the concern. I mean, the code is still on their servers though, but at least it can be marked as private if desired.
Jeremy Falcon
-
See that's the other thing. I would NEVER have company code out on GitHub. Source code is the Crown Jewels and the jewels stay on the premises. I do know you can set up your own server locally, or I think I read about that.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.
Github is not just public repositories, it makes most of its money by hosting private repositories. You can use other services like Azure or Bitbucket. Or even self host.
CI/CD = Continuous Impediment/Continuous Despair
-
Github is not just public repositories, it makes most of its money by hosting private repositories. You can use other services like Azure or Bitbucket. Or even self host.
CI/CD = Continuous Impediment/Continuous Despair
sorry. Microsoft bought GitHub in 2018. Microsoft is the "most public" fluster cluck of security that I can even imagine, not that they are alone. I'd not trust HP nor Amazon with the Crown Jewels. I want that one person or small group in my company understanding they are not going to lose a contract, they are going to be summarily terminated for not doing their job. It's down toward the bottom of the list to research - offsite GitHub repositories, but every fiber of my being says no. If I could put a private GitHub repo behind my firewall and on my network - fine. Companies hosting this out in "the cloud" are out of their elephanting mind.
Charlie Gilley “They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759 Has never been more appropriate.