On branching
b-list.org
On branching
1–10 of 43 posts
Re: On branching
#2I'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.
Re: On branching
#3Coming from svn, I too felt initial discomfort about git's promiscuous branching, but then I learned to stop worrying and love the index. Working in svn repositories evokes "I wish this was a git repository" every time.
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.
Re: On branching
#4Coming from svn, I too felt initial discomfort about git's promiscuous branching, but then I learned to stop worrying and love the index. Working in svn repositories evokes "I wish this was a git repository" every time. 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…
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
Re: On branching
#5Coming from svn, I too felt initial discomfort about git's promiscuous branching, but then I learned to stop worrying and love the index. Working in svn repositories evokes "I wish this was a git repository" every time. 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…
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.
Re: On branching
#6I 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.
Re: On branching
#7I'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.
Re: On branching
#8I 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 pape…
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 ;)
Re: On branching
#9Coming from svn, I too felt initial discomfort about git's promiscuous branching, but then I learned to stop worrying and love the index. Working in svn repositories evokes "I wish this was a git repository" every time. 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…
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
Re: On branching
#10Coming from svn, I too felt initial discomfort about git's promiscuous branching, but then I learned to stop worrying and love the index. Working in svn repositories evokes "I wish this was a git repository" every time. 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…
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.
Further:
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"