251–260 of 821 posts
I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…
Earlier quoted context omitted.
Yeah this is incorrect. One of the reasons that we able to achieve so much with computers is that there is a separation of concerns between different areas. Requiring everyone to fully understand git is like requiring people who code in high-level languages to understand and apply chip design in their day-to-day work. Imagine if when you tested some Python or Java code you got an error from your CPU and needed to tak…
>I could say more about what you would do to make a better version but a comment isn't the place for that. I'd be very interested because it's rare for me to see anyone attempt and, when I do, they break a basic use case.
Insanely complicated commands to undo things are one symptom of this.
As a user, you want to "save" some code and you also want to "share" it with others. You also want a historical record of what you did.
But obviously you will occasionally save and share things you didn't mean to. Like your Python virtual environment, like a bunch of pictures in their binary format, etc.
A sane version control would provide a point-and-click way to make these disappear from history (though with adequate security protections to make sure that only authorized people can do it).
Earlier quoted context omitted.
+1. The very first question: >Oh, I just pushed a change. I really didn’t wanna push that, so how do I undo it? Is a Github problem, not a git problem. You might as well ask how to unsend an email. If you don't know what git push means, you shouldn't be using it and are playing with intellectual property fire. The conflation of Github with git is responsible for a lot of confusion. Having Github be your first interac…
Right, it's also because github guides people into a history-only flow instead of rebase / force-push. Casual github users know they should follow the tree with pull and don't know what fetch is. With history if you make a vcs mistake, or realize iteratively after pushing that corrections are needed, your worthless threshing around trying to fix it becomes part of your project log forever, instead of just pushing the…
Earlier quoted context omitted.
> Git is an object database and its objects are blobs, trees and commits not diffs What do you think is the difference between a "commit" and a "diff"?
A "commit" doesn't contain a diff, it contains (references to) the blobs of the files at that state. Diffs are display-only, generated by comparing two full file states.
Arguments against git being 'too hard' seem to fall into these categories: * It's not actually hard. ** You don't understand it. Everyone else is fine with it. You just haven't spent the time to understand it like everyone else has. ** Ok maybe lots of people don't understand it. They just haven't spent the time to understand it like I and others have. * It is actually hard. ** You're not intelligent enough to unders…
Ask your manager, which problem is the problem for him.
Git is hard because it precisely models the complexities of concurrently modifying source code on multiple computers. It explicitly models all of the concepts and operations that are relevant in that domain - branching, merging, my local changes, the server that my local branch is kept in sync with, rewriting local history, rewriting public history. Can you shoot yourself in the foot? Absolutely, because this stuff r…
Why can't there be an equivalent of stash that keeps track of which parts were added and which weren't? If switching branches wouldn't conflict with my current change, why do I have to stash/checkout/unstash instead of just doing it? Why can't I pull without fetching? Why will none of the 5 or so push configurations just do "push the current branch to the branch of the same name on the remote"? Why is there no way to…
But git stash does keep track of what it added?
> If switching branches wouldn't conflict with my current change, why do I have to stash/checkout/unstash instead of just doing it?
If your current changes apply to files which haven't changed between said branches, you don't need to stash your changes when switching between them.
> Why can't I pull without fetching?
The command for that is `git merge`.
> Why will none of the 5 or so push configurations just do "push the current branch to the branch of the same name on the remote"?
The command for that is `git push origin HEAD`.
> Why is there no way to stop git from setting master as the upstream every time I do git checkout -b myfeature origin/master?
The option for that is `--no-track`.
> Why do I have to detach from a branch before deleting it?
Because the `git branch` command never changes the working tree, which in this case uses the branch name to identify its location. If the branch were to be deleted without first detaching (or switching to a different branch), stuff would break.
Please read through the first few chapters of the official git tutorial[1]. Once you get the mental model right, git is immensely simple to use.
I highly recommend sticking with the command line.
Github on the other hand, was designed to solve a whole different problem.
FWIW if you're on Linux (unsure about Windows and Mac), I happen to have zsh and oh-my-zsh[2] installed. They add a ton of incredibly useful git aliases. So for example, seeing a tree view of your project is a simple `gloga` command. Helps by not having to remember the equivalent full command that gives you the same result.
Except this one:
>> I will get you to think about a directed graph or as operations on a directed graph
> No human thinks about that!
Well, that's not wrong, people don't usually think like that, but people also don't usually think about possible specimens living in some forest during a hike, or the odds and the reasons why a given storm could become a hurricane when they read about it in the news, or all the most likely reasons why a given body part might be hurting. No, those are thought by zoologists, meteorologists and physicians, respectively.
With that in mind, I see thinking about graphs and other areas more complex of version control as being, similarly, part of the job and the cognitive load of software engineers.
In short: People don't usually think like that, but, in my opinion, thinking like that is part of a software engineer's job, so I don't see an inherent problem with that.
The underlying technology of git is great, but the UX is terrible. The commands are all named wrong. "To create a branch, use git branch, but that doesn't check it out. If you want to create it and check it out at the same time use "git checkout -b", not "git branch --checkout" which would be 1000x more logical (and then there could be an option to make that the default behaviour) Resisting GUI's is not a good idea.…
I don't agree at all. Git is the simplest version control system I've ever used. The concept of merging, rebasing, cherry-picking, and resetting works so naturally that I'm basically going to expect this level of ease of use from any VCS I use going forward. That being said, I know there are some who have trouble with Git. But IMO it isn't because Git is hard, but because they don't have to truly understand Git to us…
>But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is. A copy&paste of my previous comment: Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git CLI (the "porcelain"). Yes, I know that Git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file forma…
This sounds like you just don't use or need those things much, which is fine if it works for you. Of the top 10, I can answer 9 of them without doing any research because I've used these commands a lot and they've become a part of my workflow. The one I'm missing? I've never renamed a git branch. If I needed to, I'd probably just do git branch --help or google it and figure it out in five seconds.
You don't need to commit every command of the program to memory. Just like anything else in tech, knowing how to find the knowledge you need is good enough.