-
I've considered it several times. The only reason I use git is because it's required to access third-party code, so it's not like I am trying to gain git features without the pain of it being git.
You can use git for accessing code that's on git, and use something else for your own projects.Mercurial doesn't have good penetration, so where some product offers built-in source control it will be typically subversion and now git, but not Mercurial.
Never had a problem with that.Usually that wouldn't bother me because I rarely use the built-in stuff anyway,
Ditto.but it's an indicator of industry support and I've been bitten previously by jumping ship to something that gets binned shortly afterwards.
I understand the point, but I don't subscribe to it.
First thing is, don't worry too much about the tool being binned. Mercurial has been around for (slightly) longer than git actually, and is still actively maintained. As it's used by a few big organizations (such as Mozilla), I doubt it will get abandoned any time soon.
Anyway, do as you wish - I'm not evangelizing - just suggesting something that has worked for me quite well and that I think is worth considering, rather than sticking to something like git that may be popular but (as a few of you also said) has a number of flaws that can make it annoying to use, or even a nightmare in some cases. Sometimes popularity doesn't imply quality.
To add to the oddities of git, something annoying I have noticed (please tell if that happens to you as well): like you, I use it occasionally to pull third-party code. Every once in a while, a "git pull" will result in conflicts (that you have no idea about) whereas you have modified absolutely NOTHING in your local repo. It's fucking annoying, and looks like the tool sometimes can't even agree with itself. Anyway.
-
Thanks for the advice, but...
Quotegit submodule update
That would update the submodule to the current version at the origin, wouldn't it? I just want a copy of what I have right here on my disk, not change it for something I haven't tested yet
Having a reasonable number of submodules for truly independent things with well-defined and stable interfaces between them works perfectly reasonably. You just have a master repo for each submodule -- which can be the local bare repo you made, but one for each submodule -- and then just step into each submodule and push it. You can copy the commands needed into a little script, if you want.
See for example something like https://github.com/riscv/riscv-gnu-toolchain which is a repo that consists almost completely of seven major submodules. In my experience it works fine.
Some projects do go overboard with submodules. One I love to hate is Android, which has dozens and dozens of git submodules. At least they wrote a tool ("repo") to help with this, but it's still a pain.
It sounds as if whoever set up your software similarly went overboard with submodules.
Maybe repo would help you: https://gerrit.googlesource.com/git-repo/
-
Herein lies the problem with git, it's fragile and the slightest missed step or misconfiguration when you're trying to actually use features can tear the whole house of cards down.
I don't find that to be true at all.
git uses some different concepts to other version control software but it is very simple at heart and it's well worth making a little bit of effort to understand the main points of the structure.
I've never come across a git bug that loses data in a repo. The 100% always reason for loss of data is user error, especially user error in copying and pasting commands that use the "force" option from some well-intentioned colleague or internet site. Don't do that!
Sadly, many of the git commands have grown a lot of obscure options over the years. It's almost never necessary to use them or learn them. You can accomplish exactly the same thing using a short sequence of much simpler commands, each of which you *do* understand.
Don't expect to find a canned solution for every situation. git is a version control toolkit for use by programmers. It is not and never will be a 100% finished and highly polished walled garden of version control.
-
Herein lies the problem with git, it's fragile and the slightest missed step or misconfiguration when you're trying to actually use features can tear the whole house of cards down.
I don't find that to be true at all.
git uses some different concepts to other version control software but it is very simple at heart and it's well worth making a little bit of effort to understand the main points of the structure.
I've never come across a git bug that loses data in a repo. The 100% always reason for loss of data is user error, especially user error in copying and pasting commands that use the "force" option from some well-intentioned colleague or internet site. Don't do that!
Sadly, many of the git commands have grown a lot of obscure options over the years. It's almost never necessary to use them or learn them. You can accomplish exactly the same thing using a short sequence of much simpler commands, each of which you *do* understand.
Don't expect to find a canned solution for every situation. git is a version control toolkit for use by programmers. It is not and never will be a 100% finished and highly polished walled garden of version control.
No, git is a version control toolkit for Linus Torvalds. I've seen it blow up in lots of people's faces. The claim that git has never lost data due to a bug is probably true, but only strictly true. As you point out git will happily trash your universe if you ask it to, and it makes it so easy to ask it to. The very fact that you have to use a series of hard to remember commands and options to accomplish what ought to be smooth and simple is what damns git - e.g.You realise that what you have just committed and pushed needs one little change that you forgot, or you realise that there's a typo in the commit message for something you've just committed and pushed, and in either case you want to fix the problem quickly before some poor sod pulls what you've just screwed up. Check BD139's reference to ohshitgit.com for all the common use cases that would have been designed into a well crafted version control system.
Your last paragraph, frankly, just comes over as patronising. There was us thinking that it was a version control system for kindergarden teachers, silly us. -
As you point out git will happily trash your universe if you ask it to, and it makes it so easy to ask it to.
If I was the boss of git I would remove all --force options. Sadly I'm not, but I can and do strongly recommend that you don't *use* them -- and certainly not on a repo that other people have access to.QuoteThe very fact that you have to use a series of hard to remember commands and options to accomplish what ought to be smooth and simple is what damns git
My point, which I stand by, is that a series of easy to remember and understand commands is sufficient.Quotee.g.You realise that what you have just committed and pushed needs one little change that you forgot, or you realise that there's a typo in the commit message for something you've just committed and pushed, and in either case you want to fix the problem quickly before some poor sod pulls what you've just screwed up.
Stop right there.
You're right. You've screwed up. Git is designed to be (and is) a faithful and non-forgeable record of the history of a project, mistakes and bugs and all.
Pushing a spur of the moment change to the master branch of a public repo without reflection, testing, and preferably review is more than somewhat unprofessional.
Force pushing a fix to pretend it never happened is simply terrorism.
Even if it is only 30 seconds, on a busy project someone else may already have pulled, and then your force-push screws them *totally*. Just don't do it. Own your screw up and push the fix on top of it.
Blaming the situation on git is like mashing the accelerator of your Camry all the way to the floor and leaving it there and then blaming Toyota for the ensuing crash.
There is logically no smooth and simple and invisible recovery from this situation in a public repo. Other revision control systems such as svn don't let you even pretend there is. As I said, git should arguably not have the force option available on commands, and certainly not on push. We can't change that now, but we *can* tell people DON'T USE IT.
If you don't want to have careless screw-ups and subsequent fixes in the public permanent record then don't put them there. Git has plenty of mechanisms to help you avoid them, such as local and public feature branches and reordering and combining commits as you copy them from one branch to another, and then finally merging tested a reviewed changes to master.
This is something that git supports a thousand times better than svn or cvs or others.
-
Blaming the situation on git is like mashing the accelerator of your Camry all the way to the floor and leaving it there and then blaming Toyota for the ensuing crash.
That's "very open source of you" to point out.
I prefer the analogy of an American car. It's fine if you drive it in a straight line. But the moment you get to an unexpected corner it tumbles off the road, catches fire and incinerates the occupants.
As Cerebus says it's designed for Linus. In fact it actually works pretty well for the kernel team set of use cases and working model. But the thing is absolutely no one uses it like that at all. They use it like SVN centralised on github. On top of that there are several workflow cargo cults such as gitflow who managed to attract a lot of the perhaps all too usual fashion victims in the software sector.
This leads to several terrible outcomes on a regular basis especially when you have medium sized teams. For reference, this is the scale of our world of hell. There are at least 5 people completely broken 100% of the time.
-
Quote
e.g.You realise that what you have just committed and pushed needs one little change that you forgot, or you realise that there's a typo in the commit message for something you've just committed and pushed, and in either case you want to fix the problem quickly before some poor sod pulls what you've just screwed up.
Stop right there.
You're right. You've screwed up. Git is designed to be (and is) a faithful and non-forgeable record of the history of a project, mistakes and bugs and all.
Pushing a spur of the moment change to the master branch of a public repo without reflection, testing, and preferably review is more than somewhat unprofessional.
Force pushing a fix to pretend it never happened is simply terrorism.
Even if it is only 30 seconds, on a busy project someone else may already have pulled, and then your force-push screws them *totally*. Just don't do it. Own your screw up and push the fix on top of it.
Blaming the situation on git is like mashing the accelerator of your Camry all the way to the floor and leaving it there and then blaming Toyota for the ensuing crash.
There is logically no smooth and simple and invisible recovery from this situation in a public repo. Other revision control systems such as svn don't let you even pretend there is. As I said, git should arguably not have the force option available on commands, and certainly not on push. We can't change that now, but we *can* tell people DON'T USE IT.
If you don't want to have careless screw-ups and subsequent fixes in the public permanent record then don't put them there. Git has plenty of mechanisms to help you avoid them, such as local and public feature branches and reordering and combining commits as you copy them from one branch to another, and then finally merging tested a reviewed changes to master.
This is something that git supports a thousand times better than svn or cvs or others.
You might work with superhumans all the time who never, ever make mistakes. Sadly I have been cursed with working with mere morals who do make mistakes, myself included. Tools ought to be designed for people. No doubt you've ripped out the seatbelts and airbags from your car because, if you know how to drive properly, they are options needed only for the skill disadvantaged and you're clearly, at least in your own opinion, not one of those.QuoteForce pushing a fix to pretend it never happened is simply terrorism.
Hyperbole anyone? -
You might work with superhumans all the time who never, ever make mistakes. Sadly I have been cursed with working with mere morals who do make mistakes, myself included. Tools ought to be designed for people. No doubt you've ripped out the seatbelts and airbags from your car because, if you know how to drive properly, they are options needed only for the skill disadvantaged and you're clearly, at least in your own opinion, not one of those.
I'm not sure why you consistently misunderstand or misrepresent what I'm saying.
I'm not superhuman and neither are the people I work with. We all make mistakes all the time. We use a workflow that enables the vast majority of those mistakes to be found and corrected *before* they enter the permanent record.
That workflow uses temporary branches, one for each attempt at getting it right, and merging them into the main branch only when no obvious errors remain.
Git makes that workflow easy and pleasant. SVN and other systems in general do not. As has been remarked by others "SVN supports branching — it doesn't support merging"
-
SVN merge
I'll grant you that it's not as sophisticated as git merge, but it works. The only issues I have with it (and the main reason I don't often use it) is the resolve function. Battling that can be almost as dense as git sometimes.
Merging on git isn't that intuitive, either. I seem to end up merging the branch into the trunk and then the trunk back into the branch, otherwise the pretty graph remains open-ended.
-
You might work with superhumans all the time who never, ever make mistakes. Sadly I have been cursed with working with mere morals who do make mistakes, myself included. Tools ought to be designed for people. No doubt you've ripped out the seatbelts and airbags from your car because, if you know how to drive properly, they are options needed only for the skill disadvantaged and you're clearly, at least in your own opinion, not one of those.
I'm not sure why you consistently misunderstand or misrepresent what I'm saying.
I don't, you just choose to see it as that because I, and others, disagree with you as to how wonderful git is, or is not, and get increasingly patronising and belittling with every reply - such as lecturing us as to the very basics of how git works.
It's quite clear that you're a git fanboy, nobody but a fanboy would have said "Git makes that workflow easy and pleasant" who had dealt with it at any scale at all. In fact the phrase "Git makes that workflow easy and pleasant" will, I'm sure, have elicited a cynical laugh out of more than one reader. There's little mileage in trying to debate the issues with a "true believer".
-
a workflow that enables the vast majority of those mistakes to be found and corrected *before* they enter the permanent record.
That workflow uses temporary branches, one for each attempt at getting it right, and merging them into the main branch only when no obvious errors remain.
Can you make a practical example? This sounds very interesting. -
Also don't forget about hiding all the errors people make and the audit trail with rebase!
-
You might work with superhumans all the time who never, ever make mistakes. Sadly I have been cursed with working with mere morals who do make mistakes, myself included. Tools ought to be designed for people. No doubt you've ripped out the seatbelts and airbags from your car because, if you know how to drive properly, they are options needed only for the skill disadvantaged and you're clearly, at least in your own opinion, not one of those.
I'm not sure why you consistently misunderstand or misrepresent what I'm saying.
I don't, you just choose to see it as that because I, and others, disagree with you as to how wonderful git is, or is not, and get increasingly patronising and belittling with every reply - such as lecturing us as to the very basics of how git works.
It's quite clear that you're a git fanboy, nobody but a fanboy would have said "Git makes that workflow easy and pleasant" who had dealt with it at any scale at all. In fact the phrase "Git makes that workflow easy and pleasant" will, I'm sure, have elicited a cynical laugh out of more than one reader. There's little mileage in trying to debate the issues with a "true believer".
Good grief, you really see the world as black and white!
I doubt that I could even reliably list all the version control systems I've used for real paying work. But let's try. SCCS, RCS, CVS, SVN, PVCS, Visual SourceSafe, MPW Projector, ClearCase, Perforce, Mercurial, git.
I resisted git for ages in the late 00's as Mercurial especially seemed to do everything about as well and some things better. But there is no getting around the fact that git won in mindshare and widespread support, so I eventually capitulated.
It will surprise me if I'm using git forever. Something will eventually be both better and gain critical mass. It may even exist now. Git is certainly not without its faults, and I've even mentioned some in this thread -- for example the existence of "force" options and much advice and examples on the net encouraging people to use it. Also the inability to commit empty directories is often infuriating. Support for non-diffable files (especially large ones) could be better. Support for transparently handling compressed files with diffing (i.e. unzip then, compare and diff the expanded versions, compress the differences) would be nice. Standard incorporation of tools for better reconciling long diverged branches is much needed — I couldn't live without Michael Haggerty's git-imerge.
It's an imperfect but extremely useful tool, and not nearly as bad as you make out.
-
a workflow that enables the vast majority of those mistakes to be found and corrected *before* they enter the permanent record.
That workflow uses temporary branches, one for each attempt at getting it right, and merging them into the main branch only when no obvious errors remain.
Can you make a practical example? This sounds very interesting.
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow
-
I resisted git for ages in the late 00's as Mercurial especially seemed to do everything about as well and some things better. But there is no getting around the fact that git won in mindshare and widespread support, so I eventually capitulated.
It will surprise me if I'm using git forever. Something will eventually be both better and gain critical mass. It may even exist now. Git is certainly not without its faults, and I've even mentioned some in this thread -- for example the existence of "force" options and much advice and examples on the net encouraging people to use it. Also the inability to commit empty directories is often infuriating. Support for non-diffable files (especially large ones) could be better. Support for transparently handling compressed files with diffing (i.e. unzip then, compare and diff the expanded versions, compress the differences) would be nice. Standard incorporation of tools for better reconciling long diverged branches is much needed — I couldn't live without Michael Haggerty's git-imerge.
It's an imperfect but extremely useful tool, and not nearly as bad as you make out.
That actually sounds reasonable. Why then previously go off the deep end and start talking about terrorism and indulging in other hyperbole? Git is fragile, it's a horror to use, it has too many confusing options, too many dangerous options (e.g. -force), too many ways to do essentially the same thing in subtly different ways and it is way too easy for the average user to get themselves in a horrible mess, horribly quickly. I have seen the later borne out in practice dozens of times in the real world and lost track of the time I've seen wasted getting a git repo back into a sane state just because somebody made a dumb mistake or by picking 'not quite the right set of options'. Just because it doesn't corrupt the repository itself doesn't make it not fragile. It was designed around a pull model, but is used almost everywhere but by the originators in push mode. Mercurial is an oasis of calm in comparison. You've pretty much admitted you use git "because everybody else does" which at school would have elicited the response from a teacher of "Would you jump off a cliff if 'everybody else did it'?". For me git is the version control system of choice when I have no choice (i.e. I've walked into a situation where it is already in use and mandated). In its favour is it's very fast and very flexible (overly flexible).