Well, Git stores code per se, for the rest of things it stores less data than either SVN or Bazaar (Mercurial, Monotone, Veracity).
It doesn’t track explicit directory renaming. It doesn’t keep branch history—if it did, reflog (which is local and only kept for 30 days) wouldn’t be needed. It only allows unique tags—so if you want to mark every revision where buildbot succeded to make both update and rolling back easy—you are out of luck (there can be a way—it is not obvious at all).
I have a complex enough deployment helper living in Monotone repository for which it is simpler and more natural to keep a few empty directories in the repository than to check-and-create from each of ten shellscripts. It is checkout-and-use, no other setup makes sense, so “just creating them in Makefile” would be suboptimal.
Tracking path by their content is not always good… It couples content changes with intent changes. If I need to make a copy of directory and then make the copies slowly diverge until they have nothing in common, I may want to mark which is for original intent and which is spin-off.
Branch history is not an inherently local thing.
When I have feature branches for recurring tasks, I will probably call them always the same. I will sometimes merge them with trunk and sometimes spawn them from the new trunk state. Later, I may wish to check whether some change was done in trunk or in the feature branch—it is quite likely to provide some information about commit intent. I can get it in every DVCS I know except Git easily—in Git I need to track DAG to get this information.
About succesful-build branch: for some projects I try to update to trunk head, and if it gives me too much trouble I look for closest previous revision which I can expect to work. In Monotone I simply mark some development commits as tested enough, there is a simple command to get all the branch.tested commits from the last month. This information says something about a commit, and to lose it I have to do something with the certificate that states it. In Git, rev-list behaviour depends on many things that happen later.
Linux kernel history is too big for any of the things I say to make sense for it. But in a medium project, I want to have access to strange parts of history to find out what happenned and how and what did we mean.
It looks like an estimation, not a VCS link.
Think of it this way: Vim undo history is a tree which you can walk visiting every branch (not that it’s a thing you want to do). Now, writing all this data out has some cost in IO bandwidth—comparable to bandwidth of the keyboard, i.e. kBytes/minute. Vim users don’t notice the cost of maintaining the tree in RAM.
Synchronising it at first opportunity is also not hard if you do it in the background and so latency can be tolerated most of the time.
The merges.. you can try to do them mostly on marked commits, and then they can be done just like they are done now.
But implementing all that is a great undertaking, to be sure.
There are some problem with DAG, too, because you are supposed to store the information with little meta-information.
There are precedents of tools wrapping Git command-line interface, so that part possibly could be fixed. I frankly do not know why nobody does it.
I know about “mkdir -p”—my non-problem (I was not going to use Git anyway for this project) is that I multiple places where to put it and if I miss one I will not notice for some time.
Saying that recreating something just in case right after checking out the new version makes more sense than simply storing along with all the rest seems to be exactly an example of tool imposing some workflow ideas on people.
I have two choices, you have one. My tool imposes less workflow ideas here. It’s totally information-theoretical.
I always try to do things so that they fail either often or never. Sometimes I don’t care much which is the case—if they do fail often, it is easy to reproduce and I will fix it with less effort than an elusive bug.
“mkdir -p” is not resistant to human error of not calling it / not including the file that does it in one of ten scripts.
“mkdir -p” means that browsing the VCS history you do not see the real layout.
I bother with VCS-based solution when it works better (and my “better” includes estimated time to catch trivial mistakes and ease of looking up old history) than “mkdir -p”. Dynamic working directory layout is something I have yet to see often, so I do not discard better-for-me solutions because of reasons unapplicable to current project.
Human mistakes depend on workflow. Do you often accidentally remove your checkout? And human mistakes in initial setups should cause the failure as often as possible when they happen.
“mkdir -p” before each cd will make the scripts considerably longer for no sane reason. And I have a few places in this very deployment helper system where “mkdir -p” before cd will make the failure mode less convenient.
And yes, all that is writen in shell script and I do use “mkdir -p” in the code where it made sense for my task at hand.
Somehow, most buildsystems for complex packages run make with changing working directories. Even in single script using subshells, it is trivial to save some effort with changing directories without complicating the code.
It is a deployment helper, not a single-package build system, so it has to do some work with numerous checkouts of dependencies. It is more natural to write some parts of code to run inside working directories of individual packages.
Well, now that you new that it is there, you could just type :help undo-tree. Basically, it is about g+/g-.
And the next chapter of undo.txt tells you about saving undo history.
Also, it gives Facebook full access to personalized LessWrong-browsing patterns.
Is there any incentive to hoard karma? Maybe we need to keep two values: Earned Karma and Karma Balance. In that case the only cost of sacrificing karma is opportunity cost, but I guess there will be only so many projects.
A more interecting question about up/down-votes is whether a person can change one’s mind after using karma/voucher in voting. On the one hand, LW should allow people to change their mind; on the other hand, it may create some strange dynamics if someone wants to support more projects than they can with the current amount of karma.
Showing more parameters will lead to different perception of post karma, and so it should be separately discussed.
Currently, many people think along the lines “I would upvote it from 2 to 3, but not from 4 to 5, and from 10 I will downvote it to 9”. So, even a non-controversial post can accumulate some upvotes and downvotes if some people find it overrated and some find it underrated.
Actually, I would be more interested in the size of checking core of Qea. Quickly inspecting 23 megabytes of proofs sounds like a bad idea. A converter to TSTP first-order proof format (for example) would allow me to use a few different bug-for-bug-independent well-tested checkers for this format that are already out there; that I would trust more than both human inspection and any single-implementation prover.
Facebook tried to argue that doing this violates its ToS (not doing this would violate law in many countries).
http://cyberghostvpn.com/blog/2011/09/newsflash-facebook-doesnât-like-privacy-2/
Using a distinct button for first click seems to be OK.
The question is the reverse—whether there exist people who would like to get LW karma as an acknowledgment of expected positive effect of their donation to SingInst.
It looks like Qea does verify the proof and generates human-readable text. In that case, my trust in it or Coq would be based on their relative size adjusted for amount of testing these tools received. Coq uses a non-trivially unique proof system (calclulus of coinductive constructions, if I remember correctly), which counts against it. Did anything look what proof system Qea uses?
The article feels overoptimistic.
What we can is to create few static motor control connections. If we need to create more, we would need to deal with routing problems—how to make sure nothing conflicts for the same place of 3D space. There is probably something about this in references, but no reference in the place it is mentioned. Or maybe we don’t yet know if we can solve this. Also, is there anything to cite about sensory connections in this place of your article?
It seems that some medical operations could temporarily freeze inter-hemisphere communication. It is quite obvious that re-merging the brain should be simpler than coalescence. Did anyone find any human volounteers to tell about the feeling of that?
Also, inter-hemisphere link could have some particular connection patterns which would be hard to reproduce—and without it maybe we need many more connections?
You say that cortex can shift functions around. But that probably uses changing some neurin connections, doesn’t it? Can exocortex connections bee mutable? Do we expect the neurons directly on the end of connections to reroute the connections? Do we have any ground to expect or not expect locality problems?
And if brain could be quickly trained to overcome all that, is there any ground to expect anything below complete merge with uncontrolled rate after some threshold of learning to use the connection is passed?
A technical note—“Paths to Coalescence” chapter seems to discuss only one—exocortices. Why use plural in that case?
ETA: I do not know the context and the likely effect of the paper on the people in the context. I just tried to explain why this paper feels optimistic to me by listing the unanswered questions that I had during skimming it (and then rereading part 3 to find out whether I missed the answers).
One-population single-parameter evolution seems to produce convergence, not explosion...
Of course, Subversion is still “majority” VCS even for open-source projects. Maybe people need something other than Git to change that—or maybe SVK should become more widespread way to use SVN.
And for the sake of speed and stability Git doesn’t store some data that every other open-source DVCS does store, and I have heard some Git users to say it is acceptable tradeoff (which is true for them) and some to say that nobody should care about this kind of data.
Of course, better tool is never a solution to tool ideology. Evaluating multiple other tools isn’t either—after doing it with DVCSes, I now hate Git and implicitly assume that every tradeoff there is not fit for the medium-sized projects I’d care about.