141–150 of 200 posts
Earlier quoted context omitted.
I think bookmarks are a fine name but I don't really see quibble about branches, which I think are an even better name, but I know it's because I'm seeing it with my git goggles on. Can you elaborate on what you think branches are a better reference to? What operations or concepts are better expressed in terms of them? I think I'm at the edge of an epiphany here ... but I'm not quite groking it yet.
The issue is the "named" bit of the definition, more precisely "named sequence". A commit is as much a branch as a head of a linked list is both a node and a list. I think 'branch' is fine.
Earlier quoted context omitted.
> if you do 'git checkout [path]' The entire point of that command is to discard local changes. There is some risk of getting the different forms of checkout mixed up, though, so prefer using switch and restore instead. As far as I know, the only use case of checkout not covered by other commands is checking out a commit that doesn’t have a branch attached to it.
> The entire point of that command is to discard local changes. I think that's arguable, but it's neither here nor there. Someone who is not well versed in git arcana will be surprised that the level of risk associated with 'git checkout [branch]' is radically different from 'git checkout [directory]'. I think a lot of people will learn this the hard way, especially if they have been told "It is very hard to permanen…
> But if you try to understand the commands without the model, you will suffer, because the commands do not make sense. I've read this about git several times and certainly felt it. My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation. Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc? This seems like a similar situati…
> My question is why hasn't anyone come along and fixed it? Because the model is simple and easy to understand, and you get a lot of power from understanding it. Whereas opinionated porcelain that tries to insulate the user from the model will tend to fail in obnoxious ways and will not serve the user. Really, there's objects, there's commits, then there's a couple of methods for symbolically naming commits (branches…
The problems with git are not the commits and the DAG. It's all the ancillary stuff that's inconsistent and confusing.
I'm not a fan of this mythos around Git's complexity. It is simply a DAG, a bunch of references to nodes in that graph, and a stack of commands that let you make any modification to that system you so desire. If you just learn the mapping of those concepts to Git's vocabulary, you really don't need to memorize all the commands. In the odd case, you can just look up the docs. Nodes are commits, references are either b…
1. If I've partially staged some changes, why can't I stash and unstash them and get back to the same state?
2. How come stashes are sort of like commits but sort of not? I've managed to get into a state where I had a stash that couldn't be popped because it was in the wrong format - how can I tell when this will or won't happen?
Earlier quoted context omitted.
> My question is why hasn't anyone come along and fixed it? Because the model is simple and easy to understand, and you get a lot of power from understanding it. Whereas opinionated porcelain that tries to insulate the user from the model will tend to fail in obnoxious ways and will not serve the user. Really, there's objects, there's commits, then there's a couple of methods for symbolically naming commits (branches…
If I've partially staged some changes, why can't I stash and unstash them and get back to the same state? The problems with git are not the commits and the DAG. It's all the ancillary stuff that's inconsistent and confusing.
> But if you try to understand the commands without the model, you will suffer, because the commands do not make sense. I've read this about git several times and certainly felt it. My question is why hasn't anyone come along and fixed it? Git has the plumbing vs. porcelain separation. Why hasn't someone written new porcelain that makes git as intuitive as mercurial, subversion, etc? This seems like a similar situati…
> My question is why hasn't anyone come along and fixed it? Because the model is simple and easy to understand, and you get a lot of power from understanding it. Whereas opinionated porcelain that tries to insulate the user from the model will tend to fail in obnoxious ways and will not serve the user. Really, there's objects, there's commits, then there's a couple of methods for symbolically naming commits (branches…
Earlier quoted context omitted.
Mind if I ask what Git did better? The main selling point for the difference between them was the Linus, Linux and then the whole community chose Git. The only big difference I recall Git winning on was in third party tooling and Git supporting more than two parents merging.
Git wasn't really winning until GitHub emerged. The game was still open at that point. Once GH had resoundingly beat the competition for "social coding" (like bitbucket and sourceforge), though, it was all over.
Earlier quoted context omitted.
just to spell it out fully for dear reader: that's how merge commits work.
and Just for fun, sometimes it can be as big as 66, meet Cthulhu merge [1] 1. https://lkml.org/lkml/2014/1/21/361
Graph log visualisation was certainly fairly difficult to make much of, but it wasn’t generally intended to be made much of, since it was basically a deployment implementation detail.
Earlier quoted context omitted.
Sure but then why do they describe the term wrong in the first paragraph? That's just adding to the confusion they intend to fight. I'm not sure the author is reading this, but think it's worth rewording.
I'm reading it and I think I got it right. The Git community, the Git documentation, and the Git tools all refer to "branches", and I think what they mean when they talk about "branches" is much closer to what I described than to what you did. For example, consider this very ordinary-sounding phrase that I just picked out of the git-rebase man page: > If the upstream branch already contains a change you have made … I…
Obviously, and if you got the idea that I thought you did then I apologize for that.
Anyway, the git docs aren't exactly known for getting the nuances of its own concepts right, which adds to the general confusion.
That said, I think I see your point now: it's the same as how a reference to a linked list is actually just the head of the linked list, but you still call it a list and not a head.
I have to admit that maybe I didn't see the forest for the trees.