421–430 of 490 posts
Git is hard to use mostly due to "clean commit history" cargo culting. The commands that cause the most trouble are the command that re-write history, and there really is never a good reason to use them beyond "I want my commit history to look like a line".
I don't understand. You can always restore any previous state using git, I used to do it from the command line. If I use github desktop I can roll back a commit whenever I like with a simple menu command. What am I missing here. I feel like I don't understand what the tool is doing.
If you understand the fundamentals of a version control system I find git relatively intuitive to use. Sometimes I don’t know the exact cli syntax for a complicated procedure but that’s easy enough to figure out if you know the concepts. Most people fail to learn the concepts and then try to brute force everything.
Earlier quoted context omitted.
If it's an issue of having to read the docs or the man, well I've been at work like this for a little over a decade and I still have to pull up a reference when I want to do something nontrivial in, not only git, but pretty much every cli tool I use on a regular basis. Cli tools, frameworks, libraries, languages... I have to pull up a reference for everything I do as a programmer, so it's hard for me to muster up the…
`git add ` Wait, how do I remove it from staging? It seems there should be some symmetric operation, `git remove ` or something. Maybe git rm ` `, whoa don't do that. No, it is `git reset HEAD -- `. There is no mental symmetry. Or why use add at all? What am I adding it to? It is so generic, why not `git stage file` and `git unstage file`? I agree that you need to read and learn tools, but there is a lack of consiste…
(use "git restore --staged ..." to unstage)This seems like putting a training wheel on a training wheel. git is already the easiest to understand of any VCS that I've used, and it's somewhat hard to do something in git that can't be reversed. As the articles states, it's unlikely you'll ever lose your changes. Further, this doesn't seem to be that different of a concept from git reset, so why not learn reset instead of yet another command?
> git is already the easiest to understand of any VCS that I've used Breaks down in uproarious laughter. One of the worst offenses git is its use of multiple different jargon terms for the same concept; indeed, it's the only VCS I've used where reading help leaves me less sure than when I started if it does what I want it to do. If I accidentally leave my system in a weird state (say, I'm in the middle of a git rebas…
I think Mercurial is way ahead of Git on this department by having repositories immutable by default, so even undo actions would have their commit. You never find yourself in an unrecoverable situation. Advanced mutable features can only be accessed by making configuration changes, and are still safe to use because public changesets are differentiated from draft changesets, so, you can only make changes on your own w…
Sounds like mercurial repos would have a lot of "noise" with that approach - commits for fixing other commits spamming everywhere
Earlier quoted context omitted.
That's nice, but most of us here are version control consumers, not version control professionals. We need something that has very few knobs to turn because our job is focused around delivering value through other tasks. Git is highly professionalized. It has layers of modal state. That is built into the operating model. It is made for Linus Torvalds, a professional merger of code. If you are using all of those comma…
This is such a strange attitude to source control as a developer. It's literally the most important tool a developer will use second only to an editor. And again, maybe git is the wrong tool for you, that was kind of my point, use cvs or svn it's much closer to what you seem to want.
Some sort of basic version control is definitely important.
Earlier quoted context omitted.
Because, as the parent poster said, everything is immutable except the working directory. The working directory is the default place where all the work is done, as the name suggests. You have to explicitly move things from the working directory to the other areas in order for git to recognize it; the default is "do nothing". On top of this, various git commands can delete things you've done in the working directory w…
They are wrong, there are actions you can take in git that will cause you to lose your "immutable" history. Most accidental cases probably involve `git reset` or `git rebase`, but here's an example if you want to do it intentionally: # Commit all changes and push to at least one remote so your changes are ""immutable"" rm -rf myrepo/ mkdir example && cd example git init # Repeat for each remote git remote add remote1…
Earlier quoted context omitted.
can you explain the `git pull origin master` thing one more time here?
I don't think using `git pull` is a particular good way of working. A pull is a fetch and merge or a rebase combined. If it's difficult to keep your mental model of some system up to date, I doubt that doing bigger steps at once makes things easier. So 1. run `git fetch` 2. if the textual output does not tell you what has happened, run `gitk -all` 3. Decide what to do. Rebase, merge, whatever. Of course if you know e…
Essentially the whole concept of "upstream" is weird and non-orthogonal. Another one that bothers me is that as far as I can see there's no way to globally turn off setting an upstream on newly created branches (I can pass a flag to the specific "git branch" command, but that's tedious and error-prone).
Damn, this is such a GREAT idea. I've messed up repos a few times, and it's never good. It's always -- "what's the magic want I have to wave now"? The truth is, while we use git every day, most people really don't understand how it works. There I said it. And I'm not ashamed. I don't really know how Git works. And I think I'm not the only one. What does "git reflog" or "git reset --hard ...." do? What are the implica…
FYI: `git reflog` saves your ass when you accidentally delete a branch locally, only to then realize there were valuable commits yet to be pushed to master! How it does it is another matter.
Systems enabling high usefulness with little education (i.e. shallow learning curve, at least initially) and then incremental education are ideal. This isn't essential, just desirable. Git can err a little on the steep learning curve/mystery black box side of things a bit. But it is still a damn fine tool.