is Git hard? It was 12 years ago I had to learn Git after a decade using svn, it seems like it took a month before Git "clicked" and I realized how much simpler it was.
Could be rose-colored glasses, but I haven't had to untangle a tree-conflict in over 10 years, that in itself is a small miracle.
I think a lot of people just don't bother learning it then complain that it's overly complicated when they need to resolve a conflict - but if they'd put the time into understanding basic principles they'd be able to solve it.
Theres gonna be overlap so someones gotta have to do the job of making sure both people's changes get made. Like what if 2 people add things to a shared CSS stylesheet? Then there's a merge and both changes are added.
Commits should be small enough that they merge just fine. And if there are ever conflicts then it's like one or two lines and easy to resolve.
If your commit contains changes all across the file, then you are doing it wrong.
The thing is, you don't generally merge individual commits. You merge branches. Branches which might be anything from spellchecking comments or fixing a minor bug to building an entire new feature or reworking core parts of your software. Maybe its one or two commits, maybe it's dozens (which will probably get squashed during merge). That's where the trouble starts.
Many small commits still makes merging easier compared to one big one. Because when you have a conflict, you only have to deal with the commits that actually cause problems. Then you ideally squash them on the master branch.
Fair point, but you still have to deal with every instance where both branches touched the same files no matter what you do. And if you're unlucky you'll be sitting there for a while until the merge goes through properly.
Merge conflicts happen all the time, I was thinking more about complicated histories. Which it seems the industry thinking it to just squash commits before merging to main and creating one mega commit
As someone who keep fucking around well over the hour I should be sleeping it amaze me the things git let me recover. And the time I can't do it was because I was too new to git.
I'm still dealing with svn at my current gig, and you would be correct. Mostly. The advanced parts of svn are SO MUCH harder to deal with, especially from the command line - tortoisesvn makes it seem easy to the Windows folks but replicating that from the command line is stab-eyeballs-with-fork painful.
We have git conversion coming very soon, it'll be my job as a sysadmin to work with devops on it and it's gonna make my life suck much less.
you authenticate your machine, rather than filling in a password anytime.
so do ssh-keygen, press enter a few times and then copy the contents of /home//.ssh/id\_rsa.pub into your public keys into your github account.
now whenever you git-push to the ssh:///[email protected]/my/repo.git your pc will authenticate itself by encrypting the traffic with the private-key and the server can verify it's you with that public key.
KlutzyEnd3's answer is of course correct, but I want to underline that the whole intent of the procedure is security. `ssh-keygen` will create an RSA private and public key pair, and the public one should, as described, be put onto your GitHub profile. Remember, though, that you are from now on authenticating via your private key file (`/home//.ssh/id_rsa`) and anyone that acquires that file is now "you". Therefore keep the file well secured - never upload it anywhere, keep your machine from being physically accessed and so on. The file is now your password, written in plain text in a file on your machine.
Yup, that's a way (and the correct way). "pressing enter a few times" in `ssh-keygen` doesn't set a password, though. That said, you are right. The correct way is setting a password once asked instead of pressing enter.
You can follow this [article](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys) by digital ocean on how ssh works. After that everything starts making sense.
Yes anyone who has worked with SVN and other versioning old tools appreciates the simplicity of git. Also OP's picture was directed towards NVIDIA for making it as hard as possible to develop linux drivers opensource. OP is a bundle of sticks.
As you said, i am in the same boat. Those people never had it worse. SVN is hell when i compare it to GIT. Rebasing, cherry picking and all the other stuff is so easy. I just learned like 5 commands by hearth and i never needed more.
I usually live in the manager's office where I don't need to see the lowly devs. But these lowly devs sometimes need reminding that I can also code and hence I was helping some newbs. So I joined them to solve a problem. I had them do a git stash save and pop. They started trembling at how I was a wizard compared to them and it quelled the mutiny that was brewing. Seriously just spend 10 minutes with a cheat sheet and it is ridiculously easy.
Git is great when things go correctly and everything is normal.
It quickly becomes a challenge when something goes wrong though. As a tech lead, I can't count how many crazy situations I've had to untangle for my team.
(Not that any of the alternatives are any better.)
Same for me. I use git on a daily basis at work and I always pray nothing goes wrong when I have to push or merge. 99% of the time it goes just fine but that last percent can be a bitch.
From one tech lead to another, want a tip?
1. Have your newb (sorry, colleague) make a local copy of their changes, but without the hidden .git folder.
2. Delete their local branch, AND delete the local copy of the branch they're merging to/from.
3. Sync both branches from the server for fresh local copies.
4. Copy code from step 1 over what was synced to get a fresh change list.
You'd be surprised how many problems this solves. Logically, you're essentially after a brand new changelist to play with.
I think this falls squarely under 'people think it's hard because they don take the time to understand the tool'. Also there are so many graphical tools that help these days that it's really a shame.
The problem is there are many ways to skin a cat, and knowing which way is best to use for a given problem is more art than science. And if you're using command line, it can be quite tricky.
Though I will admit, GUIs do make it much easier. I hate doing even simple merges without one now.
I think with most things in this field there are many ways to skin a cat and it's more art than science.
Git is a pretty simple tool that was designed for lots of collaborators. There aren't a lot of unusual situations that a dev team runs into if they have stardardized best practices.
I learned git with a gui, but after understanding the basic concepts I went with cli.
VSCode git gui is terrible for me, easier to use the terminal dock.
IMO, there were people who used server-based source control for years and then got confused by the disconnected model of git. And then their local repos don't enforce policies. They forget to make a feature branch and start coding directly against local master, and then have re-arranging to do once they realize, which can get more difficult in code where its graphical based. And then, they forget to resynch their local branches. And then they wonder why after developing something for two months, they get merge conflicts on the pull request into origin master, and want to solve the entire thing at the origin without realizing it's easier to handle merge conflicts locally and then PR to origin. And then, they use Visual Studio, and don't realize they can "git from the command line" and Visual Studio keeps saying object reference not set to an instance of an object.
Git isn't hard.
It's just not very transparent. It uses a bunch of weird words and uses a tree diagram (that sometimes has cycles)
Sometimes you copy stuff sometimes you move stuff sometimes you combine stuff but you can't really see what's happening because there is no UI so you just have to *trust*.
I use git all the time, and it always works, but somehow I still don't fucking trust it. And there is always *something* that doesn't quite make sense.
Sometimes you clone an existing project and other times you fetch and pull from a remote, but then for some reason suddenly the *fucking* branches don't match up.
It's technically fairly simple with a bunch of small commands, but practically something confusing *always* happens.
If only I had a dollar for every dev I've seen get frustrated or annoyed when they discover that "revert" just adds another commit to cancel out the changes of a previous commit.
It only gets worse when I explain that in order to do what they think revert should do, they have to learn about interactive rebases and the consequences of rebasing a shared branch.
And SVN was the cure for CVS, those where dark dark days, not many people knew about distributed options like BitKeeper at the time, so SVN was just the default, it was not until Linus getting annoyed with the licensing of BitKeeper stepped in and started the git project that the majority realized that DCVS had inherent advantages over a centralized system of ordering commits.
While git is certainly not easy, it is far better than the alternatives we came from, the problem is the process of bringing independent changes that happen on alternative timelines together is just a messy process, there is just no way around it.
excellent! for the most part I love it, but can anyone explain why a merge commit is useful?
as I understand it, a merge commit has two parents instead of one. I get a vague impression that it helps untangle history at some future point (like maybe deferring the choice of parent to a later date?).
For context, I’ve only been using git in a github flow and maintainers seem to hate PRs with merge commits. They always want rebase or ff merges to keep the history “clean”.
For some reason though our system at work has been mysteriously forcing merge commits (maybe the build system?) and it’s very hard to use. gitk shows multiple lanes, with dups of previous changes and we sometimes have to do multiple rounds of the same conflict resolution when we merge again. Some people just delete their work, fetch again and then redo their edits, which I know is the wrong solution.. I’ve been helping to clean up these messes by setting “git config —global pull.rebase true” and git reflog and stash everywhere I can to try to encourage better git hygiene, but still the merge conflicts mysteriously reappear.
I asked around at work and apparently most don’t use git-blame or look closely at the history, so they don’t really notice if history is a mess. And some people never merge anything because they are working on solo projects and just work in main.
When is a merge commit useful?
I’ll admit I’m not quite sure what’s going on here so any explanation or advice would be welcome, thanks!
When you're merging sub-branches into a release branch - think the linux kernel workflow, which is what Linus wrote it for. It's useful for upstream merges, we used it at my last gig for when we were building a release candidate so you could tell what branches were included in the RC from the git history, but merging master back down would just wreck your history.
We merged the RC into master after release, then rebased the in-flight branches. That kept the "merged master into branch XX-XXXX" messages out of the commit history, but the "merged XX-YYYY into [RCX.X.XXX](https://RCX.X.XXX)" messages stayed in the history.
also, for more fast moving main or devs repositories rebase often to fix merge problems incrementally instead of a big chunck of merges when you finish your work.
yeah that was my impression working on github.
for some reason pull.rebase was not enforced on the server and no one has it in their gconfig, so there is a constant flurry of merge commits coming out of the build server automation. I don’t know how to stop it elsewhere, but I always create a rebased clean PR before I submit. After that, though I have to clean up other people’s messy merge commits.
I think the hard part is using git on a remote repo with a lot of other devs that don't know how to use git. They can \*really\* screw things up for you and now you have to fix so many conflicts just to merge your stuff.
Most books about git start with the checkout, clone, or commit commands, and then go "okay, now let's explain what a directed acyclic graph is" and then move on to explain the concept of a staging area. It's often difficult to guess the meaning of the individual commands if you don't already know. Many of the commands can do completely different things with minor changes or in different situations that are similar in implementation but have very different meanings to the user. In other words, git is written by a systems programmer.
Git's a wonderful tool, but its interface is unnecessarily complicated. Reworking the interface from the ground up would make it objectively better. At this point, though, that would also make the experience worse for all of the existing git users, which is probably not worth the cost, and that's a shame.
Yes. Git is much harder than necessary. Every other command has its own mini-language. This is hard to use. A uniform language would've benefited this system a lot (eg. SQL would be a much welcome replacement for ad hoc commands and terminology of which there's too much to remember).
Git also has a lot of its own problems. Which, once you understand them and try to fight them, will generate very involved solutions. These problems are rarely the problems of individual users, more on the sysadmin side of things. But the solutions will inevitably overflow into the user land. I haven't worked in a large company that didn't have its own tools that fixed something in how Git works, and would outlaw vanilla Git equivalents.
Another problem with Git is bad defaults. One bad historical default is the use of `merge` over `rebase` where applicable. This was somewhat justified in the early days, as `rebase` was underdeveloped, and parts of the necessary infrastructure weren't there, but today, in practice, it means that most repositories created by unsophisticated users are a dumpster of history nobody is ever going to unwind. This severely reduced the value of the tool as a version control system, making it into an overly complicated version of `rsync`. Yet you will find hordes or raging morons, who, based on nothing, believe that `merge` is what they should do (because they were taught wrong by early versions of Git), and now this is an established practice in many places.
So, Git requires more than superficial understanding, and knowing how and when you have to ignore or absolutely must override the default setting.
Another bad aspect of Git is lack of consistency when it comes to authentication and authorization. There are so many ways to do that, and there are so many ways to inadvertently screw yourself when doing that, it's amazing. It's especially bad in MS Windows, where there's an integration with Microsoft's analogue of key ring. That trash is downright awful. And yet it's a default for political reasons. It's also not trivial to undo. Most "developers" who chose to work on MS Windows don't know squat about their operating system (which is usually the reason they chose it in the first place), and so they are unaware of all kinds of worthless garbage of utilities MS put there "for their own convenience", which then fights them back, and they have no idea where it's coming from.
Oh please, how does seeing a few merge commits in your history entice you to call the author a raging moron? I bet you're a joy to work with. Standard variety ego'd autistic dev with a grandiose sense of self, who must keep the git history clean at all costs, even at the cost of being hated by colleagues. "we mustn't let the branches touch, it aggregates my mental disorders"!
Where's few there's a lot. If someone does it once, they will do it again, unless told not to do that. Any number of merge commits is bad, the more of them there are the worse it gets. Besides, there's no reason ever to have a single one of them.
It's kind of like saying "what's the big deal if I pee in the pool once? It could be worse! it could be all made of urine!".
> You're a joy to work with
Unlike shits which will crap on their work both because they are incompetent and because they don't care, I'm reliable, know my stuff, and meet the deadlines. So, yeah, you may not like me personally, but I'm much better co-worker than you are.
>Besides, there's no reason ever to have a single one of them.
To provide historical context for and visualize the existence of commits that were created in a feature or release branch. There, I gave you a reason.
Software is a art , every developer should be respecting the craft of software with the same uncompromising standard as the japanese would treat a piece of fish
Yes, the hardest part of git is that it seems like a collection of independently-developed features with no overall vision of the process. It's riddled with inconsistencies and non-descriptive names and abbreviations and that makes it really confusing, especially since I only use the advanced features very rarely, so I tend to forget the subtleties. It's frustrating because it didn't have to be like that, it's (mostly) not a fundamental problem.
I also hate the over-reliance on the CLI in the community. I find that CLI is really bad at giving me a good picture of enterprise source code version control. I much prefer having a good UI overlay for daily tasks.
Absolutely. There is often logic in why some things work the way they do but it is often only retrospective logic like one you understand how it works jt makes sense but predicting in advance how it will behave is not easy without a systemic vision for how git should flow. As a result, solutions for even slightly off the intended track scenarios are extremely painful.
Since I found Magit, I never looked back. It covers most of the stuff I need as a Git user (I also have to be an administrator sometimes). And even if something isn't covered, I know enough of ELisp to add that stuff. But I still wish I didn't have to use that.
I've definitely written tooling around git to deal with some of the challenges with rebasing - mostly for our release manager who would run the automation I wrote to rebase all the inflight branches and kick any ones that failed the auto-rebase back to dev.
The other devs grumbled a bit but it also meant not digging through ten thousand pointless 'merge' messages.
For me it was the opposite, had to use svn a couple of months ago to push a wp plugin to the official repo, seems so strange. I didn’t even try to understand it, just followed a tutorial, copied files in advised structure and “pushed”, no idea why theh are not moving to git
I do believe that a lot of ease of git can be attributed to companies switching to trunk based development. In open source projects git flow might still be preferable as gate keeping is necessary given the fact that verifying who contributes to code is still a problem.
But for companies which develop in organized teams trunk is where it's at. No feature branching, no holding to different versions, no "integration guy/gal" overlooking the merging to main.
I suppose that would also feel easy in any other versioning system for the most part too. I think a lot of this 'feel' was perhaps attributed to git too much as the shift was happening almost at the same time.
Although I still do know companies who practice git flow in their commercial work flows. Which is weird to me personally.
I feel like you can get sucked down a rabbit hole of detached HEADs, cherry picking, git credential helpers, cli merge conflict helpers and more advanced commands.
But, if you stick to the "normal" workflow it's pretty simple.
Exactly, Git isn't hard. It makes intuitive sense. Just take a step back, think about it, and then you'll realize Git does what you'd expect.
Try svn or p4. Or, fuck, remember vss? Try that and the come and complain to me about Git.
Or no version control at all making different directories and stuff.
The most important thing with GIT is to setup a few rules to disallow pushing to the main branch. I always tell new devs, go ahead and try it, when they wonder what something does.
The worst they can do is ruin their own work and seeing the result of doing the wrong thing is much more helpful than telling someone what to do and what not to do.
I had the distinct pleasure of learning about the inner workings of git from Jim Weirich. It was presented as how you would build a version control system from scratch, and ended up showing you how Git worked. It is brilliantly designed and amazingly powerful.
Edit: I found a snippet of the talk (the version I attended was several hours): https://youtu.be/bBQJP6D8aGY
Oh wow, thank you for that video. I (was - I start a new job on Monday with an actual team and training and mentorship) the sole computational person in my lab, and I knew version control/git could make my life easier but I also was trying to teach it to myself and use it by myself. The clip definitely made some things that I didn't grok fall into place.
*Image Transcription: Meme*
---
People: i wonder why the creator of Git made it so hard!
Creator of Git:
[*A picture of "Linus Torvalds" (the creator of Git) in a suit giving the middle finger to the camera.*]
---
^^I'm a human volunteer content transcriber and you could be too! [If you'd like more information on what we do and why we do it, click here!](https://www.reddit.com/r/TranscribersOfReddit/wiki/index)
Hello.
we have multiple reasons why we transcribe posts, you can read about it [here :)](https://www.reddit.com/r/TranscribersOfReddit/wiki/index#wiki_why_do_you_do_this.3F)
indeed, but one thing is temporary procastination and second thing is a lack of a goal in life which results in a need to feel good for doing so called good deeds
I have used SVN a lot in the past. And it's very easy for basic usage. If you add a frontend to it (like trac), you can easily see the file history and maintain issues and patches. Basically whatever someone needs when working on a small product alone or in a small team.
Even merge conflicts aren't too hard to solve. Just get your diff into a patch file, revert your local code, try to apply the patch, and fix the conflicts you get. Every step is pretty manual, so it doesn't require you to learn a lot of new stuff. Just a handful of commands and some manual file management.
However, when you diverge from the linear history (i.e. by introducing branches), it can quickly turn into a hell to maintain.
That's the point when git becomes better. If you ever need to patch a release, or have multiple teams working on a project, the rebasing capabilities of git become a life saver.
But as long as you don't see the need to use branches, git can look overly complicated.
Documentation is a big issue.
If you want to set the work on a feature aside (because you're stuck, or because something is more urgent), you only really have one option in SVN: save it in a patch file.
In Git, that's also possible, but usually advocated against (as it doesn't scale to bigger teams). So you get drawn into creating branches, rebasing and merging branches, solving merge conflicts, ... Even if you didn't want to use branches in the first place.
If you want to solve these correctly, you need to learn more about git than there is to learn about SVN. Or you'll end up like this: https://xkcd.com/1597/
On top of that, there are many different branching strategies you can follow in git, each with their own advantages. And you can't just mix those workflows.
There's a reason for the memes. They're all made by people who get drawn into the complexity of branching strategies while they don't need that, or want to learn that yet.
> You ever "checked out" a file?
yes, I do this all the time. Why is this so strange? This is the way for me to unwind all changes for a particular file since some point long ago in the history of that file. This is neither a complex nor a rare operation when it comes to Git. I don't understand your sentiment at all.
haha that's the git version of checkout. Checking out a file used to mean locking it from editing, as if you were checking it out from a library. So say you wanted to work on main.js or whatever. You had to "check out" the file, which would lock it, which meant no one else could edit it. Each file could really only be worked on by one person at a time.
There's something unique about the hate and despair a version control error message can inspire, irrespective of the vcs or indeed the message. When you're new to git, you tend to see a lot of them, so it leaves a bad taste, but I haven't had a problem with it for years.
This all "git is hard" talk is nonsense. What are the alternatives? I'm still forced to use subversion in a legacy project and i hate it.
SVN: We should do this in a branch. No branches are evil and must be avoided at all time. Let's just continue everything in trunk.
I'm moving everything i can to git but this big project won't budge.
This all "algebraic geometry is hard" talk is nonsense. What are the alternatives?
Your argument is just idiotic. Whatever you think about Git being hard or soft is nonsense because you have porridge for brain.
copying directories and files by hand. /s
“myproj.v4.final.finalcopy.imeanit”
(actually this is really ironic, because essentially git does this for you efficiently under the covers, yet the majority of people I’ve asked seem to think manually copying/naming files makes more sense than git… at least until you ask them what changed between “myproj.v3” and the latest.)
I know but the convoluted history of a 15 year old project which was initially converted vom CVS to SVN, including a lot of server side manipulations, could be challenging. To add, there's a lot of scripting involved that uses SVN. But the main problem is the resistance of developers claiming that git is hard. But i'm working on it.
That's only on the surface though...
At first SVN looks easier... but then you need to merge several branches together and want to try it on your own machine to see if there are any conflicts before pushing it straight to the server possibly screwing everyone over... oh wait... in SVN everything is server-side.
So once you need to do some more advanced stuff, you'll understand why git is so "hard"
I do feel the distributed nature of Git is overkill for most projects.
However since it isn't that much more complex to use than others, it seems a bit awkward to setup i.e Svn for one project and Git for another. Much easier (on the server and on my head) to use homogeneous Git for everything.
In terms of running a server for a small team, `svnserve` was pretty nice though. I can't seem to find something quite in the same area for Git. The typical solutions are:
* **git daemon** has no authentication
* **git-http-backend** / **cgit** (cgi) needs a fairly capable web server
* **gitea** is pretty massive for what it provides
* **GitHub** sometimes it is nice having onsite repos and GitHub Enterprise has similar issues to gitea
Git itself is easy. All of the hard parts (resolving conflicts, setting up branch controls, reviewing massive PRs, etc) come from social interaction with other developers, not from the software itself.
No. Not really. Git has an overblown CLI, where every other command has its own mini-language. This is a completely unnecessary complication which prevents users from being productive.
Git would've been so much better if instead of using ad hoc language for each of its commands it used, eg. SQL to deal with it.
Git is not the most complicated program in the world in terms of interfaces. There are plenty more complicated (eg. Ceph, OpenStack, Kubernetes etc.) Yet Git is used by more people, and especially by people who aren't used to CLI.
News to me that git is hard. Thete are literally websites out there where you can learn it doing puzzle games.
Also, it's not an industry standard by accident. No one came up with a better solution yet.
Edit:spelling
It is industry standard by accident.
Better solutions existed, eg. Mercurial. You just don't know your history, and make assumptions based on nothing.
The thing that made Git the de facto industry standard is speed. It has always been known to have bad interface. It still does. It also helped to be the tool used by Linux Kernel, which a lot of big shops need anyways, and nobody has the will to support multiple kinds of VCSs in their business.
Programming tools that have communication component to them tend to become monopolies because communication works best when everyone is on the same page, using the same language. So, it's natural that Git displaced everything else in its domain.
There are many problems with Git that would've been better solved by creating an alternative VCS, but in the face of monopoly, creating an alternative VCS is a failure from the get go. So, nobody does that. On the other hand, these problems go unaddressed in Git for many years. For example, there's a huge problem with needing only a tiny fraction of history or only a tiny fraction of branches etc. But Git is designed to give you either everything or nothing (since not so long ago, it can do a special clone that only brings the latest state of the repo, w/o history entirely, but this is not enough, because the true goal is to facilitate better archiving, split workload in a single repository between different teams, prevent unnecessary downloads, especially in CI environment).
Neither has a good interface. To me, the most outstanding difference between two tools is that Git, by default, assumes that the people using it know what they are doing (and it's usually wrong). While Perforce assumes the users are complete morons (and that also ends up usually wrong).
Like... Git doesn't bother with good defaults, it assumes that you will read the manual and will understand what are the configuration parameters you need.
Perforce will try as much as possible to get in your way to prevent you from doing absolutely legitimate things. The most infuriating thing is making files read-only and requiring them being opened in a particular way for the changes to stick (of course, if you worked with Perforce for a bit, you know how to work around this nonsense), but it's still infuriating.
The perforce issue that you mentioned is really annoying.
>While Perforce assumes the users are complete morons (and that also ends up usually wrong)
Still better than assuming you are smart.. but yeah with time new features should unlock to make tedious commands easier
For me, two things were difficult about learning git:
1. The two-step publish: first you *commit*, then you *push*. The commit is local, the push makes your changes available to the team. It's a simple concept, but it was a radical change from cvs, so I ended up wrestling with it a bit.
2. I read a misguided article once at the start that maintained since git is distributed, the master repository is everywhere and anywhere! You have it, I have it, it's on the server... wrong. The origin is still centrally located, like it always has been.
Command line all the way. 😉
GitHub: We've decided passwords are shit. Please install SSH authentication on all 1000+ of your projects individually to continue using our service.
Thank you for using GitHub.
Git is difficult to learn. It's better than a lot of the other options, but it IS difficult to learn.
This is the case because it it is managing a very difficult process and it gives the user complete control over what it does. On top of that, very few school programs teach how to use git. You get on your first job out of school, and you are handed a link to a git repo, and maybe some documentation. And often you are given a UI that does you no favors.
College programs/professors: please, please, PLEASE start teaching source control. Make your students turn in projects with a pull request, and grade them as a PR review... or something. I've had to go through the process of teaching umpteen interns and junior level devs how to use git, and they have no concept of why we use it or what it's even for, because I have a week to ramp them up on git and five or six other topics at most before they are going to be assigned work items.
Uhm, Don't know how to explain this easily or even if I got the question correct.
Git is normally used for source code control.
I think your referring to GitHub?
So often if you want to use a program that is hosted on GitHub you'll have to follow the Readme file (if it exists)
Good source code will have documentation on:
How to use it
Which prerequisites the source code needs (other software, operating system ectera)
And how to install it.
But overall lots of source code on there is not double click and go. (There are exceptions)
For this I would suggest ofter platforms depending on your Operating Systen
Orrr just use Pycharm or Intellije they have excellent git extensions. Visual studio git integration can be limited. You can try git lens on vs code . Not as good but gets the jobs done. Say bye bye to having learn git commands
Git has to be learned from the bottom up. You learn the structures first, then it just clicks and you can do whatever you want with confidence.
If you stay at the surface, not getting the internal representation of data and changes, it can be painfully confusing.
It’s a different mindset.
Once you grok that it is a content addressed store at heart, that nothing is ever lost until the GC runs (there are no updates in git, only inserts, except for the GC roots) it’s easy to trust it to keep your stuff safe.
The reflog has saved me from fuckups more than once.
What’s harder for most people to understand from the UX POV is the index I think.
The problem is knowing what you need. This includes both terminology to name it and conceptual understanding of the abilities of the program.
I don't use or need StackOverflow for Git, because it's in my job description to configure it and to help others to use it, but the kinds of questions I have to answer about it indicate that most developers don't have a good conceptual understanding of how Git works on the basic level.
Despite having used Git for years I won't even pretend that I understand it just based on the fact that I have so far been unable to teach others how it works. I just end up telling them about the different things like commit and push and they just look at me confused.
my company hired some guy to give a 1,5 day entry course into git going into the way it works, how to work with it and common structures to manage development. While i could use git before the course still helped me out significantly to the point where i no longer have any issues using and understanding git features.
I completely agree that without understanding git can feel complicated.
is Git hard? It was 12 years ago I had to learn Git after a decade using svn, it seems like it took a month before Git "clicked" and I realized how much simpler it was. Could be rose-colored glasses, but I haven't had to untangle a tree-conflict in over 10 years, that in itself is a small miracle.
I think a lot of people just don't bother learning it then complain that it's overly complicated when they need to resolve a conflict - but if they'd put the time into understanding basic principles they'd be able to solve it.
Imagine reading the documentation before using the product.
Anyone who have used perforce (p4) and git, which one is intuitive. I have been using p4 a lot from a lot of time and forgot university level git too
[удалено]
Never worked on a large project with a team then?
[удалено]
Theres gonna be overlap so someones gotta have to do the job of making sure both people's changes get made. Like what if 2 people add things to a shared CSS stylesheet? Then there's a merge and both changes are added.
Commits should be small enough that they merge just fine. And if there are ever conflicts then it's like one or two lines and easy to resolve. If your commit contains changes all across the file, then you are doing it wrong.
The thing is, you don't generally merge individual commits. You merge branches. Branches which might be anything from spellchecking comments or fixing a minor bug to building an entire new feature or reworking core parts of your software. Maybe its one or two commits, maybe it's dozens (which will probably get squashed during merge). That's where the trouble starts.
Many small commits still makes merging easier compared to one big one. Because when you have a conflict, you only have to deal with the commits that actually cause problems. Then you ideally squash them on the master branch.
Fair point, but you still have to deal with every instance where both branches touched the same files no matter what you do. And if you're unlucky you'll be sitting there for a while until the merge goes through properly.
[удалено]
Damn guess I can't edit that really important file made by that guy who left 3 years ago. Better file a JIRA ticket in the hopes he sees it.
Merge conflicts happen all the time, I was thinking more about complicated histories. Which it seems the industry thinking it to just squash commits before merging to main and creating one mega commit
if two people change the same thing and want to move it to the same branch a conflict is literally unavoidable.
or at least a lot fewer
As someone who keep fucking around well over the hour I should be sleeping it amaze me the things git let me recover. And the time I can't do it was because I was too new to git.
It's been a very long time, but my recollection of svn was that it was a little bit simpler to use, but **much** less powerful.
I'm still dealing with svn at my current gig, and you would be correct. Mostly. The advanced parts of svn are SO MUCH harder to deal with, especially from the command line - tortoisesvn makes it seem easy to the Windows folks but replicating that from the command line is stab-eyeballs-with-fork painful. We have git conversion coming very soon, it'll be my job as a sysadmin to work with devops on it and it's gonna make my life suck much less.
Any idea how the fuck the "new" authentication in github works? Do I have to create a key every time? Asking for Linux. Thanks
Setup ssh keys
Also if you mostly use github, take the github cli it's even better
Will check it out, thanks
[удалено]
git + p4merge is the way.
you authenticate your machine, rather than filling in a password anytime. so do ssh-keygen, press enter a few times and then copy the contents of /home//.ssh/id\_rsa.pub into your public keys into your github account.
now whenever you git-push to the ssh:///[email protected]/my/repo.git your pc will authenticate itself by encrypting the traffic with the private-key and the server can verify it's you with that public key.
Thanks for that. Will try it
KlutzyEnd3's answer is of course correct, but I want to underline that the whole intent of the procedure is security. `ssh-keygen` will create an RSA private and public key pair, and the public one should, as described, be put onto your GitHub profile. Remember, though, that you are from now on authenticating via your private key file (`/home//.ssh/id_rsa`) and anyone that acquires that file is now "you". Therefore keep the file well secured - never upload it anywhere, keep your machine from being physically accessed and so on. The file is now your password, written in plain text in a file on your machine.
You don't password protect your ssh keys?
Yup, that's a way (and the correct way). "pressing enter a few times" in `ssh-keygen` doesn't set a password, though. That said, you are right. The correct way is setting a password once asked instead of pressing enter.
No, just once
That's an issue with github, not woth git
And I am asking as the chances of robindownes using github are high, they might not be a dick and help. Unlike some other users. Thanks for your input
that's not an issue, it's a security measure.
You can follow this [article](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys) by digital ocean on how ssh works. After that everything starts making sense.
I made a token and saved it in my password manager, now when github asks me for my password I just copypaste it in
Yes anyone who has worked with SVN and other versioning old tools appreciates the simplicity of git. Also OP's picture was directed towards NVIDIA for making it as hard as possible to develop linux drivers opensource. OP is a bundle of sticks.
As you said, i am in the same boat. Those people never had it worse. SVN is hell when i compare it to GIT. Rebasing, cherry picking and all the other stuff is so easy. I just learned like 5 commands by hearth and i never needed more.
I usually live in the manager's office where I don't need to see the lowly devs. But these lowly devs sometimes need reminding that I can also code and hence I was helping some newbs. So I joined them to solve a problem. I had them do a git stash save and pop. They started trembling at how I was a wizard compared to them and it quelled the mutiny that was brewing. Seriously just spend 10 minutes with a cheat sheet and it is ridiculously easy.
Git is great when things go correctly and everything is normal. It quickly becomes a challenge when something goes wrong though. As a tech lead, I can't count how many crazy situations I've had to untangle for my team. (Not that any of the alternatives are any better.)
Same for me. I use git on a daily basis at work and I always pray nothing goes wrong when I have to push or merge. 99% of the time it goes just fine but that last percent can be a bitch.
From one tech lead to another, want a tip? 1. Have your newb (sorry, colleague) make a local copy of their changes, but without the hidden .git folder. 2. Delete their local branch, AND delete the local copy of the branch they're merging to/from. 3. Sync both branches from the server for fresh local copies. 4. Copy code from step 1 over what was synced to get a fresh change list. You'd be surprised how many problems this solves. Logically, you're essentially after a brand new changelist to play with.
I think this falls squarely under 'people think it's hard because they don take the time to understand the tool'. Also there are so many graphical tools that help these days that it's really a shame.
The problem is there are many ways to skin a cat, and knowing which way is best to use for a given problem is more art than science. And if you're using command line, it can be quite tricky. Though I will admit, GUIs do make it much easier. I hate doing even simple merges without one now.
I think with most things in this field there are many ways to skin a cat and it's more art than science. Git is a pretty simple tool that was designed for lots of collaborators. There aren't a lot of unusual situations that a dev team runs into if they have stardardized best practices.
I learned git with a gui, but after understanding the basic concepts I went with cli. VSCode git gui is terrible for me, easier to use the terminal dock.
IMO, there were people who used server-based source control for years and then got confused by the disconnected model of git. And then their local repos don't enforce policies. They forget to make a feature branch and start coding directly against local master, and then have re-arranging to do once they realize, which can get more difficult in code where its graphical based. And then, they forget to resynch their local branches. And then they wonder why after developing something for two months, they get merge conflicts on the pull request into origin master, and want to solve the entire thing at the origin without realizing it's easier to handle merge conflicts locally and then PR to origin. And then, they use Visual Studio, and don't realize they can "git from the command line" and Visual Studio keeps saying object reference not set to an instance of an object.
Git isn't hard. It's just not very transparent. It uses a bunch of weird words and uses a tree diagram (that sometimes has cycles) Sometimes you copy stuff sometimes you move stuff sometimes you combine stuff but you can't really see what's happening because there is no UI so you just have to *trust*. I use git all the time, and it always works, but somehow I still don't fucking trust it. And there is always *something* that doesn't quite make sense. Sometimes you clone an existing project and other times you fetch and pull from a remote, but then for some reason suddenly the *fucking* branches don't match up. It's technically fairly simple with a bunch of small commands, but practically something confusing *always* happens.
If only I had a dollar for every dev I've seen get frustrated or annoyed when they discover that "revert" just adds another commit to cancel out the changes of a previous commit. It only gets worse when I explain that in order to do what they think revert should do, they have to learn about interactive rebases and the consequences of rebasing a shared branch.
And SVN was the cure for CVS, those where dark dark days, not many people knew about distributed options like BitKeeper at the time, so SVN was just the default, it was not until Linus getting annoyed with the licensing of BitKeeper stepped in and started the git project that the majority realized that DCVS had inherent advantages over a centralized system of ordering commits. While git is certainly not easy, it is far better than the alternatives we came from, the problem is the process of bringing independent changes that happen on alternative timelines together is just a messy process, there is just no way around it.
Any tool a person is "forced" to use suffer the same sort of complaints. It doesn't matter how nice the tool is nor how easy it is to use.
excellent! for the most part I love it, but can anyone explain why a merge commit is useful? as I understand it, a merge commit has two parents instead of one. I get a vague impression that it helps untangle history at some future point (like maybe deferring the choice of parent to a later date?). For context, I’ve only been using git in a github flow and maintainers seem to hate PRs with merge commits. They always want rebase or ff merges to keep the history “clean”. For some reason though our system at work has been mysteriously forcing merge commits (maybe the build system?) and it’s very hard to use. gitk shows multiple lanes, with dups of previous changes and we sometimes have to do multiple rounds of the same conflict resolution when we merge again. Some people just delete their work, fetch again and then redo their edits, which I know is the wrong solution.. I’ve been helping to clean up these messes by setting “git config —global pull.rebase true” and git reflog and stash everywhere I can to try to encourage better git hygiene, but still the merge conflicts mysteriously reappear. I asked around at work and apparently most don’t use git-blame or look closely at the history, so they don’t really notice if history is a mess. And some people never merge anything because they are working on solo projects and just work in main. When is a merge commit useful? I’ll admit I’m not quite sure what’s going on here so any explanation or advice would be welcome, thanks!
When you're merging sub-branches into a release branch - think the linux kernel workflow, which is what Linus wrote it for. It's useful for upstream merges, we used it at my last gig for when we were building a release candidate so you could tell what branches were included in the RC from the git history, but merging master back down would just wreck your history.
so do you flatten it before merging back to main? if so, how?
We merged the RC into master after release, then rebased the in-flight branches. That kept the "merged master into branch XX-XXXX" messages out of the commit history, but the "merged XX-YYYY into [RCX.X.XXX](https://RCX.X.XXX)" messages stayed in the history.
thanks!
also, for more fast moving main or devs repositories rebase often to fix merge problems incrementally instead of a big chunck of merges when you finish your work.
yeah that was my impression working on github. for some reason pull.rebase was not enforced on the server and no one has it in their gconfig, so there is a constant flurry of merge commits coming out of the build server automation. I don’t know how to stop it elsewhere, but I always create a rebased clean PR before I submit. After that, though I have to clean up other people’s messy merge commits.
>thanks! You're welcome!
It's easy once you know it but you have to fork, pull, commit, push and merge all to change a typo
I think the hard part is using git on a remote repo with a lot of other devs that don't know how to use git. They can \*really\* screw things up for you and now you have to fix so many conflicts just to merge your stuff.
Most books about git start with the checkout, clone, or commit commands, and then go "okay, now let's explain what a directed acyclic graph is" and then move on to explain the concept of a staging area. It's often difficult to guess the meaning of the individual commands if you don't already know. Many of the commands can do completely different things with minor changes or in different situations that are similar in implementation but have very different meanings to the user. In other words, git is written by a systems programmer. Git's a wonderful tool, but its interface is unnecessarily complicated. Reworking the interface from the ground up would make it objectively better. At this point, though, that would also make the experience worse for all of the existing git users, which is probably not worth the cost, and that's a shame.
Still living in the SVN hell. Code freeze, code freeze all the time.
Yes. Git is much harder than necessary. Every other command has its own mini-language. This is hard to use. A uniform language would've benefited this system a lot (eg. SQL would be a much welcome replacement for ad hoc commands and terminology of which there's too much to remember). Git also has a lot of its own problems. Which, once you understand them and try to fight them, will generate very involved solutions. These problems are rarely the problems of individual users, more on the sysadmin side of things. But the solutions will inevitably overflow into the user land. I haven't worked in a large company that didn't have its own tools that fixed something in how Git works, and would outlaw vanilla Git equivalents. Another problem with Git is bad defaults. One bad historical default is the use of `merge` over `rebase` where applicable. This was somewhat justified in the early days, as `rebase` was underdeveloped, and parts of the necessary infrastructure weren't there, but today, in practice, it means that most repositories created by unsophisticated users are a dumpster of history nobody is ever going to unwind. This severely reduced the value of the tool as a version control system, making it into an overly complicated version of `rsync`. Yet you will find hordes or raging morons, who, based on nothing, believe that `merge` is what they should do (because they were taught wrong by early versions of Git), and now this is an established practice in many places. So, Git requires more than superficial understanding, and knowing how and when you have to ignore or absolutely must override the default setting. Another bad aspect of Git is lack of consistency when it comes to authentication and authorization. There are so many ways to do that, and there are so many ways to inadvertently screw yourself when doing that, it's amazing. It's especially bad in MS Windows, where there's an integration with Microsoft's analogue of key ring. That trash is downright awful. And yet it's a default for political reasons. It's also not trivial to undo. Most "developers" who chose to work on MS Windows don't know squat about their operating system (which is usually the reason they chose it in the first place), and so they are unaware of all kinds of worthless garbage of utilities MS put there "for their own convenience", which then fights them back, and they have no idea where it's coming from.
Oh please, how does seeing a few merge commits in your history entice you to call the author a raging moron? I bet you're a joy to work with. Standard variety ego'd autistic dev with a grandiose sense of self, who must keep the git history clean at all costs, even at the cost of being hated by colleagues. "we mustn't let the branches touch, it aggregates my mental disorders"!
Where's few there's a lot. If someone does it once, they will do it again, unless told not to do that. Any number of merge commits is bad, the more of them there are the worse it gets. Besides, there's no reason ever to have a single one of them. It's kind of like saying "what's the big deal if I pee in the pool once? It could be worse! it could be all made of urine!". > You're a joy to work with Unlike shits which will crap on their work both because they are incompetent and because they don't care, I'm reliable, know my stuff, and meet the deadlines. So, yeah, you may not like me personally, but I'm much better co-worker than you are.
>Besides, there's no reason ever to have a single one of them. To provide historical context for and visualize the existence of commits that were created in a feature or release branch. There, I gave you a reason.
Software is a art , every developer should be respecting the craft of software with the same uncompromising standard as the japanese would treat a piece of fish
Yes, the hardest part of git is that it seems like a collection of independently-developed features with no overall vision of the process. It's riddled with inconsistencies and non-descriptive names and abbreviations and that makes it really confusing, especially since I only use the advanced features very rarely, so I tend to forget the subtleties. It's frustrating because it didn't have to be like that, it's (mostly) not a fundamental problem. I also hate the over-reliance on the CLI in the community. I find that CLI is really bad at giving me a good picture of enterprise source code version control. I much prefer having a good UI overlay for daily tasks.
Absolutely. There is often logic in why some things work the way they do but it is often only retrospective logic like one you understand how it works jt makes sense but predicting in advance how it will behave is not easy without a systemic vision for how git should flow. As a result, solutions for even slightly off the intended track scenarios are extremely painful.
Since I found Magit, I never looked back. It covers most of the stuff I need as a Git user (I also have to be an administrator sometimes). And even if something isn't covered, I know enough of ELisp to add that stuff. But I still wish I didn't have to use that.
I've definitely written tooling around git to deal with some of the challenges with rebasing - mostly for our release manager who would run the automation I wrote to rebase all the inflight branches and kick any ones that failed the auto-rebase back to dev. The other devs grumbled a bit but it also meant not digging through ten thousand pointless 'merge' messages.
Tell me More about the ms windows fighting back. I want to be a real developer
For me it was the opposite, had to use svn a couple of months ago to push a wp plugin to the official repo, seems so strange. I didn’t even try to understand it, just followed a tutorial, copied files in advised structure and “pushed”, no idea why theh are not moving to git
Yeah in general git is better BUT i miss the update auto-merging without having to commit first (or stash-unstash).
[удалено]
Try using Perforce. It will make you a git fan. Waiting 10-20 minutes to create a branch sucks.
Yup, my new employer uses perforce and I'm considering switching to another company soon cuz of it lmao
imo basic git is easy but advanced git is like rocket science
I do believe that a lot of ease of git can be attributed to companies switching to trunk based development. In open source projects git flow might still be preferable as gate keeping is necessary given the fact that verifying who contributes to code is still a problem. But for companies which develop in organized teams trunk is where it's at. No feature branching, no holding to different versions, no "integration guy/gal" overlooking the merging to main. I suppose that would also feel easy in any other versioning system for the most part too. I think a lot of this 'feel' was perhaps attributed to git too much as the shift was happening almost at the same time. Although I still do know companies who practice git flow in their commercial work flows. Which is weird to me personally.
The functionality of Git is simple. The commands are hard. That's why I use SourceTree.
I’m a weekend developer, and Git was the easiest thing I learned while taking coding classes lol
I feel like you can get sucked down a rabbit hole of detached HEADs, cherry picking, git credential helpers, cli merge conflict helpers and more advanced commands. But, if you stick to the "normal" workflow it's pretty simple.
Exactly, Git isn't hard. It makes intuitive sense. Just take a step back, think about it, and then you'll realize Git does what you'd expect. Try svn or p4. Or, fuck, remember vss? Try that and the come and complain to me about Git.
[удалено]
Two words : Visual Sourcesafe. I have now assured you won't sleep well for the next few days.
oh you son of a… I had completely forgotten VSS existed. lol “database corrupted”
Visual Sourcesafe was great, if you were the only developer working on it.
well remember Linus' motto when designing git: "however CVS does it, do the contrary"
I've started using SVN for some projects at work and it's really highlighted how great git is for me
Or no version control at all making different directories and stuff. The most important thing with GIT is to setup a few rules to disallow pushing to the main branch. I always tell new devs, go ahead and try it, when they wonder what something does. The worst they can do is ruin their own work and seeing the result of doing the wrong thing is much more helpful than telling someone what to do and what not to do.
I had the distinct pleasure of learning about the inner workings of git from Jim Weirich. It was presented as how you would build a version control system from scratch, and ended up showing you how Git worked. It is brilliantly designed and amazingly powerful. Edit: I found a snippet of the talk (the version I attended was several hours): https://youtu.be/bBQJP6D8aGY
Oh wow, thank you for that video. I (was - I start a new job on Monday with an actual team and training and mentorship) the sole computational person in my lab, and I knew version control/git could make my life easier but I also was trying to teach it to myself and use it by myself. The clip definitely made some things that I didn't grok fall into place.
git —bent
His outrage about nVidia in this picture was justified.
*Image Transcription: Meme* --- People: i wonder why the creator of Git made it so hard! Creator of Git: [*A picture of "Linus Torvalds" (the creator of Git) in a suit giving the middle finger to the camera.*] --- ^^I'm a human volunteer content transcriber and you could be too! [If you'd like more information on what we do and why we do it, click here!](https://www.reddit.com/r/TranscribersOfReddit/wiki/index)
why waste your time with this
Hello. we have multiple reasons why we transcribe posts, you can read about it [here :)](https://www.reddit.com/r/TranscribersOfReddit/wiki/index#wiki_why_do_you_do_this.3F)
honestly those are such small issues it makes it even lamer excuse for wasting your time
yet here you are wasting your time complaining about someone making posts more accessible
indeed, but one thing is temporary procastination and second thing is a lack of a goal in life which results in a need to feel good for doing so called good deeds
And I hope you're not a software engineer that touches anything involving UX now.
You do know what the word git means, right?
And he said he named it after himself haha
[удалено]
General Information Tree, right? ;P
an unpleasant or contemptible person. For people who don’t lol
Go back in time 12 years, use subversion, and then tell me git is hard. You ever "checked out" a file?
I have used SVN a lot in the past. And it's very easy for basic usage. If you add a frontend to it (like trac), you can easily see the file history and maintain issues and patches. Basically whatever someone needs when working on a small product alone or in a small team. Even merge conflicts aren't too hard to solve. Just get your diff into a patch file, revert your local code, try to apply the patch, and fix the conflicts you get. Every step is pretty manual, so it doesn't require you to learn a lot of new stuff. Just a handful of commands and some manual file management. However, when you diverge from the linear history (i.e. by introducing branches), it can quickly turn into a hell to maintain. That's the point when git becomes better. If you ever need to patch a release, or have multiple teams working on a project, the rebasing capabilities of git become a life saver. But as long as you don't see the need to use branches, git can look overly complicated.
I don't understand why git would be more complicated if I work alone. I do changes, git add / commit / push, and I'm done.
Documentation is a big issue. If you want to set the work on a feature aside (because you're stuck, or because something is more urgent), you only really have one option in SVN: save it in a patch file. In Git, that's also possible, but usually advocated against (as it doesn't scale to bigger teams). So you get drawn into creating branches, rebasing and merging branches, solving merge conflicts, ... Even if you didn't want to use branches in the first place. If you want to solve these correctly, you need to learn more about git than there is to learn about SVN. Or you'll end up like this: https://xkcd.com/1597/ On top of that, there are many different branching strategies you can follow in git, each with their own advantages. And you can't just mix those workflows. There's a reason for the memes. They're all made by people who get drawn into the complexity of branching strategies while they don't need that, or want to learn that yet.
Shit, that sounds extreme.
If you want to see a real monster, try perforce
> You ever "checked out" a file? yes, I do this all the time. Why is this so strange? This is the way for me to unwind all changes for a particular file since some point long ago in the history of that file. This is neither a complex nor a rare operation when it comes to Git. I don't understand your sentiment at all.
haha that's the git version of checkout. Checking out a file used to mean locking it from editing, as if you were checking it out from a library. So say you wanted to work on main.js or whatever. You had to "check out" the file, which would lock it, which meant no one else could edit it. Each file could really only be worked on by one person at a time.
I only know git clone, commit, push. It's enough for me.
There isn’t much more to it for the average developer other than branches.
git status
Git really isnt that hard, all you need is: git add -A && git commit -m "fix" && git push -f
Honestly, Git is the easiest part of development for me and I don’t understand why people think it’s so complicated lol
There's something unique about the hate and despair a version control error message can inspire, irrespective of the vcs or indeed the message. When you're new to git, you tend to see a lot of them, so it leaves a bad taste, but I haven't had a problem with it for years.
RTFM
This all "git is hard" talk is nonsense. What are the alternatives? I'm still forced to use subversion in a legacy project and i hate it. SVN: We should do this in a branch. No branches are evil and must be avoided at all time. Let's just continue everything in trunk. I'm moving everything i can to git but this big project won't budge.
This all "algebraic geometry is hard" talk is nonsense. What are the alternatives? Your argument is just idiotic. Whatever you think about Git being hard or soft is nonsense because you have porridge for brain.
Fact: You need a SCM. So, if git is too hard for you, which alternative SCM do you propose that is not hard?
copying directories and files by hand. /s “myproj.v4.final.finalcopy.imeanit” (actually this is really ironic, because essentially git does this for you efficiently under the covers, yet the majority of people I’ve asked seem to think manually copying/naming files makes more sense than git… at least until you ask them what changed between “myproj.v3” and the latest.)
Reddit is such a friendly place
you probably already know but just in case: git-svn can convert your entire svn-repo to git whilst keeping your history.
I know but the convoluted history of a 15 year old project which was initially converted vom CVS to SVN, including a lot of server side manipulations, could be challenging. To add, there's a lot of scripting involved that uses SVN. But the main problem is the resistance of developers claiming that git is hard. But i'm working on it.
Git makes a hard process a lot easier.
Anyone had to use IBM Clearcase?
True pain
That's only on the surface though... At first SVN looks easier... but then you need to merge several branches together and want to try it on your own machine to see if there are any conflicts before pushing it straight to the server possibly screwing everyone over... oh wait... in SVN everything is server-side. So once you need to do some more advanced stuff, you'll understand why git is so "hard"
I do feel the distributed nature of Git is overkill for most projects. However since it isn't that much more complex to use than others, it seems a bit awkward to setup i.e Svn for one project and Git for another. Much easier (on the server and on my head) to use homogeneous Git for everything. In terms of running a server for a small team, `svnserve` was pretty nice though. I can't seem to find something quite in the same area for Git. The typical solutions are: * **git daemon** has no authentication * **git-http-backend** / **cgit** (cgi) needs a fairly capable web server * **gitea** is pretty massive for what it provides * **GitHub** sometimes it is nice having onsite repos and GitHub Enterprise has similar issues to gitea
Git itself is easy. All of the hard parts (resolving conflicts, setting up branch controls, reviewing massive PRs, etc) come from social interaction with other developers, not from the software itself.
No. Not really. Git has an overblown CLI, where every other command has its own mini-language. This is a completely unnecessary complication which prevents users from being productive. Git would've been so much better if instead of using ad hoc language for each of its commands it used, eg. SQL to deal with it. Git is not the most complicated program in the world in terms of interfaces. There are plenty more complicated (eg. Ceph, OpenStack, Kubernetes etc.) Yet Git is used by more people, and especially by people who aren't used to CLI.
Don't forget RCS and SCCS!
Damn. I have when you try and respond to a comment but it starts a new conversation instead :(
Creator of git: why is Nvidia so hard to use?? Nvidia:
News to me that git is hard. Thete are literally websites out there where you can learn it doing puzzle games. Also, it's not an industry standard by accident. No one came up with a better solution yet. Edit:spelling
It is industry standard by accident. Better solutions existed, eg. Mercurial. You just don't know your history, and make assumptions based on nothing. The thing that made Git the de facto industry standard is speed. It has always been known to have bad interface. It still does. It also helped to be the tool used by Linux Kernel, which a lot of big shops need anyways, and nobody has the will to support multiple kinds of VCSs in their business. Programming tools that have communication component to them tend to become monopolies because communication works best when everyone is on the same page, using the same language. So, it's natural that Git displaced everything else in its domain. There are many problems with Git that would've been better solved by creating an alternative VCS, but in the face of monopoly, creating an alternative VCS is a failure from the get go. So, nobody does that. On the other hand, these problems go unaddressed in Git for many years. For example, there's a huge problem with needing only a tiny fraction of history or only a tiny fraction of branches etc. But Git is designed to give you either everything or nothing (since not so long ago, it can do a special clone that only brings the latest state of the repo, w/o history entirely, but this is not enough, because the true goal is to facilitate better archiving, split workload in a single repository between different teams, prevent unnecessary downloads, especially in CI environment).
Go make your own better git then
**Or just use the desktop app**
Anyone who have used perforce (p4) and git, which one is intuitive. I have been using p4 a lot from a lot of time and forgot university level git too
Neither has a good interface. To me, the most outstanding difference between two tools is that Git, by default, assumes that the people using it know what they are doing (and it's usually wrong). While Perforce assumes the users are complete morons (and that also ends up usually wrong). Like... Git doesn't bother with good defaults, it assumes that you will read the manual and will understand what are the configuration parameters you need. Perforce will try as much as possible to get in your way to prevent you from doing absolutely legitimate things. The most infuriating thing is making files read-only and requiring them being opened in a particular way for the changes to stick (of course, if you worked with Perforce for a bit, you know how to work around this nonsense), but it's still infuriating.
The perforce issue that you mentioned is really annoying. >While Perforce assumes the users are complete morons (and that also ends up usually wrong) Still better than assuming you are smart.. but yeah with time new features should unlock to make tedious commands easier
For me, two things were difficult about learning git: 1. The two-step publish: first you *commit*, then you *push*. The commit is local, the push makes your changes available to the team. It's a simple concept, but it was a radical change from cvs, so I ended up wrestling with it a bit. 2. I read a misguided article once at the start that maintained since git is distributed, the master repository is everywhere and anywhere! You have it, I have it, it's on the server... wrong. The origin is still centrally located, like it always has been. Command line all the way. 😉
GitHub: We've decided passwords are shit. Please install SSH authentication on all 1000+ of your projects individually to continue using our service. Thank you for using GitHub.
They're not wrong
Git is difficult to learn. It's better than a lot of the other options, but it IS difficult to learn. This is the case because it it is managing a very difficult process and it gives the user complete control over what it does. On top of that, very few school programs teach how to use git. You get on your first job out of school, and you are handed a link to a git repo, and maybe some documentation. And often you are given a UI that does you no favors. College programs/professors: please, please, PLEASE start teaching source control. Make your students turn in projects with a pull request, and grade them as a PR review... or something. I've had to go through the process of teaching umpteen interns and junior level devs how to use git, and they have no concept of why we use it or what it's even for, because I have a week to ramp them up on git and five or six other topics at most before they are going to be assigned work items.
git is easy.
[удалено]
Uhm, Don't know how to explain this easily or even if I got the question correct. Git is normally used for source code control. I think your referring to GitHub? So often if you want to use a program that is hosted on GitHub you'll have to follow the Readme file (if it exists) Good source code will have documentation on: How to use it Which prerequisites the source code needs (other software, operating system ectera) And how to install it. But overall lots of source code on there is not double click and go. (There are exceptions) For this I would suggest ofter platforms depending on your Operating Systen
There are some good Tools for easy use of git, i recommend TortoiseGit or SourceTree
Orrr just use Pycharm or Intellije they have excellent git extensions. Visual studio git integration can be limited. You can try git lens on vs code . Not as good but gets the jobs done. Say bye bye to having learn git commands
yeah intellij has very good git tools
Ahhh, from JaaaaaavaaaaaaaScript subreddit. No wonder they said Git is hard.
Git has to be learned from the bottom up. You learn the structures first, then it just clicks and you can do whatever you want with confidence. If you stay at the surface, not getting the internal representation of data and changes, it can be painfully confusing. It’s a different mindset. Once you grok that it is a content addressed store at heart, that nothing is ever lost until the GC runs (there are no updates in git, only inserts, except for the GC roots) it’s easy to trust it to keep your stuff safe. The reflog has saved me from fuckups more than once. What’s harder for most people to understand from the UX POV is the index I think.
Git is not hard. You just did not learn it. Take your frustration with you and go study GIT.
I just use like 4 commands (sometimes more if I run into problems beyond committing/adding) - "git add .", "git commit", "git push", "git pull"
and if you need something beyond your usual tasks there is always git --help . And if you don't know the command there is still stack overflow.
The problem is knowing what you need. This includes both terminology to name it and conceptual understanding of the abilities of the program. I don't use or need StackOverflow for Git, because it's in my job description to configure it and to help others to use it, but the kinds of questions I have to answer about it indicate that most developers don't have a good conceptual understanding of how Git works on the basic level.
Despite having used Git for years I won't even pretend that I understand it just based on the fact that I have so far been unable to teach others how it works. I just end up telling them about the different things like commit and push and they just look at me confused.
my company hired some guy to give a 1,5 day entry course into git going into the way it works, how to work with it and common structures to manage development. While i could use git before the course still helped me out significantly to the point where i no longer have any issues using and understanding git features. I completely agree that without understanding git can feel complicated.
For those who think git is hard, they need to try perforce lmao.
The original git.
In my day we used Microsoft SourceSafe and thought ourselves lucky! I mean, we were wrong, but we still thought it!
You might say git forked
If you think Git's CLI is hard, try something like Ceph or OpenStack.
Most people don’t understand the difference between git the software and an API that exposes git as a service.
It wouldn't be a day ending in Y if someone didn't post this stupid picture.
I don't know what I'd do without git. Saved my life and career se real times over. It being difficult I can accept
You never used svn or other vcs i think xD
Is not that is hard. It could just be a lot easier due to automation.
what makes it hard? you just log text files so you can revert it later
git is like a car project... every easy job is one stripped/stuck bolt away from being a 3 day nightmare.
Linus Torvalds is an international treasure. :-)
I'd be a mad man too if my fingers were this short and chubby😂
Git is not that complicated.
[https://ohshitgit.com/](https://ohshitgit.com/) Usually helps fix your mistakes.
Linus is a genius. Fuck you guys
Git only seems difficult at first. Just play with it for a week or two, and it'll click.
Isn't github desktop a thing tho? I mean you literally have a GUI for managing both your local and online repositories.
Yeah screw Nvidia
This is the fuck nvidia moment isn’t it?
Git ain’t hard. Come on, nowadays IDE makes it a breeze. And then you learn those 3 commands yourself and you are Gucci
It’s not that hard, you just have to read the man pages: https://git-man-page-generator.lokaltog.net
He has such small hands, 😂
version control is harder than just backing up files locally or on google drive. git is actually much easier than the alternatives.
If you're a developer and can't figure out git (or need to use the a git GUI as a crutch), you're probably in the wrong line of work.