7 ms·

On branching

49 points by stakent 17y ago

fexl 17y ago
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.
- _delirium 17y ago
  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.
  - fexl 17y ago
    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.
- eru 17y ago
  "rm -rf" is dangerous. A versioning system should allow you to get by without doing dangerous stuff.
  - fexl 17y ago
    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 FEEL the adrenaline rush! ;)
  - fexl 17y ago
    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: cd ~/somewhere mv the_thing_i_want_to_delete ~/tmp/go_away cd ~/tmp rm -rf go_away I'll also use Tab to command-complete the "go_away", and pause slightly before pressing Enter. Sometimes I'll even just let it sit there in ~/tmp for a few months before clobbering it.
  - youngian 17y ago
    http://code.google.com/p/trash-cli/ 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.
    - fexl 17y ago
      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.
      - eru 17y ago
        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.
hyperbolist 17y ago
Coming 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.
- fexl 17y ago
  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 I'm not trying to denigrate git. I still use it to publish code, e.g. http://github.com/chkoreff/Loom http://github.com/chkoreff/Loom. But my dirty little secret is, I still shamefully use "cp -pr" and "diff -r" anyway, and only git-commit right before pushing to github.
- ubernostrum 17y ago
  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.
  - hyperbolist 17y ago
    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 http://news.ycombinator.com/item?id=1095116
traviscline 17y ago
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.
- ubernostrum 17y ago
  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 ;)
  - traviscline 17y ago
    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.
    - ubernostrum 17y ago
      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...
      - traviscline 17y ago
        The possible workflows with git encompass hg workflows. You're obviously not interested in gaining anything but self-fulfillment throughout this thread.
ellyagg 17y ago
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.
- ubernostrum 17y ago
  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?
  - tene 17y ago
    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?

49 points by stakent 17y ago

fexl 17y ago

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.

_delirium 17y ago
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.
- fexl 17y ago
  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.
eru 17y ago
"rm -rf" is dangerous. A versioning system should allow you to get by without doing dangerous stuff.
- fexl 17y ago
  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 FEEL the adrenaline rush! ;)
- fexl 17y ago
  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: cd ~/somewhere mv the_thing_i_want_to_delete ~/tmp/go_away cd ~/tmp rm -rf go_away I'll also use Tab to command-complete the "go_away", and pause slightly before pressing Enter. Sometimes I'll even just let it sit there in ~/tmp for a few months before clobbering it.
- youngian 17y ago
  http://code.google.com/p/trash-cli/ 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.
  - fexl 17y ago
    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.
    - eru 17y ago
      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.

hyperbolist 17y ago

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

fexl 17y ago
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 I'm not trying to denigrate git. I still use it to publish code, e.g. http://github.com/chkoreff/Loom http://github.com/chkoreff/Loom. But my dirty little secret is, I still shamefully use "cp -pr" and "diff -r" anyway, and only git-commit right before pushing to github.
ubernostrum 17y ago
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.
- hyperbolist 17y ago
  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 http://news.ycombinator.com/item?id=1095116

traviscline 17y ago

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.

ubernostrum 17y ago
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 ;)
- traviscline 17y ago
  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.
  - ubernostrum 17y ago
    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...
    - traviscline 17y ago
      The possible workflows with git encompass hg workflows. You're obviously not interested in gaining anything but self-fulfillment throughout this thread.

ellyagg 17y ago

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.

ubernostrum 17y ago
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?
- tene 17y ago
  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?