• Senior Software Engineer • Focused on Customers and Craftsmanship • Leader of the Phoenix Software Engineering Reading Group Mike is a DZone MVB and is not an employee of DZone and has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

More Incomplete Thoughts on Git

06.12.2012
| 2921 views |
  • submit to reddit

I’m working through Chapter 6 and things are starting to go off the rails for me. Here are my current thoughts…

  • The git diff --stat <branch|tag> command is nifty. Even more nifty: referring to tags and branches by name rather than full path (svn).
  • I’m gratified to see that EGit displays annotations (blame) similarly to Subclipse.
  • Countless times I’ve committed code to a Subversion repository only to find I’ve broken the build by leaving out a file or lib. The Subversion-way is to either make a follow-up commit with whatever was missing or to reverse-merge the commit and re-commit with everything. The former is undesirable because it spreads the single change across more than one commit; the latter is preferred but is more complicated. Git’s amended commit gives you the convenience of the former with the pedantic correctness of the latter.
  • Yeah… git revert != svn revert … this is going bite me constantly. It already has.
  • I’m totally confused by git reset. I have no idea what this means: “git reset updates the repository and stages the changes for you to commit.” Maybe if I knew what was being “updated” or what was being “staged,” it would make sense! Also, the book says “[git reset] is useful when you notice an error in your previous commit and want to fix it.” What…? I thought that’s what amend was for…? Apparently, if I’m going to understand reset, I’ll have to find another reference.
  • My single experiment with git rebase -i wherein I attempted to squash two commits together and then break them back out did not work as expected. The book said the second execution of rebase would show my squashed commit starting with “edit” but it still says “pick”; not sure what I did wrong.
  • Using hashes as revision numbers makes it impossible to glance at a list of commits and determine what’s newer, older, or (dis)ordered. I ran into this when playing with git rebase -i. Unquestionably, rebase has a set order but it’s not self-obvious.
Published at DZone with permission of Mike Christianson, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jilles Van Gurp replied on Wed, 2012/06/13 - 2:02am

Git reset is about resetting your staging area. So if you've git added a file but not committed it yet, you can unstage it by resetting it. The default is a soft reset, which keeps the changes to the file but removes it from the staging area. A hard reset also removes the changes

But that's just one use. You can also use it to rewind history a few commits. So say you have a history with commits A and B and you do a git reset A: commit B is now gone from your history. With --hard the changes will be gone from your checked out copy as well. It's something you wouldn't want to do in subversion but something that makes perfect sense on a local git repository for changes you haven't pushed yet.

The process of staging changes for commits is one of the harder things to grasp for new git users because there's simply no such thing in svn. You can actually modify a file, stage it, modify it again, and then a commit will only commit the first modifications until you stage the second modification as well.

Git revert on the other hand actually creates a new commit that reverts the specified commit(s). It's the equivalent of a merge with a negative range in subversion. Of course a git merge is an entirely different beast than a svn merge, but that's a separate discussion.

Regarding hashes: git histories are directed acyclic graphs. Sequential numbers wouldn't make much sense for that. Also, git is a decentralized version system and hashes are globally unique identifiers, sequential numbers would make even less sense for this reason.  

Wujek Srujek replied on Wed, 2012/06/13 - 2:04am in response to: Jilles Van Gurp

Erwin Mueller replied on Wed, 2012/06/13 - 8:08am

I think you are confused, because in git there is something called the "index" or "staging area". You can think of it as a layer between the real files and the commit. So if you do a "git add", you are not committing yet, but add the files to the index. With reset you can reset the index again.

That index or staging area allows us very cool stuff. Like to add files and reset again; to do "git stash" and "git stash pop"; and many more cool thinks I didn;t think right now.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.