On branching(b-list.org)
b-list.org
On branching
http://www.b-list.org/weblog/2010/feb/02/branching/
4 comments
You seem to be under the impression that I'm afraid of short-lived branches for minor work. I'm not sure how you could have gotten that impression unless you didn't actually read the article.
I read the article, I enjoyed it. It reminded me of why I like git so much.
git-diff doesn't require you to do gymnastics to compare files from different branches in the same working directory: "git diff branch1 [branch2] path" where omitting branch2 compares the working path instead of branch2's.
And I think your second problem with git, that big hairy branches should somehow be distinct from small simple branches, is also a non-issue. Especially since you already recognized the solution: let big hairy branches live, and small simple branches die.
Since you can reconstruct deleted branches, I don't see the problem with deleting them. Bugfix branches for specific releases can be created as needed by choosing the release commit in master as the starting point for the branch. If you really want to keep dormant branches around you can rename them to keep them distinct from "working" branches.
Sorry for not having specifically addressed these in the original comment, which was actually supposed to be a reply to fexl http://news.ycombinator.com/item?id=1095116
git-diff doesn't require you to do gymnastics to compare files from different branches in the same working directory: "git diff branch1 [branch2] path" where omitting branch2 compares the working path instead of branch2's.
And I think your second problem with git, that big hairy branches should somehow be distinct from small simple branches, is also a non-issue. Especially since you already recognized the solution: let big hairy branches live, and small simple branches die.
Since you can reconstruct deleted branches, I don't see the problem with deleting them. Bugfix branches for specific releases can be created as needed by choosing the release commit in master as the starting point for the branch. If you really want to keep dormant branches around you can rename them to keep them distinct from "working" branches.
Sorry for not having specifically addressed these in the original comment, which was actually supposed to be a reply to fexl http://news.ycombinator.com/item?id=1095116
git-diff doesn't require you to do gymnastics to compare files from different branches
It requires me to use git-diff. How do I do it without involving the VCS tool? How do I get both files side-by-side in Emacs so I can go through them thoroughly (some of us prefer that to reading diffs, you know)?
Since you can reconstruct deleted branches, I don't see the problem with deleting them.
I want the history of my codebase to be easy to get a feel for; that means major work (e.g., a long-lived branch which made significant changes) should be easily accessible. Telling people to hunt down the right merge commit and work back through its ancestry doesn't do that. Inventing ad-hoc schemes of tags or renamed branches to try to make up for the inability to keep a branch but say you're done with it doesn't do that.
It reminded me of why I like git so much.
Meanwhile, it's (one reason) why I don't like git so much.
It requires me to use git-diff. How do I do it without involving the VCS tool? How do I get both files side-by-side in Emacs so I can go through them thoroughly (some of us prefer that to reading diffs, you know)?
Since you can reconstruct deleted branches, I don't see the problem with deleting them.
I want the history of my codebase to be easy to get a feel for; that means major work (e.g., a long-lived branch which made significant changes) should be easily accessible. Telling people to hunt down the right merge commit and work back through its ancestry doesn't do that. Inventing ad-hoc schemes of tags or renamed branches to try to make up for the inability to keep a branch but say you're done with it doesn't do that.
It reminded me of why I like git so much.
Meanwhile, it's (one reason) why I don't like git so much.
How do I get both files side-by-side in Emacs so I can go through them thoroughly (some of us prefer that to reading diffs, you know)?
So never delete branches. You'll know if they're "done" if they've been merged into your master branch.
git show branch:path/to/file > /tmp/file
So never delete branches. You'll know if they're "done" if they've been merged into your master branch.
git show
Did you miss the part where I said I'd like to not involve the VCS tool? Without using git, how do I see two different branches' versions of files?
So never delete branches. You'll know if they're "done" if they've been merged into your master branch.
But nobody else will. What everybody and their brother has told me to do is delete the branch and invent an ad-hoc naming scheme to tag the merge commits. Which is... um, no, that's not the same as being able to close a branch.
Did you miss the part where I said I'd like to not involve the VCS tool? Without using git, how do I see two different branches' versions of files?
So never delete branches. You'll know if they're "done" if they've been merged into your master branch.
But nobody else will. What everybody and their brother has told me to do is delete the branch and invent an ad-hoc naming scheme to tag the merge commits. Which is... um, no, that's not the same as being able to close a branch.
how do I see two different branches' versions of files?
You could clone the branches to different paths, I guess.
But nobody else will [know that a branch is "done".]
If you've instructed the team to care about merged status, they will. And there's nothing semantically strange about it either.
I get it, git isn't for you. I concede.
You could clone the branches to different paths, I guess.
But nobody else will [know that a branch is "done".]
If you've instructed the team to care about merged status, they will. And there's nothing semantically strange about it either.
I get it, git isn't for you. I concede.
GIT_EXTERNAL_DIFF lets you use emacs as your diff tool.
http://stackoverflow.com/questions/255202/how-do-i-view-git-...
http://stackoverflow.com/questions/255202/how-do-i-view-git-...
Further:
To say "I'm done with this branch", merge it to master. This is natural; you already do this.
To say "I'm done with this branch", merge it to master. This is natural; you already do this.
git branch --merged master # list branches that are "done"
git branch --no-merged master # list branches that are "not done"
Okay, now . . . tell me how this provides any benefit over Mercurial's options.
I'm not making that claim, and freely admit that I am utterly ignorant about mercurial. I'm merely demonstrating that, contrary to the author's assertion, it's possible to use git without deleting branches and still have a meaningful way to measure whether a branch is "done", and it's the common-sense measure of "has it merged?"
You can change your mind and turn a 'bookmark' into a 'branch' and back again. you can also fold your branch into another one and pretend it never happened. Or you can pick your branch up and place it somewhere else in the tree, or...
I very much like what you say about "newfound willingness." But I, Triceratops, am perfectly willing to experiment:
cd project/loom
cp -pr code ~/version/loom/95.before_zany_idea
# hack away; restore if irredeemably stupid
diff -r code ~/version/loom/93.released
# you get the idea
It actually annoys me when people don't use git now. Git has clearly won among current dvcs. If something comes along later that's head and shoulders above dvcs, then I'll be happy to switch. But for now, random folks' views on why their tool is marginally technically better doesn't outweigh the enormous benefits of everyone you know using the same dvcs.
And it annoys me when people use BitBucket over Github. It's like your one friend who insists on not having a Facebook account and sticking to his Livejournal because Livejournal is supposedly better at some random thing, but in reality, you strongly suspect he just wants to prove he's not a follower, an independent breed cut from a better cloth than the rest of us.
These days, whenever I need a new little tool, its official repo is usually on Github. This lets me pull it into my project as a submodule and still contribute back in a very efficient way. As soon as it's mercurial, I can't, simply because I don't know mercurial and I certainly have zero intention of attaining the same mastery of it that I have of git. And, frankly, I don't want to attain any mastery of it.
Moreover, of course, you can't just mix repos willy nilly. Maybe there's a way to use mercurial as a submodule of git repos. But it's gonna be a dastardly hack.
So, please. Just use git. Competition is good, but so is standardization. I get that you have highly nuanced opinions about the various merits of dvcs, and I'm sure you're right and I'm wrong. But it just doesn't matter, because the benefits of mercurial don't outweigh the beneficial network effects of using git, and that's never going to change.
And it annoys me when people use BitBucket over Github. It's like your one friend who insists on not having a Facebook account and sticking to his Livejournal because Livejournal is supposedly better at some random thing, but in reality, you strongly suspect he just wants to prove he's not a follower, an independent breed cut from a better cloth than the rest of us.
These days, whenever I need a new little tool, its official repo is usually on Github. This lets me pull it into my project as a submodule and still contribute back in a very efficient way. As soon as it's mercurial, I can't, simply because I don't know mercurial and I certainly have zero intention of attaining the same mastery of it that I have of git. And, frankly, I don't want to attain any mastery of it.
Moreover, of course, you can't just mix repos willy nilly. Maybe there's a way to use mercurial as a submodule of git repos. But it's gonna be a dastardly hack.
So, please. Just use git. Competition is good, but so is standardization. I get that you have highly nuanced opinions about the various merits of dvcs, and I'm sure you're right and I'm wrong. But it just doesn't matter, because the benefits of mercurial don't outweigh the beneficial network effects of using git, and that's never going to change.
Maybe it's the circles I travel in, but I don't see the same git dominance you do vs. mercurial; I see them both really frequently. Among major projects I can think of off the top of my head, Python, Adium, OpenOffice, and Mozilla are all on mercurial.
> Python... [is] on mercurial
Welllll... no. Python has made the decision to move to hg, but the conversion has hit some stumbling blocks and is not yet complete:
http://sayspy.blogspot.com/2010/01/where-hg-transition-stand...
Welllll... no. Python has made the decision to move to hg, but the conversion has hit some stumbling blocks and is not yet complete:
http://sayspy.blogspot.com/2010/01/where-hg-transition-stand...
I use mercurial, because it supports HTTPS pushing. Git has had a request for http(s) push for years and hasn't implemented it. My university blocks outgoing SSH access and none of the standard prescribed solutions work. Its quite easy for someone with a job to say - "Get a VPS and tunnel through it", but I can't afford a VPS, so git has barriers to entry, and until that is reduced I will stick to my LiveJournal.
You should switch to Windows again, you'll receive the enormous benefit that everyone you know uses the same OS.
You should switch to Windows again, you'll receive the enormous benefit that everyone you know uses the same OS.
Smart HTTP support for Git is being released soon. We'll be adding it to GitHub shortly thereafter.
Funny, I could have posted the same comment after s/git/mercurial/g and s/Github/BitBucket/g. But then again, it would be equally stupid and trollish.
Monoculture has its own problems. Lack of competition, for one thing, and a lack of different options for people that actively like working in different ways.
Oh, and Livejournal does both security and commenting better than Facebook, which is why I have both.
Oh, and Livejournal does both security and commenting better than Facebook, which is why I have both.
I had a two-word reply to your opinions, but then I realized HN would vote me down into oblivion for expressing it in those terms.
So I'll pose it in different terms: why haven't you given into the network effects of, say, Visual Basic?
So I'll pose it in different terms: why haven't you given into the network effects of, say, Visual Basic?
Can you elaborate on what the network effects of using Visual Basic would be, actually? What domains does Visual Basic have significant network effects? How does this compare against the network effects of Perl's CPAN, which is a significant factor in my choice of programming language?
Offhand, I'd bet VB will open up a larger raw number of job opportunities than Perl. So why doesn't everybody jump on that bandwagon? After all, every major language is Turing-complete, so obviously people are just nitpicking when they could be choosing a clear winner.
I don't really see much value in keeping a branch around after development is complete (or defunct).
If the work is complete then merge it (with no-ff if you want to show the merge explicitly). If it's defunct then delete it. If you want to keep it around but discourage further development then tag it or come up with a naming convention.
That you have the ability to mark branches as closed in mercurial is mainly paper over their odd decision to not allow deletion of branches.
If the work is complete then merge it (with no-ff if you want to show the merge explicitly). If it's defunct then delete it. If you want to keep it around but discourage further development then tag it or come up with a naming convention.
That you have the ability to mark branches as closed in mercurial is mainly paper over their odd decision to not allow deletion of branches.
I don't really see much value in keeping a branch around after development is complete (or defunct).
If you have both branches and a way to close them, then you have a much simpler way to get a feel for the history of the code. You know at a quick glance what sort of major work has gone on and what's still ongoing.
If you don't have that you'll end up inventing more complex ad-hoc schemes to get it (merging a branch, deleting it and tagging the merge commit is an example of one such scheme, and it doesn't do the same thing).
And the ability to mark branches as closed in Mercurial is, to me, an indication that the developers put some thought into the different use cases for branching and wanted to cover more of them than git's standard workflow does ;)
If you have both branches and a way to close them, then you have a much simpler way to get a feel for the history of the code. You know at a quick glance what sort of major work has gone on and what's still ongoing.
If you don't have that you'll end up inventing more complex ad-hoc schemes to get it (merging a branch, deleting it and tagging the merge commit is an example of one such scheme, and it doesn't do the same thing).
And the ability to mark branches as closed in Mercurial is, to me, an indication that the developers put some thought into the different use cases for branching and wanted to cover more of them than git's standard workflow does ;)
Actually, git supports more workflows, you could simply implement read-only branches with a naming scheme and a hook.
In lots of ways git is a superset, branch workflow included.
In lots of ways git is a superset, branch workflow included.
git is a superset
A superset which doesn't include everything that's in the alleged subset? That must be a new definition of "superset" that I haven't heard of yet...
A superset which doesn't include everything that's in the alleged subset? That must be a new definition of "superset" that I haven't heard of yet...
The possible workflows with git encompass hg workflows.
You're obviously not interested in gaining anything but self-fulfillment throughout this thread.
"Git standard workflow"? Where'd you get that notion from? Supposing there is one, care to share?
Where'd you get that notion from?
From the documentation and from the fact that pretty much every git user who's responded has told me the same things. Or am I supposed to take that as a massive coincidence?
From the documentation and from the fact that pretty much every git user who's responded has told me the same things. Or am I supposed to take that as a massive coincidence?
You didn't specify your sample size and I won't vouch for what people I don't know tell you. You can take it as whatever you'd like.
Next you'll be saying the Django tutorial is the standard way to lay out projects. It's in the documentation, right?
Well, of the people who decided to provide answers on HN or reddit, the consensus was: merge the branch, delete it, then add a tag on the merge commit. And then on IRC the author of this book told me to do the same thing:
http://pragprog.com/titles/tsgit/pragmatic-version-control-u...
The only person who suggested anything else, out of fifty-seven comments so far, was one who suggested merging the branch and then keeping it around rather than deleting and tagging it.
Since that's all I have to go on, and since it seems to be a pretty clear consensus, I'm taking their advice as being a generally-accepted convention amongst git users. Granted, such conventions in git seem to be as ephemeral as branches (e.g., fads such as "rebase everything! rebase after every commit! No, wait, never rebase! Rebasing is evil! Nobody should rebase!"), but if you're trying to suggest that as a result there are no conventions, I'm just going to write you off.
http://pragprog.com/titles/tsgit/pragmatic-version-control-u...
The only person who suggested anything else, out of fifty-seven comments so far, was one who suggested merging the branch and then keeping it around rather than deleting and tagging it.
Since that's all I have to go on, and since it seems to be a pretty clear consensus, I'm taking their advice as being a generally-accepted convention amongst git users. Granted, such conventions in git seem to be as ephemeral as branches (e.g., fads such as "rebase everything! rebase after every commit! No, wait, never rebase! Rebasing is evil! Nobody should rebase!"), but if you're trying to suggest that as a result there are no conventions, I'm just going to write you off.
Conventions are just conventions anyway. We've established that there's no technical barrier to your two objections. 1) You can clone different branches into different paths, which is exactly like a traditional svn workflow, and a pretty normal thing to do for continuous integrations and the like. 2) And if you never want to delete a branch, you can check on their merged status to determine if they're "done". More clever solutions have been supplied by others in this thread. You needn't convert to git, but it'd be polite to recognize that your objection to git is purely psychological.
I've used svn and git, but something still doesn't feel right. I still like "cp -pr" and "diff -r" for version control. I waste disk space with whole directory copies, but I eventually "rm -rf" the really old ones. I don't trust automatic merges so I do them manually, yanking and pasting between vim edit panels. I am a paleolithic relic.
I do this too, partly because when I have branches and revisions as actual directories and files, I can use the usual Unix tools on them, instead of having to use a parallel set of tools provided by the version control system.
I have another reason for the old-fashioned approach. I do hedge fund accounting for a living. With my software tools I can reproduce every result ever created for a fund from original input, even going back several years. I have translators for various brokerage feeds that I've had to maintain and adapt for years -- and this is no small feat considering that information technology people in the financial industry can't do a complete, consistent, or stable data feed to save their lives.
Whenever I make a change, either to a translator or even the core accounting code, I make a copy of the library. I then have to go back and run all funds, including my test funds, as a regression test using the new modified library. I have to do that one fund at a time, testing to make sure no catastrophic differences have arisen. So during this interim period, I have some funds running on the new code and some funds running on the old code. BOTH versions have to be "live" at the same time.
I also have to keep backups of the data as well, both inputs and outputs, so I can "diff" those easily. I'm sure as heck not gonna put that into git.
So I'm not just stick in the mud trying to be contrary -- I have work to do, and it needs to be as reliable as a Swiss watch.
Whenever I make a change, either to a translator or even the core accounting code, I make a copy of the library. I then have to go back and run all funds, including my test funds, as a regression test using the new modified library. I have to do that one fund at a time, testing to make sure no catastrophic differences have arisen. So during this interim period, I have some funds running on the new code and some funds running on the old code. BOTH versions have to be "live" at the same time.
I also have to keep backups of the data as well, both inputs and outputs, so I can "diff" those easily. I'm sure as heck not gonna put that into git.
So I'm not just stick in the mud trying to be contrary -- I have work to do, and it needs to be as reliable as a Swiss watch.
"rm -rf" is dangerous. A versioning system should allow you to get by without doing dangerous stuff.
Oh yes, it's dangerous, and I rarely use it. It's funny, I just cd'ed into my ~/version/loom and saw a directory "58" sitting there dated 2008-08-17. I'll probably keep that one. Then there's "86.12.before_prune" dated 2009-05-20. I could "rm -rf" that one pretty safely, since my prompt shows my current directory as "~/version/loom". Here goes!
laptop:~/version/loom$ rm -rf 86.12.before_prune
http://code.google.com/p/trash-cli/
I don't know, maybe if you're old-fashioned you won't like the trash metaphor, but I love it. And every so often I just do trash-empty 30 to clean out anything older than a month.
I don't know, maybe if you're old-fashioned you won't like the trash metaphor, but I love it. And every so often I just do trash-empty 30 to clean out anything older than a month.
I like the trash metaphor. I haven't formalized it yet, but often I will simply "mv" things to ~/old or ~/tmp and let it rot there for a few months. Thanks for the tip, I'll check it out.
I quite like the way Gmail handles this issue. Stuff just goes stale and drops of the first page of your inbox. But it's still there --- and I now feel that it's barbaric to delete emails.
By the way there's another trick I sometimes use when I really really want to delete a directory but I also really really don't want to make a mistake:
Sometimes I'll even just let it sit there in ~/tmp for a few months before clobbering it.
cd ~/somewhere
mv the_thing_i_want_to_delete ~/tmp/go_away
cd ~/tmp
rm -rf go_away
Sometimes I'll even just let it sit there in ~/tmp for a few months before clobbering it.
I wouldn't have initially trusted git if it weren't for Linus's Google Talk. And I'm glad I gave it the time it requires to change workflows.
The most unexpected side-effect of using git is a newfound willingness to follow experimental ideas in my projects as fast as I can think/type. I'll guess it comes from confidence in git's ability to safely partition branches in-situ; the relative speed and ease with which branches are created, merged and destroyed; and the existence of the index and stash. Git removes the version control inertia I didn't even know was there.