4 ms·

A safer git checkout

13 points by guybrush0 14y ago

shaggyfrog 14y ago
Dear author: the plural of alias is aliases.
- cirwin 14y ago
  I know :). See https://github.com/ConradIrwin/git-aliae#faq https://github.com/ConradIrwin/git-aliae#faq.
  - lsb 14y ago
    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".)
deleted 14y ago
[deleted]
bherms 14y ago
Perhaps I'm missing something, but in years of development using git as our scm, I have never used checkout -f. I've used reset --hard HEAD here and there. Is there any difference in their use? Also, are there a lot of developers who work for hours without committing? I've only found myself in a situation where I could possibly lose hours of work a few times and each time this happens I realize I was treading thin ice. Lastly, and maybe this is also just me, I keep my repos in Dropbox. Github is our main repo store, but I've got an extra level of protection, especially since Dropbox allows you to rollback file changes.
- ghurlman 14y ago
  I've worked with developers that went days without committing... it was maddening.
  - MBlume 14y ago
    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.
    - gauravk92 14y ago
      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.
      - davvid 14y ago
        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.
      - Cogito 14y ago
        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 http://dir.gmane.org/gmane.comp.version-control.git [2] http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html 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...
- MBlume 14y ago
  > Also, are there a lot of developers who work for hours without committing? I manage maybe an hour at a max, and then have to make extensive use of commit -p to tease apart all the changes I've made.
bnr 14y ago
I don't see how git-cof is different/better than git-stash.
- cirwin 14y ago
  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".
hyprlogik 14y ago
Why not just use git stash?
billybob 14y ago
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 orphaned for a while (a week or two?) will Git truly discard them.
- Xurinos 14y ago
  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.
  - davvid 14y ago
    Exactly. As mentioned in the article, `git reset --keep` is the preferred way to do it these days. It preserves uncommitted worktree changes.
  - billybob 14y ago
    Oh! I see. I would never do a `git reset` of any kind if I hadn't committed or stashed. Yikes!

13 points by guybrush0 14y ago

shaggyfrog 14y ago

Dear author: the plural of alias is aliases.

cirwin 14y ago
I know :). See https://github.com/ConradIrwin/git-aliae#faq https://github.com/ConradIrwin/git-aliae#faq.
- lsb 14y ago
  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".)

deleted 14y ago

[deleted]

bherms 14y ago

Perhaps I'm missing something, but in years of development using git as our scm, I have never used checkout -f. I've used reset --hard HEAD here and there. Is there any difference in their use? Also, are there a lot of developers who work for hours without committing? I've only found myself in a situation where I could possibly lose hours of work a few times and each time this happens I realize I was treading thin ice. Lastly, and maybe this is also just me, I keep my repos in Dropbox. Github is our main repo store, but I've got an extra level of protection, especially since Dropbox allows you to rollback file changes.

ghurlman 14y ago
I've worked with developers that went days without committing... it was maddening.
- MBlume 14y ago
  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.
  - gauravk92 14y ago
    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.
    - davvid 14y ago
      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.
    - Cogito 14y ago
      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 http://dir.gmane.org/gmane.comp.version-control.git [2] http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html 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...
MBlume 14y ago
> Also, are there a lot of developers who work for hours without committing? I manage maybe an hour at a max, and then have to make extensive use of commit -p to tease apart all the changes I've made.

bnr 14y ago

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

cirwin 14y ago
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".

hyprlogik 14y ago

Why not just use git stash?

billybob 14y ago

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 orphaned for a while (a week or two?) will Git truly discard them.

Xurinos 14y ago
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.
- davvid 14y ago
  Exactly. As mentioned in the article, `git reset --keep` is the preferred way to do it these days. It preserves uncommitted worktree changes.
- billybob 14y ago
  Oh! I see. I would never do a `git reset` of any kind if I hadn't committed or stashed. Yikes!