11–20 of 43 posts
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'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.
"rm -rf" is dangerous. A versioning system should allow you to get by without doing dangerous stuff.
laptop:~/version/loom$ rm -rf 86.12.before_prune
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.
"rm -rf" is dangerous. A versioning system should allow you to get by without doing dangerous stuff.
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.
Earlier quoted context omitted.
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,…
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.
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.
Earlier quoted context omitted.
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,…
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 codeba…
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.
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 li…
So I'll pose it in different terms: why haven't you given into the network effects of, say, Visual Basic?
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 li…
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 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,…
In lots of ways git is a superset, branch workflow included.
Earlier quoted context omitted.
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,…
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 codeba…
http://stackoverflow.com/questions/255202/how-do-i-view-git-...