31–40 of 273 posts
To understand the data structures interactively, use "git cat-file -p HEAD" and continue drilling down to an individual file in a subdirectory with "git cat-file -p OBJECTHASH"
Personally, I think using git from the commandline is too complicated for the purpose it serves in most companies. Using a git GUI works quite well for people inexperienced with git.
For example, I've never had any problems with Mercurial. Everything just works there and it is intuitive. You can never lose data there, and it has extremely sensible defaults.
Earlier quoted context omitted.
Isn't the staging area closer to an intermediary box? That's where it can get confusing.
Staging puts things in the box, commit closes the box, puts it on the pile with the other boxes, and gives you a new empty staging box.
Personally, I think using git from the commandline is too complicated for the purpose it serves in most companies. Using a git GUI works quite well for people inexperienced with git.
Even for experienced people, I rather spend my time on GUI tools and only drop into the CLI on as needed basis. From UI/UX point of view, developers are users as well, but many seem to think developers should put up with bad interfaces.
Earlier quoted context omitted.
> WHY there is a staging area I understand your second point, but I have a hard time understanding the difficulty with this part. Why is it hard for people to understand the idea of staging? You put things in a box one at a time before closing the box. Does it require more explanation than that? What do people find difficult about it?
So I have a solid mental of git, and I understand the theoretical need for the staging area. However, I find the occasions for using the staging area in practice are few and far between, for the simple reason that I can't test and execute the code that's in the staging area without also having the code from the working directory also be there. It feels like after having partially staged some of my working directory,…
Earlier quoted context omitted.
> WHY there is a staging area I understand your second point, but I have a hard time understanding the difficulty with this part. Why is it hard for people to understand the idea of staging? You put things in a box one at a time before closing the box. Does it require more explanation than that? What do people find difficult about it?
People are very used to the web "save always" style: There is one document, and you're editing it. Most people will be familiar with the traditional desktop "save" model where you have to do something to make your changes permanent. People often then learn that there is a local file and some remote file: they can cope with a save -> upload workflow. Lots of traditional VCS turn this into a save -> commit workflow. Gi…
It's also very important to learn to use the reflog. When I was learning to climb they told me I'd never get really good until I'd fallen once. The same thing goes for git. People are really scared of it because they think they could lose work or something. Thanks to the reflog and the way git works, that's actually quite difficult to do.
I found this very helpful: http://eagain.net/articles/git-for-computer-scientists/ . Git's data structures are well designed. Once you have internalized them, you will be better equipped to navigate through the jungle of command-line options. To understand the data structures interactively, use "git cat-file -p HEAD" and continue drilling down to an individual file in a subdirectory with "git cat-file -p OBJECTHASH "