You see 3 hash right. So one would be for my file_1.txt, the other would be for the snapshot created when I commited. What is the third one ? Well because a commit is an object in itself, it is also compressed and stored in the object folder.
Understanding Git for real by exploring the .git directory
21–30 of 92 posts
Re: Understanding Git for real by exploring the .git directory
#22I worked with someone whose approach was very interesting: he committed the .git directory of a newly initialized repo to a separate, newly initialized repo. And then watched what changed when he added a file, changed things, branched, etc, in the committed .git directory. It's always seemed worthwhile to me to dig into git's model more, but if you're already comfortable and productive with stuff like detached head/r…
I missed the part where that was interesting
Re: Understanding Git for real by exploring the .git directory
#23How many "Understanding Git" posts have hit #1 on Hacker News? More than a few. How many have hit top 10? Surely dozens. Can we, please, take this as an indicator that Git is too fucking complicated? After the first thousand "Git made easy" blog posts it should have been apparent. Le sigh.
But maybe everyone agrees that it's too complicated but it's used. You know, English is way too complicated, but you can't just make everyone switch to Esperanto. People are interested in things that help people understand English and things that help people understand Git.
Re: Understanding Git for real by exploring the .git directory
#24The most inscrutable part of Git is rebasing and how it works. It took me really long to form a mental model where I can visualise how it does its job.
I agree with the author that understanding how Git works is the only way to get comfortable with it. For eg, Rebasing is hard but you will have your "Aha!" moment when you realise that it is nothing but a combination of hard reset and cherry-pick
Re: Understanding Git for real by exploring the .git directory
#25I worked with someone whose approach was very interesting: he committed the .git directory of a newly initialized repo to a separate, newly initialized repo. And then watched what changed when he added a file, changed things, branched, etc, in the committed .git directory. It's always seemed worthwhile to me to dig into git's model more, but if you're already comfortable and productive with stuff like detached head/r…
for about six months my git workflow was this:
git add -A
git commit -am "fixed some stuff"
but I've finally found some time to start digging into how to really use it.
The issue I have with it is that if you step outside the basics it's so easy to get yourself into a thorn bush and the way that git is explained most places is really not intuitive at all.
Re: Understanding Git for real by exploring the .git directory
#26I have read enough of all these tutorials that I understand how git and the git commands work. I could pass a test. But still I have a hard time feeling comfortable enough to spit out commands as needed. I've created a lot of aliases to do common things but that is not the same thing.
Re: Understanding Git for real by exploring the .git directory
#27I worked with someone whose approach was very interesting: he committed the .git directory of a newly initialized repo to a separate, newly initialized repo. And then watched what changed when he added a file, changed things, branched, etc, in the committed .git directory. It's always seemed worthwhile to me to dig into git's model more, but if you're already comfortable and productive with stuff like detached head/r…
for about six months my git workflow was this: git add -A git commit -am "fixed some stuff" but I've finally found some time to start digging into how to really use it. The issue I have with it is that if you step outside the basics it's so easy to get yourself into a thorn bush and the way that git is explained most places is really not intuitive at all.
Try using a tool like 'git cola' that allows you to selectively commit soecific lines, instead of just by file.
Start a project and attempt to maintain a clean history. Break up changes logically into separate commits. To the point where 90%+ don't need more than the subject to describe a change and the history can be read like a story.
Use 'gitk --all' to view the tree of changes. get comfortable with using feature branches, using interactive rebasing to clean up a messy history of changes, etc.
The CLI works great for most things but visual tools make it much easier to write a clean history and reason about the changes over time.
Re: Understanding Git for real by exploring the .git directory
#28I've been using git at work for a couple of years and I haven't spent very much time thinking about the internals at all. It just seems to work pretty much, though sometimes I get into a weird state and just delete and redownload.
You should never have to redownload unless somebody is carelessly force oushing changes to the remote.
If you're about to do something 'weird' like fix a merge conflict, you can save the changes by creating a branch.
Sometimes you have to go back and fix a previous commit to reconcile a conflict. The 'gitk --all' command is your friend here. With it it's easy to visualize the history, reset, cherry-pick commits, etc.
Re: Understanding Git for real by exploring the .git directory
#29Earlier quoted context omitted.
for about six months my git workflow was this: git add -A git commit -am "fixed some stuff" but I've finally found some time to start digging into how to really use it. The issue I have with it is that if you step outside the basics it's so easy to get yourself into a thorn bush and the way that git is explained most places is really not intuitive at all.
Try using a tool like 'git cola' that allows you to selectively commit soecific lines, instead of just by file. Start a project and attempt to maintain a clean history. Break up changes logically into separate commits. To the point where 90%+ don't need more than the subject to describe a change and the history can be read like a story. Use 'gitk --all' to view the tree of changes. get comfortable with using feature…
You can also commit specific lines using `git add -p`
Re: Understanding Git for real by exploring the .git directory
#30Earlier quoted context omitted.
Try using a tool like 'git cola' that allows you to selectively commit soecific lines, instead of just by file. Start a project and attempt to maintain a clean history. Break up changes logically into separate commits. To the point where 90%+ don't need more than the subject to describe a change and the history can be read like a story. Use 'gitk --all' to view the tree of changes. get comfortable with using feature…
You can also commit specific lines using `git add -p`
Adding on to your helpful comment, you can also get a more concise, gitk-like graph of commits with `git log --graph`. This is my standard alias for viewing history, which also adds colors and tag/branch names:
lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %C(magenta)(%cn)%Creset %Cgreen(%cr)%Creset' --abbrev-commit --date=relative --left-right