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

Things I wish everyone knew about Git (Part II)

blog.plover.com

Post reply on HN
Print view View original

11–20 of 148 posts

Re: Things I wish everyone knew about Git (Part II)

#11

Post by rob74 »

My thoughts on this:

- even after years of working with git, I'm still not familiar with all the dark corners I can get myself into by running the wrong command at the wrong time. Yes, most of the time my changes are still there, but the way back to the state I actually want for my repository may be long, complicated and require lots of googling/asking around.

- as the article mentions, git cares a lot about stuff that has been committed, but not so much about the files in your working directory. Because of that, IDEs that keep a local history of your file system changes (like the JetBrains products) are really helpful. "Commit early, commit often" may save you from this, but produces more noise in the repo (which you can reduce by squashing commits, but that's extra effort) and may make it harder to find things - and I guess that goes double if you follow the suggestion of committing changes automatically "every few minutes". The local history is there when you need it and gets out of the way when you don't.

Re: Things I wish everyone knew about Git (Part II)

#12

Post by rocqua »

rob74 wrote: post #11

My thoughts on this: - even after years of working with git, I'm still not familiar with all the dark corners I can get myself into by running the wrong command at the wrong time. Yes, most of the time my changes are still there, but the way back to the state I actually want for my repository may be long, complicated and require lots of googling/asking around. - as the article mentions, git cares a lot about stuff th…

FYI The committing every few minutes idea commits to a separate branch to prevent this clutter.

Re: Things I wish everyone knew about Git (Part II)

#13

Post by TheChaplain »

MBlume wrote: post #6

"It is really hard to lose stuff" It is really hard to lose stuff that you have ever committed. It is really hard to lose stuff as long as you commit early and often. Uncommitted work is pretty easy to lose with 'git reset'.

Depends. I use an IDE from Jetbrains, their "Local History" feature makes it fairly difficult to lose anything, even between changes on uncommitted files.

Re: Things I wish everyone knew about Git (Part II)

#14

Post by tsimionescu »

perlgeek wrote: post #9
MBlume wrote: post #6

"It is really hard to lose stuff" It is really hard to lose stuff that you have ever committed. It is really hard to lose stuff as long as you commit early and often. Uncommitted work is pretty easy to lose with 'git reset'.

... or with `git checkout` or with `rm` or `git clean` (for files not yet under version control).

... or git merge / git pull (but not git rebase) ...

Re: Things I wish everyone knew about Git (Part II)

#15

Post by [deleted] »

rob74 wrote: post #11

My thoughts on this: - even after years of working with git, I'm still not familiar with all the dark corners I can get myself into by running the wrong command at the wrong time. Yes, most of the time my changes are still there, but the way back to the state I actually want for my repository may be long, complicated and require lots of googling/asking around. - as the article mentions, git cares a lot about stuff th…

[deleted]

Re: Things I wish everyone knew about Git (Part II)

#16

Post by praptak »

I love this quote from Part I:

"Git has an elegant and powerful underlying model based on a few simple concepts:

  1. Commits are immutable snapshots of the repository
  2. Branches are named sequences of commits
  3. Every object has a unique ID, derived from its content
Built atop this elegant system is a flaming trash pile. "

Re: Things I wish everyone knew about Git (Part II)

#17

Post by dale_glass »

stinos wrote: post #10

> But the old commit is still in there, pristine, forever. > (Git will eventually throw away lost and unused snapshots, but typically not anything you have used in the last 90 days.) Without having exlplained what a 'snapshot' is and what 'typically' means, it's pretty unclear whether the first statement is affected by the second, and if it were the first is incorrect, so I feel this clarification should be added to…

> Without having exlplained what a 'snapshot'

A commit is effectively a snapshot of the repository at a given point in time. This is unlike some other revision control systems where a commit is a diff. In git, a commit contains whole files, and the diff is generated if needed.

> and what 'typically' means

Pretty much everything is configurable, and you can invoke the cleanup process by hand if you really want to.

> it's pretty unclear whether the first statement is affected by the second, and if it were the first is incorrect

Yes, I think it's incorrect and shouldn't be relied on. Things floating around unconnected to a branch can be removed by git eventually. There's plenty time to fix any mistake, but it's not "forever".

Re: Things I wish everyone knew about Git (Part II)

#18

Post by pjerem »

stinos wrote: post #10

> But the old commit is still in there, pristine, forever. > (Git will eventually throw away lost and unused snapshots, but typically not anything you have used in the last 90 days.) Without having exlplained what a 'snapshot' is and what 'typically' means, it's pretty unclear whether the first statement is affected by the second, and if it were the first is incorrect, so I feel this clarification should be added to…

Well, the Part I have en entire chapter enticing you to read Git From The Bottom Up [0] before continuing. So the author can expect that you know what is a snapshot.

[0] : https://jwiegley.github.io/git-from-the-bottom-up/

Re: Things I wish everyone knew about Git (Part II)

#19

Post by colonwqbang »

rob74 wrote: post #11

My thoughts on this: - even after years of working with git, I'm still not familiar with all the dark corners I can get myself into by running the wrong command at the wrong time. Yes, most of the time my changes are still there, but the way back to the state I actually want for my repository may be long, complicated and require lots of googling/asking around. - as the article mentions, git cares a lot about stuff th…

I don't think it's so strange that we need to rework the patch series a bit before sending it for review. At least not if we see readability as a main goal.

Not many great writers can sit down and write a perfect script on the first try. They write a first draft and then rework it, move things around etc. In the same way the git user goes over the patch series with rebase and amend to massage it into something that flows nicely and is pleasant to read.

I find that it's actually easier to make a good patch series if you start from many small commits, rather than a few big ones. The tools in git that merge patches together are faster to use than those that pick patches apart.

Post reply on HN