361–370 of 490 posts
Any other recommendations for CLI tools? I've gotten kind of familiar with the Git CLI. But it took a lot of wasted hours and headaches to do so, and even now it takes headaches and extra time / effort to do certain things like rewrite history and "good" commits. I still prefer CLI to GUI but I wish it was more intuitive.
Earlier quoted context omitted.
> levels of state This is the crux for me. Command naming is completely unrelated to and unindicative of state. It feels like surely there's an opportunity for the basic CRUD operations to be collapsed down into a standard "{action} {source} {target}" style. There will be nuances, specifically around branching, but the basics should be basic. As opposed to a Swiss Army knife, where you have to pull out the scissors a…
Are there any git frontends that do this today?
Great work. I wish usability/ergonomy was taken more seriously for popular tools that everyone uses (like git). Another stupid pain point with git is the inability to commit empty directories. I mean, come on.
Git takes stability and extensibility seriously. Your demands and expectations on version control may be radically different from mine. Empty directories do not contain files or information, it's entirely reasonable for a VCS to omit such a feature. Not sure which use case for git is hindered by the inability to check-in empty directories. I would even suggest such a use-case may be a case of DIW
We could easily get into arguments over the specific uses of committing empty directories against the difference it ends up making in terms of stability and extensibility. Instead, consider that: 1) this behavior is very surprising, and 2) it offers no advantages to users, only disadvantages to some. Hence, it is unergonomic. My complaint was precisely that for extremely popular tools (such as git), it is worthwhile in general to sacrifice ease of implementation for ease of use, because the developper effort is amortized over the number of users.
Earlier quoted context omitted.
Git is immutable. The only thing that isn't is your working directory.
How do people lose their work so easily with Git then?
On top of this, various git commands can delete things you've done in the working directory without any confirmation or warning (e.g. "git checkout [filename]"). And of course, so can various non-git commands (e.g. "rm [filename]"). If that happens, the work is permanently lost if there isn't another backup mechanism in place.
So they're not wrong, but the second sentence's implications are kind of glossed over. It's always confused me that git lets you lose work so easily, so a very long time ago I've always just made sure to put all of my programming projects in a Dropbox folder. I rarely mess anything up that badly with git, but for the few times I have, Dropbox version history has definitely saved me.
Earlier quoted context omitted.
definitely agree, and I'm in the same boat. I don't even think the data model of git is that hard to grok at all, it's mostly that commands are very unclear on what they operate on and in particular people get really tripped up about how many levels of state there are (stage, working tree, local branches, remote refs) that they have to interact with. Like, I've had to explain a lot of times why you `git pull origin m…
> levels of state This is the crux for me. Command naming is completely unrelated to and unindicative of state. It feels like surely there's an opportunity for the basic CRUD operations to be collapsed down into a standard "{action} {source} {target}" style. There will be nuances, specifically around branching, but the basics should be basic. As opposed to a Swiss Army knife, where you have to pull out the scissors a…
Earlier quoted context omitted.
I know (or, at least, have known ) how git works, in the way most people mean that (the data structures & on-disk layout, what a commit is, what a tag is, what a branch is, what HEAD is, staging, et c.). What I can't keep straight is WTF the commands are actually doing, in that low-level sense, which is a different thing, and there's approximately a 0% chance I'm ever going to use more than a tiny fraction of the com…
Maybe for low-level, somewhat rare tasks the ideal Git porcelain would be a GUI that just exposes the data model directly.
I'm the guy people go to fix Git screw ups at my jobs but I just click a few buttons or drag a few commits...
Earlier quoted context omitted.
like why it's different? `git fetch` (and by extension `git pull` when given a remote) and `git push` copy data to and from a remote. When you specify `git pull origin master` you're saying "pull down a copy of the remote ref master from origin", which it then saves locally as the ref `origin/master`. Everything under `origin/ ` (or really `refs/heads/origin/ `) is just a cached pointer to the last known state of tha…
so the distinction here is - origin master - origin/master <=== a local branch that you cached from the "origin master" remote, may or may not be in sync with the real "origin master"
`git pull remote_repository_name branch_name` is the generic way to look at it instead of some magic incantation.
I like to call origin "upstream" to differentiate them.
and then git pull is another way to think of git fetch and git merge as one command roughly.
Earlier quoted context omitted.
I was replying to this part of your comment: > Usually my response is if you use something daily, and you know you lack the skills to use it effectively, why don't you improve your knowledge and seek out training or education? Seeking out that training would be useless since I don't use git enough. > Maybe git isn't the right tool for you? Git is definitely the tool for me. It's better than any other available tool f…
This is just retarded. You don't want branching and you still think git is the tool for you? Compared to say svn? Honestly, use svn, its the better tool for your use case. You don't have to use git. Don't gaslight me by saying you don't need gits main feature and then suggest I'm gstekeeping, I'm not, youre welcome to use git, just don't complain about your lack of ability to RTFM.
I use a modified gitflow. The article and this thread are about how when you get into trouble, git quickly becomes complicated. It’s not about branching being too hard or whatever you turned this conversation into in your head.
Git is one of those bizarre products that has remained a leader in its category for almost a decade while being extremely difficult to use, even for experts. Another one of these products is Apache. Why is this? At least from my naive point of view I would expect these extremely user-hostile products to have been overtaken but more user-friendly alternatives. I know the best products don't always win, but when they d…