GIT Time again - what am I missing?
-
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 personally felt that branching and merging, accompanied with reviews in one toolset like git hub is way better than SVN. But to be honest, I haven't looked into SVN for at least 6 years and even back then i did all relevant things with JetBrains tools, so i only have to use SVN to push and pull code.
MessageBox.Show(!string.IsNullOrWhiteSpace(_signature)
? $"This is my signature:{Environment.NewLine}{_signature}": "404-Signature not found"); -
I don't think we ever had issue with that with SVN and local copies, but it may be that I am not understanding you and that you know this is not possible with SVN.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
Keep in mind, I haven't used SVN in years. Maybe things change... But, what SVN stores locally and what Git stores locally are not the same thing. SVN is more akin to metadata (over simplification of course) whereas Git stores the actual - same exact thing - repo. There's zero difference. It's all local. Which is to say, if I need to completely update/rewrite history locally, or do whatever, I can make sure remotely will have the same exact changes (with no extra commits, etc.). It's been my experience that in SVN land, working with history is not a concept peeps care about, just make a new commit and who cares what history looks like. But, when working in a team, where some dev screws something up, it's nice to be able to clean things up when you need it. And IMO having a clean history is nice if you ever need to do any code investigation. So, do you have need to worry about it often? Nope. I hope not. :laugh: But, it's nice to have when you do need it.
Jeremy Falcon
-
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.
Branching is much easier, it does not create any additional directory since it is a pointer to a specific commit. The way branches are managed make following the timeline of modifications a lot easier for merging purposes. We used it for an ECU with a main codeline + different features to be added + different parts of the code to be ported to another OS + different stages of development for every customer. Managing that amount of branches with GIT is easier. EG tyipical workflow in GIT was: * branch from current main or current stable (first thing I do before touching the code) * get a feature to develop from Jira / Polarion / Redmine * Start developing the feature * [...] Several commits and pushes * Eventual side-branches for different potential solutions / potentially breaking code changes * Commit "working solution" * Pull request to Integration * Branch from current main or current stable * Get another feature to develop * Repeat as necessary. Integration will then merge all open branches in the new main or stable line and stop + reject PR if some branch causes failures to compile, otherwise regression tests and validations are peformed and main or stable is advanced. Now everything shall start from main again. For one developer it's useless, for 4 developers in the same office it's overkill, for 300 developers across the world it's sanity. Nothing ever gets removed from GIT, ever (unless some idiot with permissions forces it) so a stable, working commit is always reachable. One thing I loved about git was that it doesn't need a server, any file-system works, so when I worked for B***h I actually cloned the repo on my network, worked locally from my PC to the local repo then send only the vetted commits to the company repo. It allowed me a lot of flexibility, mostly that of using my own computer to edit the code while I would have been mandated to use only their horrible workstation with only a handful of useless programs (writing code in Keil is painful). In my current company we use SVN, we are literally 5 developers in a office and SVN is also used as a shared storage for documentation and stuff that should not be there. Many systems in the company refer to that SVN so we won't change - except that we can only have a total of 20 users otherwise we'd have to change license for the SVN server and we actually are at capacity since there are (stupidly) other people accessing that repository, and we can't have more than one repo due to licensing. Any serious company still uses some
-
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
With the right GUI it's easy. I love SmartGit for daily operation and Sourcetree for the amazing log viewer.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
-
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
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.
-
With the right GUI it's easy. I love SmartGit for daily operation and Sourcetree for the amazing log viewer.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X The shortest horror story: On Error Resume Next
Not to mention, I remember using TortoiseSVN back in the day. Its repo viewer was slow. But, then again, it had to make remote calls for everything.
Jeremy Falcon
-
Keep in mind, I haven't used SVN in years. Maybe things change... But, what SVN stores locally and what Git stores locally are not the same thing. SVN is more akin to metadata (over simplification of course) whereas Git stores the actual - same exact thing - repo. There's zero difference. It's all local. Which is to say, if I need to completely update/rewrite history locally, or do whatever, I can make sure remotely will have the same exact changes (with no extra commits, etc.). It's been my experience that in SVN land, working with history is not a concept peeps care about, just make a new commit and who cares what history looks like. But, when working in a team, where some dev screws something up, it's nice to be able to clean things up when you need it. And IMO having a clean history is nice if you ever need to do any code investigation. So, do you have need to worry about it often? Nope. I hope not. :laugh: But, it's nice to have when you do need it.
Jeremy Falcon
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:
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.
I say this as a dude who used SVN for years... 1. Git is awesome. 2. Old crusty people refuse change and to continue learning. 3. People need to embrace distributed concepts if they want to belong to the future. Now, as far as why you care today, as in right now. This is really a conversation between centralized vs distributed. You can replace SVN with anything centralized. 1. Unlike with SVN, you can be 100% offline and still commit code you work on. Yeah sure, you can set up a local SVN server on your home network, but let's be real. This mean, if you commute to work on a train, you can code away and make commits. Then push them to a remote later on. If you never go outside, less of an issue I guess. 3. Run queries and searches against your entire repo's history, locally and quickly. 4. Run hooks to gate/guard your code *before* it ever hits the real repository. Yeah sure, you can have staging/feature branches in both Git and SVN, but with SVN it's still in the remote repo. 5. Under the hood, git diffs commits more efficiently. I don't have evidence for this so it's anecdotal. But, from years of using it, it just feels quicker. 6. I haven't used SVN in a while, so maybe this is moot, but with Git you have Git LFS. Google it. 7. You should be making frequent commits to code. SVN is too slow for this. Large commits are terrible for maintenance. Anyone working in a large team knows this. 8. Git is profoundly better at handling branches and deltas than SVN. Granted, I haven't used SVN in years... maybe it's better at it now... maybe. I don't know. Anyone on CP saying keep with SVN, I can promise you still uses jQuery or VB, sans a few. And there are people (except for one, shout out to Ravi) who will argue all day long about how they think they are experts in their choice of version control, but they can't read a post or explain anything simply. Point is, don't trust CP to give you the best info always. Oh, and sorry, if I sound jaded. It's not you or your post, I promise. :laugh: I'm just old and cranky and really tired of having to deal with c
"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.
-
Branching is much easier, it does not create any additional directory since it is a pointer to a specific commit. The way branches are managed make following the timeline of modifications a lot easier for merging purposes. We used it for an ECU with a main codeline + different features to be added + different parts of the code to be ported to another OS + different stages of development for every customer. Managing that amount of branches with GIT is easier. EG tyipical workflow in GIT was: * branch from current main or current stable (first thing I do before touching the code) * get a feature to develop from Jira / Polarion / Redmine * Start developing the feature * [...] Several commits and pushes * Eventual side-branches for different potential solutions / potentially breaking code changes * Commit "working solution" * Pull request to Integration * Branch from current main or current stable * Get another feature to develop * Repeat as necessary. Integration will then merge all open branches in the new main or stable line and stop + reject PR if some branch causes failures to compile, otherwise regression tests and validations are peformed and main or stable is advanced. Now everything shall start from main again. For one developer it's useless, for 4 developers in the same office it's overkill, for 300 developers across the world it's sanity. Nothing ever gets removed from GIT, ever (unless some idiot with permissions forces it) so a stable, working commit is always reachable. One thing I loved about git was that it doesn't need a server, any file-system works, so when I worked for B***h I actually cloned the repo on my network, worked locally from my PC to the local repo then send only the vetted commits to the company repo. It allowed me a lot of flexibility, mostly that of using my own computer to edit the code while I would have been mandated to use only their horrible workstation with only a handful of useless programs (writing code in Keil is painful). In my current company we use SVN, we are literally 5 developers in a office and SVN is also used as a shared storage for documentation and stuff that should not be there. Many systems in the company refer to that SVN so we won't change - except that we can only have a total of 20 users otherwise we'd have to change license for the SVN server and we actually are at capacity since there are (stupidly) other people accessing that repository, and we can't have more than one repo due to licensing. Any serious company still uses some
We do all the branching / dev / commit / merge to integration just fine with SVN. I simply fail to see the superiority of git in this regards. But read my comment to the entire thread.
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.
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.
-
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.