Earlier quoted context omitted.
Where would you want to use `git commit-tree`?
It’s a convenient shortcut to take an existing commit and append to it a new commit that changes the file tree to any state you want. For example, if you want that new commit to result in the exact same file tree as another existing commit in the same repository, you can tell git commit-tree to make exactly that happen. It will also just print the new commit hash without moving `HEAD`, which is why it may also be use…
Why is it so hard to see code from 5 minutes ago?
421–424 of 424 posts
Re: Why is it so hard to see code from 5 minutes ago?
#422Earlier quoted context omitted.
That's an insane approach, eslint solves this just fine and is fully configurable for almost any style preference.
All Go code everywhere never has unused variables, never has unused imports, and is formatted similarly. But, when you're debugging a function, you can't leave unused variables or imports lying around. It's a tradeoff. I don't think either side of the tradeoff is insane.
Re: Why is it so hard to see code from 5 minutes ago?
#423Earlier quoted context omitted.
For the record, I think the second version is a clear improvement.
Out of curiosity, do you do much creative writing? I agree that the second version is clearer and more grammatically sensible, but the first version bends the normal usage of syntax to evoke emotion, although a word here or there could be adjusted. Here's an example of a similar update; would you say you like the second version more? "Halting, stuttering, his words slurred, his eyes watery, his knees trembling, he th…
Re: Why is it so hard to see code from 5 minutes ago?
#424I see it as a product named Multiverse Editing. You start off coding in the prime universe. Each Undo places a node on the current universe's timeline. If you continue editing you are still on the prime timeline. But you can click on any node in the timeline to go back, and editing from there branches to a new universe with its own unique timeline. Each node represents either complete before and after code for the current timeline and a pointer to the root of one or more new universes. you can select any two or three nodes and perform a merge which results in another new universe branching from the source (left) node of the merge. A database will exist for each source file, each representing their own multiverse. Source control events would become nodes on the timelines such as branches becoming a new universe and merges collapsing universes together. Ideally the database would be in the SCP and not the editor, though that might get slow, nut that would preserve the complete edit history for a file. Each node would have metadata where the developer could add notes in MD format, etc.