21–30 of 42 posts
Earlier quoted context omitted.
Someone who knows this stuff please tell me if I my analysis is correct: I see smart people pointing out "flaws" in software, not realizing the solution requires strong AI. (e.g. yesterday's post: http://news.ycombinator.com/item?id=2455793 )
Merging associativity doesn't require magic AI.
Earlier quoted context omitted.
Someone who knows this stuff please tell me if I my analysis is correct: I see smart people pointing out "flaws" in software, not realizing the solution requires strong AI. (e.g. yesterday's post: http://news.ycombinator.com/item?id=2455793 )
Merging associativity doesn't require magic AI.
The above article gives us a simple example (A vs B) of a situation where doing the right thing requires a human aka strong AI because you need to know the "intent" of commit.
Is there a simple solution - or even a complex one - which would not require a human to verify?
For a similar analysis of yesterday's post, see this comment: http://news.ycombinator.com/item?id=2455970
Earlier quoted context omitted.
Someone who knows this stuff please tell me if I my analysis is correct: I see smart people pointing out "flaws" in software, not realizing the solution requires strong AI. (e.g. yesterday's post: http://news.ycombinator.com/item?id=2455793 )
Merging associativity doesn't require magic AI.
David Roundy, the initial author of darcs, seems to disagree on this. From https://github.com/droundy/iolaus : > I realized that the semantics of git are actually not nearly so far from those of darcs as I had previously thought. In particular, if we view each commit as describing a patch in its "primitive context" (to use darcs-speak), then there is basically a one-to-one mapping from darcs' semantics to a git repository.
Note that darcs implements the "expected" or "naive" semantics, at the cost of edge cases that have exponential time (rather than going ahead with unflagged inconsistent merges).
Another interesting case: http://www.kernel.org/pub/software/scm/git/docs/howto/revert... I'm not sure if the "forget whatever happened" metaphor works for me. In the "revert a revert" article above, the problem is that merging a topic branch doesn't cause the first few commits on it to be applied if those commits were already merged but then reverted -- the revert has no effect on the merge. This is precisely becaus…
Note that darcs implements the "expected" or "naive" semantics, at the cost of edge cases that have exponential time (rather than going ahead with unflagged inconsistent merges).
The really big insight Linus had that Brahm apparently still doesn't want to recognize is that if that if you design what essentially a snapshotted filesystem, the merge algorithm is just a convenience. Any better merge algorithms can be added to git without touching the format. In fact any individual user can pick and choose their merge algorithm that the repository just cares about the recorded content history (whi…
Earlier quoted context omitted.
The really big insight Linus had that Brahm apparently still doesn't want to recognize is that if that if you design what essentially a snapshotted filesystem, the merge algorithm is just a convenience. Any better merge algorithms can be added to git without touching the format. In fact any individual user can pick and choose their merge algorithm that the repository just cares about the recorded content history (whi…
Git also stores diffs from time to time: http://book.git-scm.com/7_how_git_stores_objects.html
Earlier quoted context omitted.
The really big insight Linus had that Brahm apparently still doesn't want to recognize is that if that if you design what essentially a snapshotted filesystem, the merge algorithm is just a convenience. Any better merge algorithms can be added to git without touching the format. In fact any individual user can pick and choose their merge algorithm that the repository just cares about the recorded content history (whi…
Git also stores diffs from time to time: http://book.git-scm.com/7_how_git_stores_objects.html