Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding Git for real by exploring the .git directory

medium.com

Post reply on HN
Print view View original

61–70 of 92 posts

Re: Understanding Git for real by exploring the .git directory

#61

Post by icebraining »

EvanPlaice wrote: post #55
tuxracer wrote: post #29

Earlier quoted context omitted.

You can also commit specific lines using `git add -p`

It's much easier when you can see all of the staged/unstaged files and drill down to staging/unstaging individual lines within those files. It also highlights whitespace nastiness (ie trailing spaces, missing newline at end of file, inconsistent newline chars, etc). The CLI is the ideal too for a lot of things. Preparing commits is not one of them.

You can see all the files and drill down with "git add -i". Git also highlights whitespace problems.

Re: Understanding Git for real by exploring the .git directory

#62

Post by ricardolopes »

rolfvandekrol wrote: post #52

The article claims to be aimed a beginners: "There are a lot of posts out there about learning the basic commands of git, this is not one of them. What I’m going to try here is a different approach." The article rings a lot of bells because I actually do understand how Git works. I'm not so sure it is understandable by someone who is new to git. The second sentence of the actual tutorial part: "When you create a git…

That's unfortunately the problem with most tutorials: they just assume you have all the required knowledge. It's hard to make good learning material.

Re: Understanding Git for real by exploring the .git directory

#63

Post by Biganon »

crispyambulance wrote: post #58
forrestthewoods wrote: post #17

How 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.

Indeed, the miracle here is how git got so popular. It has _NOTHING_ to do with meeting needs or doing things spectacularly better than other tools. There was version control before git and it worked just fine. I just think some "cool kids" started using it, it developed a certain Caché that made it desirable and that was it: here we are with the most popular version control system in the world with an absolutely shi…

Cachet

Re: Understanding Git for real by exploring the .git directory

#64

Post by obelisk_ »

rolfvandekrol wrote: post #52

The article claims to be aimed a beginners: "There are a lot of posts out there about learning the basic commands of git, this is not one of them. What I’m going to try here is a different approach." The article rings a lot of bells because I actually do understand how Git works. I'm not so sure it is understandable by someone who is new to git. The second sentence of the actual tutorial part: "When you create a git…

When I was still quite new to git, I attended a presentation based on The Git Parable.

I found it to be an enlightening talk and it helped me understand git better than what I had until then.

Re: Understanding Git for real by exploring the .git directory

#65

Post by gechr »

grayclhn wrote: post #47
fla wrote: post #45

Earlier quoted context omitted.

For some time now, we use the rebase workflow. (create your branch, do some work, rebase on master, push). It is a great way to have a clean linear history. But it makes git pull 'illegal' because it does a merge implicitely. That's tipically something I didn't think about the first times I used git.

git pull --rebase doesn't merge implicitly and git config --global pull.rebase true will set that as the default `pull` behavior.

Note that

  git config --global pull.rebase true
was added in v1.7.9 - if you're using an earlier version of Git for whatever reason, the config you should be setting is

  git config --global branch.autosetuprebase always

Re: Understanding Git for real by exploring the .git directory

#66

Post by chrisweekly »

the4dpatrick wrote: post #43
n0us wrote: post #25

Earlier 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.

This is still my git workflow. Aside from the off times I have to rebase or revert a commit. I'm curious as what git commands you've found the most valuable or you've used the most since digging deeper into git.

a couple things helped me get into a comfortable flow w/ git: realizing git stash creates a commit (accessible via git reflog show stash). v helpful for managing interrupts, and gaining confidence you're not going to lose any work.

also, learning to be quick to create (and dispose of) branches, as they're just names.

Re: Understanding Git for real by exploring the .git directory

#67

Post by Kaotique »

The CLI is a complete mystery and that makes it hard to explain to people. Most of the commands and arguments differ so much that it makes little sense. Delete a branch, commit or tag in a similar way; the commands to do this are totally different.

How Git works can be easily drawn out on paper to explain it to someone. The branches, commits and merges is simple to draw.

When we lose sense of our state we always take a piece of paper and draw it out. Most of the time you can just figure it out what's up.

Re: Understanding Git for real by exploring the .git directory

#68

Post by matt4077 »

Kaotique wrote: post #67

The CLI is a complete mystery and that makes it hard to explain to people. Most of the commands and arguments differ so much that it makes little sense. Delete a branch, commit or tag in a similar way; the commands to do this are totally different. How Git works can be easily drawn out on paper to explain it to someone. The branches, commits and merges is simple to draw. When we lose sense of our state we always take…

Yeah, I used to race through svn workflows without a second thought. With svn, I still don't understand how to (just one example) throw away all the local changes. (No, not git reset --hard. At least that didn't work when I last tried).

It came to the point where I thought about spending a week just learning git to defend my berd creds.

Instead, I just use a gui for anything beyond add/comit/push. I still don't like not to understand one of my daily tools, but I have real work to do.

Re: Understanding Git for real by exploring the .git directory

#69

Post by vlunkr »

icelancer wrote: post #32
n0us wrote: post #25

Earlier 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.

Ah yes, the "subversion" method of using git. ... I also do this. :|

Also the method that gets logging, debuggers and temp files committed by accident.

Re: Understanding Git for real by exploring the .git directory

#70

Post by patrickaljord »

chrisweekly wrote: post #66
the4dpatrick wrote: post #43

Earlier quoted context omitted.

This is still my git workflow. Aside from the off times I have to rebase or revert a commit. I'm curious as what git commands you've found the most valuable or you've used the most since digging deeper into git.

a couple things helped me get into a comfortable flow w/ git: realizing git stash creates a commit (accessible via git reflog show stash). v helpful for managing interrupts, and gaining confidence you're not going to lose any work. also, learning to be quick to create (and dispose of) branches, as they're just names.

> accessible via git reflog show stash

You can just do "git stash list".

Post reply on HN