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

A safer git checkout

cirw.in

Post reply on HN
Print view View original

11–20 of 20 posts

Re: A safer git checkout

#11

Post by gauravk92 »

MBlume wrote: post #7
ghurlman wrote: post #5

Earlier quoted context omitted.

I've worked with developers that went days without committing... it was maddening.

Can we all work on this? Somehow nobody seems to treat writing crappy commits (messages like "work since Tuesday" or "it works now") like they would writing crappy code. Version control is fundamental to our job .

Most developers learn by example. I've looked for resources on using vcs properly but the few that existed weren't very good. A great resource would be a showcase for a collection of great commits. It doesn't exist as far as I know unfortunately.

Re: A safer git checkout

#12

Post by Xurinos »

MBlume wrote: post #7
ghurlman wrote: post #5

Earlier quoted context omitted.

I've worked with developers that went days without committing... it was maddening.

Can we all work on this? Somehow nobody seems to treat writing crappy commits (messages like "work since Tuesday" or "it works now") like they would writing crappy code. Version control is fundamental to our job .

It's funny -- I think this is where some of the conflict lies. With git, you can do a bunch of commits with crappy comments and then, when you are ready to publicize it (push, whatever), you can use rebase to pretty up your commit history. In other words, I take the analogy of "crappy commits" to "crappy code" a step further: the commit history is another document that is to be presented to other developers; make it helpful!

Re: A safer git checkout

#13

Post by Xurinos »

billybob wrote: post #10

I've been using Git for a couple years now, and I don't think I've ever lost any work. Even if you do `git reset --hard HEAD~5`, "throwing away" your last few commits, they aren't actually discarded yet. You can do `git reflog` to see them and then `git checkout -b some_commit_hash` to recover one to a branch, or `git reset --hard some_commit-hash` to set this branch back to that point. Only if those commits stay orp…

It becomes dangerous if you have changes in your working tree. You truly lose those changes with a "git reset --hard HEAD" or the forced checkout.

Re: A safer git checkout

#14

Post by cirwin »

bnr wrote: post #8

I don't see how git-cof is different/better than git-stash.

Git stash solves a different problem, which is "I want to save these changes, and get them back". git-cof is optimized for the use-case of "I want to get rid of these changes, and I'll probably never use them again".

The most obvious difference is that commits made with git-cof never show up in git log --oneline --graph; but also they get garbage collected automatically, you don't have to manually go through "git stash list".

Re: A safer git checkout

#16

Post by davvid »

gauravk92 wrote: post #11
MBlume wrote: post #7

Earlier quoted context omitted.

Can we all work on this? Somehow nobody seems to treat writing crappy commits (messages like "work since Tuesday" or "it works now") like they would writing crappy code. Version control is fundamental to our job .

Most developers learn by example. I've looked for resources on using vcs properly but the few that existed weren't very good. A great resource would be a showcase for a collection of great commits. It doesn't exist as far as I know unfortunately.

The git project itself is a perfect example, and the code reviews on the mailing list will often note changes that should be made to commit messages.

Re: A safer git checkout

#17

Post by davvid »

Xurinos wrote: post #13
billybob wrote: post #10

I've been using Git for a couple years now, and I don't think I've ever lost any work. Even if you do `git reset --hard HEAD~5`, "throwing away" your last few commits, they aren't actually discarded yet. You can do `git reflog` to see them and then `git checkout -b some_commit_hash` to recover one to a branch, or `git reset --hard some_commit-hash` to set this branch back to that point. Only if those commits stay orp…

It becomes dangerous if you have changes in your working tree. You truly lose those changes with a "git reset --hard HEAD" or the forced checkout.

Exactly. As mentioned in the article, `git reset --keep` is the preferred way to do it these days. It preserves uncommitted worktree changes.

Re: A safer git checkout

#18

Post by lsb »

cirwin wrote: post #15
shaggyfrog wrote: post #2

Dear author: the plural of alias is aliases.

I know :). See https://github.com/ConradIrwin/git-aliae#faq .

We make nouns out of adverbial/prepositional phrases often, and alias ("in other places [known as]" -> "a name by which one is known in another place") is just one example. We talk about items, but "item" is the adverb that means "also", and you'd find it in recipes: "2 eggs. Item: oil. Item: water.". (Less similarly, you'll see brochures called "take-ones".)

Re: A safer git checkout

#19

Post by Cogito »

gauravk92 wrote: post #11
MBlume wrote: post #7

Earlier quoted context omitted.

Can we all work on this? Somehow nobody seems to treat writing crappy commits (messages like "work since Tuesday" or "it works now") like they would writing crappy code. Version control is fundamental to our job .

Most developers learn by example. I've looked for resources on using vcs properly but the few that existed weren't very good. A great resource would be a showcase for a collection of great commits. It doesn't exist as far as I know unfortunately.

as davvid says, the git project is an excellent place to start. The git project inherited a lot of its practices from the linux kernel project, but they are different enough to make looking at both interesting.

The archive for the git list is at [1].

The other great thing to look for is a well designed standard, with examples, for how a commit message should look. Most everyone who uses a standard uses The Standard* [2], so I would suggest you do the same.

* Except that many projects don't require the sign-off

[1] http://dir.gmane.org/gmane.comp.version-control.git

[2] http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa... (I am pretty sure there is a very similar post from Linus on a mailing list somewhere, but I can't find it. This is the most commonly linked to that I could find.)

[EDIT] formatting...

Re: A safer git checkout

#20

Post by billybob »

Xurinos wrote: post #13
billybob wrote: post #10

I've been using Git for a couple years now, and I don't think I've ever lost any work. Even if you do `git reset --hard HEAD~5`, "throwing away" your last few commits, they aren't actually discarded yet. You can do `git reflog` to see them and then `git checkout -b some_commit_hash` to recover one to a branch, or `git reset --hard some_commit-hash` to set this branch back to that point. Only if those commits stay orp…

It becomes dangerous if you have changes in your working tree. You truly lose those changes with a "git reset --hard HEAD" or the forced checkout.

Oh! I see. I would never do a `git reset` of any kind if I hadn't committed or stashed. Yikes!
Post reply on HN