161–170 of 490 posts
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.
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…
Take a look at https://eagain.net/articles/git-for-computer-scientists/ ? Maybe you've already read it, but this is what let me grok the underlying data.
It's just that the command-line interface is very opaque regarding what it does to that data.
For instance, say I want to apply the last three commits I made in one branch to another branch. It's a very simple operation conceptually.
Good luck remembering that the command that does it is rebase, and what the arguments for it are.
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…
I understand how git works, and I still can't use it. There are three problems: 1. Despite the claim that git never loses data, there are actually some dangerous operations that will irretrievably nuke your work with no warning. Git checkout is the canonical example. This makes me very gun-shy about doing anything that I'm not intimately familiar with. 2. Git's merge is not smart enough to realize that identical chan…
Git should store the commands that "did" the operations on a repo. Git should never ever let you lose work. I should always be able to go "backward" and recover previous states. I guess that is what the "Git undo" proposal is about. I'm a very visual person so I tend to use Git Graph on VSCode. But I still get in trouble. Especially things like Cherry Picking, or reverting. Another thing that is not so easy is switch…
is `git reflog` not enough for your use case ?
Earlier quoted context omitted.
Bitbucket had a much crappier UI.
Actually, one of the reasons I preferred hg to git is that Windows explorer GUI integration back then was far superior to gits, which was buggy as hell.
Having used Bitbucket and GitHub, I think GH is much nicer - both in the sense of basic stuff like page loads being faster, and in terms of features. And since it's the main tool that everyone on the development team spends their time on for communication & collaboration, those things really matter.
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.
Earlier quoted context omitted.
For some reason people love to defend the obscure and strange and oftentimes objectively terrible Git CLI. I’ve found Mercurial much more straightforward for my (mundane and boring but prevalent) use cases, and I lament that it isn’t more widely used.
Every single time we are discussing git this comment shows up. But why is one popular when the other one is so much better? I guess we will never know
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…
can you explain the `git pull origin master` thing one more time here?
`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 that ref on the remote.
All other commands operate only on these local references. So when you want to refer to what you know to be the state of things on `origin`, you can use `origin/master`. Otherwise that command has no particular knowledge of how to talk to origin.
Incidentally this is a shortcut I use all the time to update my local master from a remote:
`git fetch origin master:master`
Which is super unclear in its meaning but it means fetch origin's master HEAD and put it in my local master ref. I actually use this more often than git pull nowadays.
Earlier quoted context omitted.
Yeah, this barely scratches the surface though. Take branching, which is something you're supposed to be doing all the time. So abstractly, I want to be able to get a list of my current branches, create a new branch, check out an existing branch, delete an existing branch, and maybe rename a branch. I would expect the commands for these operations to be something like: git branch list git branch create [name] git bra…
> "git branch create" is "git branch [name]". I've been using Git professionally for of a decade and you just taught me something new. I always use `git checkout -b [name]` (which is a completely bananas UX, but it's the one I know).