Create a Dreamwidth Account
Site and Account
Reload page in style:
Re: Git & rebase (Reply)
Re: Git & rebase
2011-06-29 05:02 am (UTC)
I feel like this post is from someone who was using git back in the early days, when you had to do a lot of plumbing commands yourself. Today's Git has a very similar command set for the average user's needs. The free book Pro Git gives you enough information in a single chapter to use Git very well day to day (chapter 2, if you're wondering). I feel like it's very straightforward and quite polished under most circumstances, but has power if you want to delve a little deeper. I submit that anyone who wants to compare Git to Mercurial, or point out any fault of Git, needs to have read that book from cover to cover.
Anyway, going back to what you call the single greatest failing of Git, which is not recording branch information on the commits themselves. I don't want branch information recorded. I may make a temporary branch named something ridiculous or uninformative (and I'm speaking of lightweight branches, or Mercurial's bookmark extension), implement a feature, and decide that it's worth keeping. I then merge this feature into a more "mainstream" branch (or rebase, if that's how I want to work -- both workflows are valid). I don't want my old temporary branch name to stick to those commits. It's unhelpful information. However, giving this temporary branch an important or mainstream name is not ideal, because I may not want to merge the contents of that branch into the mainstream workflow, and then those commits are floating around with seemingly important labels, when they're garbage.
I'm rambling, so here's the point -- I don't see the importance of knowing under which branch a certain commit was developed. That's useless information, in my opinion. Rather, I want to know what a single commit does. (Which should be documented in a well-written commit message) Assuming everyone is writing good commit messages, then it doesn't matter under which branch some code was written -- what matters is the code itself.
Now, I have to end with a confession: I don't know mercurial very well. Every time I try to pick it up, I miss my integrated lightweight branching. (I don't want to use an extension -- it's the most important part of my workflow, and what makes Git so awesome in my opinion, its branching model) Every time I hear someone mention heavy branching (cloning into a new directory), I shudder, thinking of the SVN branching model. I admit, though, I need to learn more about Mercurial and really try it.
But I will say this: the author has stated that he has worked on projects using both Mercurial and Git; I submit that the author has not learned to properly use a Git workflow, based on what I've read here. Please go read Pro Git (http://progit.org/book/) from cover to cover. It's not very long, and really explains a Git workflow and the power of the Git branching model. After reading this book, I submit that no one could point at Git and call it arcane or a cognitive burden -- it's progressed a lot in the last few years. If, at that point, you still miss your Mercurial branches (er, families, I guess), then by all means use Mercurial. But I love Git, and just want people to realize that it's easy to use when you have the right resources to learn from, and just encourages a different workflow from Mercurial.
Thread from start
This account has disabled anonymous posting.
You can comment on this post while signed in with an account from many other sites, once you have confirmed your email address.
Sign in using OpenID
(will be screened)
If you don't have an account you can
create one now
HTML doesn't work in the subject.
Check spelling during preview
This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.
j h woodyatt
Most Popular Tags
Aaron B. Russell
Expand Cut Tags
No cut tags
Page generated Aug. 20th, 2017 02:20 am
Top of page