Oh yes, indeed. Please implement it well or of not don't implement it at all. Nothing is as annoying as reading an article and having it snap back to the beginning, or suddenly staring at an error page.
Sure, for console-like applications like EC2 you cannot do without auto-update. However, on content sites that require longer attention to one piece of information, it is not necessary.
Does this apply to a Gmail or EC2 console kinda usecase? Going back to a previous version is essentially pointless because the state of your inbox/instances has already changed and that page is stale.
Note also that code of average architectural quality will require about 1 maintenance day per year per 80 LoC just by virtue (vice?) of existing. (Paul Graham: a full-time maintenance engineer can own 20,000 lines of code.)
This is true in my personal observation. I mostly wrote two pieces of software rougly 50,000 lines each, and it's my limit of manageability.
Will need splitting up and modularizing if it needs to get larger.
Why would they implement a feature that's in every browser anyway? They should just design the site so that changing the font size through the browser works.
Buttons to change font sizes are anywhere in a browser's default chrome, therefore 99% of people don't know you can do it.
In general, I think it's dumb, but have been on the receiving end of "add font size buttons". No amount of "but you can just hit ctrl-+" does any good.
I believe his point was that a web design should be resilient to the fact that users can do this with their browsers. Among other things web specific I assume. That seemed pretty obvious to me anyways.
What you mean is not in a mandatory fashion and at the C code level and that's true. But what I meant is that you can do it for the objects you manage, such as JS code and the rest of the webpage. It doesn't prevent an issue in the Firefox interpreter itself.
I can't follow what you're trying to say here. I'm probably just misunderstanding you. Someone suggested that Firefox had memory segmentation, and just did it with threads. That's obviously not accurate. Then you said, "they have it, just with javascript objects". What mainstream browser allows javascript in a tab to access objects in any other page, let alone another tab?
Depends on what JS it is. Obviously websites can't, but a huge part of Firefox is coded in JS, which runs with high privileges. It's perfectly possible that tab specific trusted JS code (including possibly extensions code) wasn't compartmentalized and now is.
Sure! Just keep in mind that a lot of that "trusted JS" is actually just a thin wrapper around C/C++ code, and the C/C++ code tends to be where the problems arise.
Git is not wrong by itself, there's just an impedance mismatch between it's model and a usable interface model. For most purposes, the index should completely hidden.
I would respectfully allow that anyone who can't comprehend what the index is for with the aid of two paragraphs and a diagram should be looking for an alternate career. The index is important. It's one of the great things about Git; without it, you wouldn't be able to create commits from a subset of the difference between your working directory and HEAD. It also has a confusing name, but here we are.
> It's one of the great things about Git; without it, you wouldn't be able to create commits from a subset of the difference between your working directory and HEAD.
I never understood that. I can do this just fine even with TortoiseSVN. Just click "commit" and select the files you want to include in this commit. I don't see how I need to keep yet another data structure / piece of "state" in the back of my head for that. I definitely don't see why I have to look for an alternate career because of that.
The benefit that the index gets you in such a situation is that sometimes you are working on two unrelated changes at the same time, but they both touch the same file. Git (using the -p flag to the add command) lets you interactively select portions of a file to add to the index.
The interface is pretty simple: it just shows you each small piece of diff to the files you are adding, and you say whether you want to include that bit of diff in the index or leave it in the working directory. Alternately, it can drop you into a view of the diff in the editor, and you can add or modify diff lines as you please.
Yes, you are; SVN doesn't allow you to commit parts of a file -- it works at the file level. Git allows you to commit an arbitrary subset of changed lines from whatever files you've changed in your working copy. It doesn't track changes to files, it tracks changes to content in its tree. See here for a more complete explanation: https://git.wiki.kernel.org/index.php/GitFaq#Why_is_.22git_c...
Yes. In git you can also do 'git add -p', which lets you interactively add pieces of a diff to the index, not just entire files.
Now, you could imagine an interface where you interactively select the pieces of the diff when committing, and I believe some VCSs do this. So, even though you were missing something, you weren't necessarily wrong. :)
But having the index can be useful if you want to build up the things you're going to commit over separate 'git add -p' sessions.
> [W]ithout [the index], you wouldn't be able to create commits from a subset of the difference between your working directory and HEAD.
That's a correct argument for why the index has to be separate from your working directory. But I don't see why the index has to be separate from HEAD ... in my model, every "git add" would automatically be followed by an implicit "git commit --amend". So instead of building up your commit in the index you build it directly onto HEAD.
Since you're remotely sane, of course HEAD is a private branch not a public one (because you're perpetually modifying "history" on it). (And to start a new commit, of course you also need a command which advances HEAD by creating an empty commit.)
To put it another way, the index should be just another branch. The git commands are way too complex because they don't treat it orthogonally.
I appreciate that you should have the option to choose which part of your working directory you commit. But I think the default should be to commit everything, like in SVN or mercurial. If I need to commit selectively in those systems, I'll disable some checkboxes, type in the filenames, build a changelist or use the record extension or something. The point is that I don't need to deal with it until I need it.
Also, it seems to me that git's behaviour encourages broken revisions (i.e. compiler errors, test failures) because your working directory doesn't match what you commit. And broken revisions will interfere with bisecting.
I think committing everything in the working directory is an awful default. Few developers are disciplined enough that the contents of a working directory always make a perfect commit.
With git, how you code is a non-issue. The whole idea is that you're able to to worry about commits afterwards. The index is a wonderful tool to help you untangle the mess of code that has not yet been separated into logical pieces. Working with git is not just writing out code and then committing it. Making proper commits requires time, discipline and practice.
Part of the problem might be the mindset that a VCS is supposed to record how the development happens, but if you think about it, that does not make much sense. The actual development process of a feature or even a bugfix is often riddled with experiments, trivial mistakes, sidetracking, and other largely uninteresting issues.
Once you have thought about what is logical to record into the repository and create a commit, you can test it. Git stash allows you to put aside all other work while you run tests, and git commit --amend allows you to fix the commit until it works.
Test your commits, and you will not have broken revisions or unbisectable history.
Yes, this is legitimate criticism of git's philosophy.
However, in practice i have seen those broken revisions in svn just as well. People forget to add untracked files or they skip the final unit test run. Basically, I believe your criticism is theoretical and no problem in practice.
Git requires a bit of a learning curve to use but it's gotten far simpler than subversion for me. I used subversion for years before using git. I refuse to go back.
If you always want to commit everything use `git add . && git commit -a`.
For me, I could learn git no problem, write wrapper scripts for some things, etc... But I'm not explaining it's idiosyncrasies to other people on my team.
In a sense, the index is an acknowledgment of the fact that the operation of "creating a commit" should be a two-phase process, similar to a database transaction.
Phase 1: Choose which parts of the working directory changes should be in the upcoming commit.
Phase 2: Actually commit those changes.
The separation is not entirely clean in Git. While this is very appreciated for convenience (e.g. git commit -a), it blurs the line and does cause confusion.
Indeed, the ability to work on code now and think about a commit later is freeing. As for the particular abstraction of how to represent the commit in progress... I like the working tree for that, rather than the index. It's just a better mental fit for me to unstage stuff I don't want to commit (via shelve/stash), _rerun unit tests_, do a simple diff without needing to remember the incantation for seeing what's in the index, and commit.
