Do they belong to you? Claim these comments.
Unregistered
aliases
- William Tanksley Jr
- William Tanksley
- Wm Tanksley
William Tanksley Jr
Is this you? Claim Profile »
5 months ago
in Fine. Git is Awesome. on Caffeinated Simpleton
That's not entirely accurate... msys is a set of libraries to allow POSIX applications to (sometimes) run on Windows. Its entire intent was to get rid of the "compatibility layer" problem with cygwin.
I'm not saying you SHOULD be using msys or git; but I am saying that using it is no worse than using any other large, multiplatform library. Certainly Qt would be no better, for example.
There are better reasons; for example, one might dislike the atrociously slow performance of git on Windows after seeing so many people advertise its speed as being one of its best features. Perhaps one might dislike its slapdash implementation in an odd mixture of bash, perl, and C. (And probably others.) I would share those dislikes.
I'm not saying you SHOULD be using msys or git; but I am saying that using it is no worse than using any other large, multiplatform library. Certainly Qt would be no better, for example.
There are better reasons; for example, one might dislike the atrociously slow performance of git on Windows after seeing so many people advertise its speed as being one of its best features. Perhaps one might dislike its slapdash implementation in an odd mixture of bash, perl, and C. (And probably others.) I would share those dislikes.
5 months ago
in Fine. Git is Awesome. on Caffeinated Simpleton
As a committed Mercurial user and fan, I have to admit: well said. Git does many things better. Right at the moment Mercurial is better on Windows, so any cross-platform project needs to carefully weigh the options, but I find Git's current feature set to be more capable.
Also notable... Although Mercurial's historical refusal to deeply support history rewriting is well-principled and reasonable, Git's support for it is actually sensible given Git's architecture. It turns out that while Mercurial is built on the idea that a version control system should remember differences (and reconstruct the actual files), Git is built on the idea that a version control system should only remember files (and store differences only to save space). Thus, when you edit a Mercurial history you're forcing Mercurial to alter the most important data it has; when you edit a Git history you're merely changing some files (usually only removing files), no different (in principle) from checking in a branch.
Mercurial's architecture makes perfect sense, and gives it a huge head start in speed and size; but Git's architecture really does preserve the things that matter most (the actual files), which makes inherently risky things like rewriting history relatively risk-free.
Thumbs up to Git for a flexible and sensible architecture.
I'm still using Mercurial for its superb Windows support (sorry, guys, gotta use it); but I'm keeping my eye on Git. (By the way, aside from extreme slowness, Git also hasn't gotten git-svn working reliably on Windows -- at least not while I've been watching.)
Also notable... Although Mercurial's historical refusal to deeply support history rewriting is well-principled and reasonable, Git's support for it is actually sensible given Git's architecture. It turns out that while Mercurial is built on the idea that a version control system should remember differences (and reconstruct the actual files), Git is built on the idea that a version control system should only remember files (and store differences only to save space). Thus, when you edit a Mercurial history you're forcing Mercurial to alter the most important data it has; when you edit a Git history you're merely changing some files (usually only removing files), no different (in principle) from checking in a branch.
Mercurial's architecture makes perfect sense, and gives it a huge head start in speed and size; but Git's architecture really does preserve the things that matter most (the actual files), which makes inherently risky things like rewriting history relatively risk-free.
Thumbs up to Git for a flexible and sensible architecture.
I'm still using Mercurial for its superb Windows support (sorry, guys, gotta use it); but I'm keeping my eye on Git. (By the way, aside from extreme slowness, Git also hasn't gotten git-svn working reliably on Windows -- at least not while I've been watching.)
- 2 points
- Jump to »
1 year ago
in Shortcomings of Mercurial on Humanist → Blog
I'm glad to hear git doesn't try to be clever and detect the merge markers. I'll hold off until I figure out a way to get it to not insert the markers in the first place.
I think I found the mailing list at http://dir.gmane.org/gmane.comp.version-control....
I think I found the mailing list at http://dir.gmane.org/gmane.comp.version-control....
- 2 points
- Jump to »
1 year ago
in Shortcomings of Mercurial on Humanist → Blog
I'm not on my Mercurial computer, so I don't know what it ships with. The feature you're listing is a new feature of the core Mercurial, and doesn't describe the berkwood package. That one actually does come with all the graphical tools I've been able to ask for (i.e. everything seems to work out of the box; I've even played around installing tons of different plugins).
1 year ago
in Shortcomings of Mercurial on Humanist → Blog
I have a question for a git guru.
Git looks really cool; I just found a Windows (mingw) port, so I'm happily working with it. It seems very slow, but I'm sure that'll go away with time. I love git-svn.
The question: is it possible to disable git's insertion of merge markers? I really like how Mercurial never alters a file; when a merge is needed, it's treated as a basic attribute of the repository, not a local problem in a file. This means it's NEVER possible to accidentally leave merge markers in a file (something I've had happen on several different CVS-using projects).
Git looks really cool; I just found a Windows (mingw) port, so I'm happily working with it. It seems very slow, but I'm sure that'll go away with time. I love git-svn.
The question: is it possible to disable git's insertion of merge markers? I really like how Mercurial never alters a file; when a merge is needed, it's treated as a basic attribute of the repository, not a local problem in a file. This means it's NEVER possible to accidentally leave merge markers in a file (something I've had happen on several different CVS-using projects).
- 2 points
- Jump to »
Jakub Narebski
@William Tanksley Jr:
First, when there is a merge conflict, Git leaves all three versions (base / ancestor, ours, theirs) in the index (commit staging area), and stores file with merge markers on filesystem. So you always have easy access ("git show :1:<file>" for example to get base version) to all versions.
Second, default pre-commit hook which ships with Git, and is by default installed in newly created repositories, detect merge markers in file (and also things like trailing whitespace) and refuses to make a commit if it looks like you didn't resolve a merge. You just have to enable it by making it executable ("chmod a+x .git/hooks/pre-commit"). Of course you can foce skipping verification phase if the tool misdetected merge markers with --no-verify option.
Third, you can use gitattributes to set merge driver for specified files, for example for all files, or/and you can use merge.default configuration option, choosing e.g. "binary" driver which leaves current version of file in the working dir in the case of conflicts.
BTW. why didn't you ask this question on Git mailing list or on #git channel on FreeNode? Git mailing list is open; you don't have to subscribe to post. Just make sure to specify that you'd like to get messages replied also to you, and/or read mailing list via mailing list archives or GMane NNTP (Usenet, news) interface.
First, when there is a merge conflict, Git leaves all three versions (base / ancestor, ours, theirs) in the index (commit staging area), and stores file with merge markers on filesystem. So you always have easy access ("git show :1:<file>" for example to get base version) to all versions.
Second, default pre-commit hook which ships with Git, and is by default installed in newly created repositories, detect merge markers in file (and also things like trailing whitespace) and refuses to make a commit if it looks like you didn't resolve a merge. You just have to enable it by making it executable ("chmod a+x .git/hooks/pre-commit"). Of course you can foce skipping verification phase if the tool misdetected merge markers with --no-verify option.
Third, you can use gitattributes to set merge driver for specified files, for example for all files, or/and you can use merge.default configuration option, choosing e.g. "binary" driver which leaves current version of file in the working dir in the case of conflicts.
BTW. why didn't you ask this question on Git mailing list or on #git channel on FreeNode? Git mailing list is open; you don't have to subscribe to post. Just make sure to specify that you'd like to get messages replied also to you, and/or read mailing list via mailing list archives or GMane NNTP (Usenet, news) interface.
1 year ago
in Shortcomings of Mercurial on Humanist → Blog
Regarding merging tools on Windows: I installed the distro from http://mercurial.berkwood.com/, and it comes with all required tools. I didn't even know there was a bare-bones distro, although I knew it was possible to configure.
- 2 points
- Jump to »
Luke Hoersten
Good Find. Looks like that's new since February 25th:
Out of curiosity, what merge tool does Hg ship with on Windows? These comments look like it Hg will only try and detect what's already installed.
"2008-02-25: Mercurial 0.9.5-434139080ed4 - Version 0.9.5 + fixes through 2008-02-25.
NOTE: This version includes the new standard merge logic that tries to detect appropriate merge tools. I've enabled the sections from contrib/mergetools.hgrc in the default Mercurial.ini that the installer writes. See hgrc.5.html in the Docs subdirectory for more information on the syntax."
Out of curiosity, what merge tool does Hg ship with on Windows? These comments look like it Hg will only try and detect what's already installed.
3 years ago
in OhGizmo! » Archive » The Wind-Turbine Cellphone-Charging Taxicab on OhGizmo!
You guys should be expecting the inefficiency; read the cited purpose: "The initiative is intended to promote the use of clean energy in the context of the Kyoto Protocol."
In that context, it's all about looking good by doing SOMETHING, no matter how ineffective.
In that context, it's all about looking good by doing SOMETHING, no matter how ineffective.
3 years ago
in OhGizmo! » Archive » How Things Change on OhGizmo!
I had one of these with a TRS80 model III someone gave me. Actually, mine was only 5MB, but it looked the same, just wider.
4 years ago
in Are Libertarians Cheerier? on Will Wilkinson
Cheerful? I'm sorry, but I have to disagree. Or I have to change my reading list. The libertarian blogs I read talk endlessly about the sheer horror of the obstacles we face, how deceived everyone else is, and so on.
Almost none of them say ANYTHING about optimism, much less about how specifically to achieve the changes we want.
I'm an optimistic libertarian. I enjoy reading left, right, center, and libertarian writings. I like thinking of ways to solve things (while making money).
The rationales I see here for libertarian cheerieness would depress me if I believed them. I should be cheery because conservatives have a twinge when they vote for Bush, or because conservatives play dirtier than liberals? Please! Stop salivating; Pavlov's left the building. I should be cheery because I believe that people are basically good and don't need oversight? Then why do the people we have keep on setting up horrible oversight?
There's a much better reason to be cheerful -- it's because we're working for change, and we know what we're doing. I believe most of us know what we're doing, but most of us aren't doing anything.
So hop to it! Make those changes! And stop whining, for heaven's sake. It's not a political failure; it's a business opportunity!!!!
-Billy
Almost none of them say ANYTHING about optimism, much less about how specifically to achieve the changes we want.
I'm an optimistic libertarian. I enjoy reading left, right, center, and libertarian writings. I like thinking of ways to solve things (while making money).
The rationales I see here for libertarian cheerieness would depress me if I believed them. I should be cheery because conservatives have a twinge when they vote for Bush, or because conservatives play dirtier than liberals? Please! Stop salivating; Pavlov's left the building. I should be cheery because I believe that people are basically good and don't need oversight? Then why do the people we have keep on setting up horrible oversight?
There's a much better reason to be cheerful -- it's because we're working for change, and we know what we're doing. I believe most of us know what we're doing, but most of us aren't doing anything.
So hop to it! Make those changes! And stop whining, for heaven's sake. It's not a political failure; it's a business opportunity!!!!
-Billy
4 years ago
in What is Big Government? on Will Wilkinson
I dunno -- I'd consider this a big, but impotent, government. They have control of 100% of your income; the fact that they right now only take 1% of it doesn't imply anything about what they'll do tomorrow.
In fact, the best description I can think of for this situation is that this isn't a big or small government; it's an enormous nonprofit corporation. It lacks the one crucial element to make it a government: the legal monopoly on the use of force.
-Billy
In fact, the best description I can think of for this situation is that this isn't a big or small government; it's an enormous nonprofit corporation. It lacks the one crucial element to make it a government: the legal monopoly on the use of force.
-Billy
Errr... I think I haven't been clear enough. With Git you can either detect merge markers in (default, you only need to enable it) pre-commit hook and refusing commit unless overriden with --no-verify.
Or you can change default file-level merge driver for some files or for all files (using combination of gitattributes and config) from "text" (which inserts diff3 -E like merge markers) to "binary" (which leaves 'our' version on disk and does not insert any merge markers).
BTW: http://git.or.cz/gitwiki/MailingList