DZone
Java Zone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
  • Refcardz
  • Trend Reports
  • Webinars
  • Zones
  • |
    • Agile
    • AI
    • Big Data
    • Cloud
    • Database
    • DevOps
    • Integration
    • IoT
    • Java
    • Microservices
    • Open Source
    • Performance
    • Security
    • Web Dev
DZone > Java Zone > More Incomplete Thoughts on Git

More Incomplete Thoughts on Git

Mike Christianson user avatar by
Mike Christianson
·
Jun. 13, 12 · Java Zone · Interview
Like (0)
Save
Tweet
3.58K Views

Join the DZone community and get the full member experience.

Join For Free

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

Published at DZone with permission of Mike Christianson, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Determine if Microservices Architecture Is Right for Your Business?
  • JUnit 5 Tutorial: Nice and Easy [Video]
  • How To Integrate Event Streaming Into Your Applications
  • Making Machine Learning More Accessible for Application Developers

Comments

Java Partner Resources

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • MVB Program
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends:

DZone.com is powered by 

AnswerHub logo