When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew. I might copy-paste existing code (just to avoid stupid transcription errors). If its too large to see both what I'm writing, and the old code, at the same time, I just use two windows on the same file.

This is relevant to writing fiction or non-fiction as well.

For example, I didn't like this, so I commented out:

>though his companions jogged just behind him, he would have barely seen them at all had he look. They ran, with their heads down, attentive only to their feet slapping the muddy earth, tracking the path they followed, their breath ragged.

and wrote this, using the commented-out text as a reference:

The fog was now so dense that he could see nothing ahead of him. He ran with his head down, breath ragged, attentive only to his feet slapping the muddy earth, tracking their path. His companions followed close behind.

I do the same - both commenting out and viewing the file in parallel at different spots - vim vertical splits are great for that. In fact, one of my colleagues remarked that he never thought to view the same file alongside itself when he saw me do that when we were pairing.

As an aside, I think I wouldn't mind if a programming language would include two commenting syntaxes, one for ordinary comments, and another for commenting out. These are two very different use-cases, and distinguishing them syntactically might facilitate certain kinds of work-flows.

A common code style rule for C# is // for comments and //// for commented out code (/// is reserved for documentation generation). StyleCop analyzers can enforce this during code analysis passes.

While this isn’t a language construct (a comment is a comment after all), Visual Studio can key off these stylistic differences to show code comments vs commented code differently. I find it to be a neat trick to improve code readability.

Cool.

I've never touched C#. But that seems like an approach applicable pretty generally. I like it!

I thought //// was psuedo reserved for documentation. and then // was for general comments. I usually use block comments for commenting out code or I just use VS hotkeys which I think are //

It’s actually /// (3 slashes) that reserved for pseudo-documentation use.

There’s a StyleCop rule to enforce this as well:

https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/ma...

I've never seen this in C# code! How common is this? Do you have any references? Sounds like a useful convention (it's nigh impossible to google). VS only distinguishes between `///` (docblock) and all other (double, quadruple,quintuple, /*/). But maybe there's an extension.

Here’s more about commenting style:

https://github.com/DotNetAnalyzers/StyleCopAnalyzers/blob/ma...

StyleCop is used for analyzing code style in C# code.

Specifically:

> If the comment is being used to comment out a line of code, begin the comment with four forward slashes rather than two.

StyleCop relies on this to tell the difference between commented code and code comments. If you use ReSharper, it can do some nifty transformation to strike these out in the IDE which is kinda cool too.

I’m a big fan of StyleCop to enforce consistent code styles. (Even if it’s not always what I may aesthetically prefer.)

Perl and Ruby have this. In Perl it's kind of an abuse of the perldoc system, like this:

    print "foo"
    =pod
    print "won't run"
    =cut

Ruby basically copied it, although I don't think these have documentation uses:

    puts "foo"
    =begin
    puts "won't run"
    =end

When I get to choose, I prefer sticking to // in C code so that I can use /* ... */ for hiding large blocks of code . . . although #if false ... #endif work too.

In C, you can wrap the 'commented' code with #if 0 ... #endif

Or indeed if rewriting a block of code:

  #if 1
    ....new code...
  #else
    ....old code...
  #endif

Esp. for tricky stuff, it's then possible to just flip the 1/0 to easily test/compare/profile the new/old code.

Some IDE's will even work out which block of code to colour and which to dim.

Why have I never thought of that?

I do the same, even in languages without a preprocessor.

You can just use a life if-else, most compilers will optimize the test-on-a-constant away. Even when the code is kept in, I doubt it will have a major performance impact during testing in most cases.

I would do a bit more by

   #if !defined(this_works_but_it_suck_memory_too_hard)
   ....
   #else
   ....
   #endif

That should give me a clue why I "disabled" it when I come back to it 5 minutes later.

I usually just do this with a comment behind the #if false. Yes, nobody is probably ever going to define that particular identifier, but comments are also less restrictive (you can write normal text).

In languages with multiline comments like /* and single-line comments like //, you can do:

    //*
    old_code();
    /*/
    new_code();
    //*/ 

And remove the first slash from the first line to switch between blocks.

Yes! Just today I was wishing that I could have syntax highlighting on commented code that I was refactoring. Just dim it a bit instead of turning it all grey.

It's not a formal distinction, but in C++ code where all the ordinary comments use //, it can be handy to use /* ... */ to comment out a block.

(Of course, if there's a stray /* ... */ comment already in the area to be commented out, this will fail. But an editor with appropriate syntax colouring can make that immediately apparent.)

I like to put a space following the // if it's written text comments, but no space if it is commented-out code.

I think the space looks nicer for text comments, but when I select a block of code and hit Ctrl+/ to comment it out, my IDE does not add a space. So it works out very conveniently for me.

I'll sometimes use:

    version (all)
    {
        ... new version ...
    }
    else
    {
        ... old version ...
    }

and change `all` to `none` to try the other branch.

Scheme has #; which comments out a single expression. This covers most but not all use-cases. (It doesn’t help for commenting-out subsequences, like if you wanted to remove the top half of a begin block.)

Sometimes I do stuff like

   // FIXME try new way mm/dd/yy
   if(1)
   {
     ... new way ...
   }
   else
   {
      ... old way ...
   }

Hrm, but it's obvious if somethingis commented out code vs an actual comment. I'm probably missing something here.

I use this workflow a lot and while I’m still figuring out how I want to implement something. I’ll often just do the whole thing in one file, commenting, and rewriting and restructuring code as I go with multiple open windows to different parts of the file. I only break it up when I’m happy with the abstractions, and I know where the natural fault lines run between functions, classes and concepts.

Doing this too early feels wrong; like I’m prematurely committing to a division of responsibility that’s going to subtly drive me to a bad design.

> one of my colleagues remarked that he never thought to view the same file alongside itself

I do this all the time in Emacs, usually to see two parts of the file that normally are too far apart to be visible at the same time. Collapsible sections can do similar, but to me it's quicker, more natural and more flexible to just split the window.

Another good trick in emacs (if using git and magit) is `magit-find-file HEAD <file>`, then you can edit in one window and see the old version in the other

It actually never occurred to me to do this. Perhaps because I tend to use command-line git, even when using an IDE. I haven't learned magit yet, and I know people swear by it. But this does look like a pretty good way to go about it, at least if your commits have a fine enough granularity.

I think this workflow comes particularly naturally in Emacs, since anytime you split the window (e.g. C-x 3) the current buffer sn already duplicated in the new window. You have to change the buffer in the new window if that is what you want. You can do this in your IDEs too (like Pycharm) but the option to do so doesn't exactly leap off the screen at you.

Vim does a similar thing to Emacs here: the `:sp` and `:vs` commands take an optional argument that, if given, loads a file in the new window. Otherwise the new window just contains the same buffer.

This is exactly what I do. Vim split of the same file, one side for editing and the other for context. Works great!

Commenting is the answer. It stays until I'm certain I no longer need it.

This is the one thing above all else which has kept me off Go. Tentatively comment out a line or two and the whole compilation process may come crashing down because now you have a declared but unused variable, and mere warnings apparently aren't Gestapo enough in this particular universe. You then find and comment out the offending declaration, only for the compilation to die in flames again because now you reference a never declared variable. It gets tiresome after a while.

Are unused variables really compiler errors in Go? That does seem very harsh, and very counter productive while developing. -Werror is all well and good, but while I’m in the middle of writing the code, it’s a bit much.

The theory is that given enough code, any antipattern that compiles will make its way into real use, and therefore the only way to make people stop using an antipattern is to refuse to compile it. Go trades inconvenience in the short term for removing an entire class of bugs and raising the readability floor of bad code.

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.

You can do underscore import and local variable to workaround this limitation and I have seen that in the code.

Sounds like a good argument for a --relax-im-just-trying-something flag for the go compiler, and taint the resulting code with it so if anyone else tries to use the code without the same flag, then the compiler/linker will complain.

They were, last time I looked. Which was admittedly a while ago.

Golang is impossible to use without an IDE like VSCode. Tried it with Sublime Text without a language server and it was a nightmare like you described. Less problematic with VSCode cause it'll add/remove imports automatically on save and have big red underlining for anything that will cause it to not compile.

My approach is similar to this, except for whole functions/classes I tend to just create a new one with a version number. e.g. DataContext => DataContext2.

When I'm satisfied that DataContext2 does everything that DataContext does, I delete old one and rename DataContext2 => DataContext.

The risk here, is that sometimes it's not possible to migrate everything to the new version and you end up with multiple old versions lying around, i.e. technical debt.

I do the same, but the opposite way, hehe - I rename e.g. "DataContext" to "DataContextOLD1", then I write the new "DataContext" (from scratch or by copying the original one and then modifying it), this way I'm sure that all calls to DataContext always use the new version.

I do this too! A big benefit is gradual migration - for example, if I'm injecting DataContext into a bunch of different places, I can implement part of the functionality of DataContext. Once I have just enough functionality implemented to support one of the places it's injected, I update that place to take DataContext2. Then I can test, and move on to the next place.

If you're using a language with strong typing and good refactoring support (right now that's C#/Visual Studio for me), the eventual rename from DataContext2 to DataContext is a non-event.

I do the same. Many people comment about commiting frequently but that doesn't work for me: delete code + commit => I don't see the code anymore and my brain magically forgets about it. I need the quick feedback loop: commented code + uncommented code (all in one screen) => new code is going to look like a mix of both. If I have to use git to see commented code then the feedback loop is broken.

Commiting frequently also has a substantial cost of needing to think of a commit message.

If you don't think of a commit message, you'll never be able to find this version again. If you think up a message every 2 minutes, you'll quickly find you spend more time thinking of commit messages than writing code.

I wish there was some kind of auto generated commit message. Things like:

"Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c".

These could be auto generated, and then commits could happen in the background every time the code is compiled.

It would be nice for git to have some kind of "commit of commits" which allows a hierarchical representation of commits. Ie. the "Add new printscreen feature" could have as subcommits "Create print renderer" and "Hook up print UI".

> I wish there was some kind of auto generated commit message. Things like:

> "Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c".

I would argue that these are not good commit messages as they do not add information not already provided by the diff itself. Commit messages should communicate the intended effect of a change that has been made, rather than being a lossy compression of a sequence of keystrokes.

In which case I want a lossy summary of the diff... And it would be great if a tool could generate those for me...

Try `git log -p <path(s)>`, which will show the sequence of diffs for only the specified set of files.

> It would be nice for git to have some kind of "commit of commits" which allows a hierarchical representation of commits. Ie. the "Add new printscreen feature" could have as subcommits "Create print renderer" and "Hook up print UI".

These are usually called feature branches.

> "Added function xyz()" or "Adjusted constant FOO to 27" or "Made lots of changes in file a.c,, b.c and c.c".

These are very poor commit messages that don't add anything of value; any diff viewer will tell you the same immediately, so you might as well leave it blank.

> Commiting frequently also has a substantial cost of needing to think of a commit message.

In larger, private feature branches I'll use loads of "asdf" commits that I will later squash together. These are my "ok, so far so good" points to make figuring out where I broke something easier.

People are getting way to hung up about their commit history in most cases. If you're just experimenting, even "asdf" can be a totally fine commit message. And it shouldn't be hard to come up with something at least a little more descriptive in <20 seconds. Remember that in some situations, what you get from git is basically a glorified backup system. And that's valuable!

You can edit the history later when it's required by somebody else working on the code.

Or you can just not care. 99% of the value of your git repo should be in the most recent commit.

Looking at other people's code I vastly prefer a feature branch with a summary name of the feature "new-checkout-flow" or whatever and then the commits as they where without squashing/rebasing. Mine tend to have quite a few commits cycling through:

  - Stub in [classes/models/etc] for checkout flow
  - Add basic test coverage
  - Fix my API for easier testing
  - Decouple foo from bar in new flow
  - New checkout flow mostly tested
  - New flow UI cleanup and add comments
  - Fix nasty [N+1/O(n^2)/etc] performance bug in new flow
  - New flow feedback from acceptance testing
  - New flow ready to merge
  - [And often enough/honestly] "WIP to share with..." or just 
 "WIP" for work in progress, "Fixing bug in" or whatever reality there was.

Going back at `git blame` etc 5 years later i can see from the branch names linked to the commit the why it was added and from the commit messages I can see something of at what point in the mental processing of designing/implementing that exact line made it it.

On the other side of the coin I hate looking at git blame to find a bunch of now irrelevant stuff, like fixes to code that were only ever in your branch. I don’t generally care about the discoveries you made along the way (at least not in commit form) unless I’m doing the review for it to go in the main branch, and even then it’s more of a curiosity than anything particularly relevant to software quality.

I wanted "squash merge" to work for me to handle this. Full history in the feature branch for detailed git blaming and a single 1000-line merge commit in main with "New Checkout Flow" but i never fully groked getting it to work when you are merging upstream branches into you feature... You end up taking credit/blame for the upstream commits on main and I feel like you could overwrite the real history of that.

I agree. I also think commit messages get more detailed the further along the process is, and the less code you change.

“Added unit tests and stub out api” (50 files) vs “fix bug when files are added too quickly” (1 file, 3 lines)

If you don't already know the commit message before you start writing the code, maybe you should wait to write the code.

What's to stop you doing all these commits locally with uninformative messages, then squashing them when you push/PR with a better message?

Putting low-effort comments into temporary commits is OK. The one can use interactive rebase (git rebase -i) to squash and edit it into a coherent and clean history, when things get closer to finished.

You don't need to think about good commit messages. Just something that works for you and then rebase before pushing. That works for me at least

I use GitKraken (or insert your favourite git GUI) and I don't have this problem. If I ever have a "wtf did I do 10 minutes ago?" moment I can just look at GitKraken real quick and feel like a stenographer reading back notes.

I typically have it open beside my IDE so I can keep an eye on the progress in the file tree view. I can drag-select a set of lines, right-click and stage them, when I'm basically locking those in, then keep going.

It also auto-fetches every minute or so, so I have great visibility on what coworkers are doing in the commit graph. Lets me react to what they do pretty quickly, and I can implicitly review what they do and I can poke them if I notice something weird.

I also use my git GUI to quickly review what changed before making the commit. That way not only I filter out irrelevant chunks/files, but I also compare the new lines to the old ones.

I get this for tracking down a bug or working on speeding a block up. But why does the unused code need to be committed? Yes it helps you with your one problem but it clutters the document with extra information for others. So I guess I phrased my question a little accusatory, commented out code is a pet-peeve of mine, but I'm still genuinely interested why the two different blocks need to be committed. Or i guess more importantly, if they need to be pushed to the mainline for others to recieve

Maybe I misread the parent, but I don't think it was stated that the commented out code is committed.

FWIW, I also sometimes work this way; however I delete the commented out block when I'm finished. This is also a pet peeve of mine, the only time commented out blocks of code are acceptable is if the obvious way to write something introduces a bug or ignores an edge case. In that case, I also leave a note explaining not to refactor this section and explain why.

But especially while refactoring or fixing certain issues, I really find it helpful to have the prior version still present to compare against. If I have to commit while that commented code is still present, invariably my last commit message is along the lines of "removed commented code" or "cleaned comments for function XYZ". Especially since for these cases I also typically end up writing a comment once finished anyway. If there was something tricky enough happening that I was comparing against older code, likely there is something confusing enough happening that whoever is in the file next could also use some additional explanation that can only really be written once finished.

> When making changes to a block of code or block of text, I frequently just comment out the code and rewrite it anew.

This is the comment I came here for. (see what I did there?)

I also sometimes keep multiple versions of the same line in comments, such as when I'm trying to a tricky regex work. For example, I might have code that looks like:

  # x = regex1 # Original line
  # x = regex2 # Doesn't work
  # x = regex3 # Nope
  # x = regex4 # Also nope
  x = regex5 # Currently testing this

That gives me the way to see which approaches I've tried while solving the problem, and ensures I don't actually use the same exact regex twice.

When I get a working solution, I comment out all but the line that works and commit that.

In this case, keeping those in the commit might be worth it, if you come back and find that the regex wasn't right after all. That way you can make sure you (or others) don't repeat your mistakes. The comment could go in the commit message instead I guess, though I tend to keep those brief.

> I frequently just comment out the code and rewrite it anew

That still doesn't give you easy access to the state of the code _halfway through the rewrite_, which is what the article mentions.

I do this, though it can get messy when I'm experimenting with multiple changes.

As an experiment recently I've taken to keeping snapshots of active work areas using rsync every minute that there are changes present - an automated full-tree version of "keeping copies of the file" that works for everything (images, word processor docs, ...) not just my code editor, avoids an accidental change when doing undo-redo "breaking" the redo buffer, and it survives explicit file closes which undo/redo buffers usually do not. There are two significant caveats: it only works at all if I save regularly while tinkering (or the editor auto-saves regularly), and it doesn't work for files mmap-ed or otherwise open-locked by the editing process. Not terribly efficient IO wise, and still wouldn't be with the improvements I know I could make but haven't got around to, but it has proven helpful at times and takes very little space for several days of snapshots most of the time (identical versions of the same file in each snapshot are hard-linked not duplicated).

Shouldn't it be "had he looked."? Also the second rendition makes doesn't include what the rest of the joggers are doing, yet the first one does. Not sure if intentional.

At first I gasped at your practice, because I never do that, but I see the point now. Mastery of language.

Yes, I had a typo. I was editing in place, and then decided that I had made some poor choices and needed to start over. I didn't bother to fix the typo.

Yes, there is a shift in point of view between the two versions. But the story is mostly written in third-person limited, and so my first version deviated from that.

But I rewrite everything every time I read it, so who knows what will happen tomorrow.

> Also the second rendition makes doesn't include what the rest of the joggers are doing ...

Something is amiss here.

Karma/backlash for my rude post. I will leave it unedited, but s/makes// in case it is not clear.

I didn't take it as rude. Should I have?

I used to work like that. Now I don't. (And I would advise against it.)

Use version control, do lots of small of commits, use diff. Have a fast edit, build, test/run cycle. If you don't have it then spend the time setting it up.

<sarcasm>My employer told me a 23-step code submission process, across five tools, that takes four days to run all the tests is fast enough. Is that fast enough?</sarcasm>

Exactly. Lots of comments. People afraid of doing changes. Or removing old unused code. Not fully understanding what is going on. All signs of a broken development setup. Spend the time and do it right. You will be paid in multiples.

Huh, I thought your first example was much more poetic. The vaguely run-on sentence does a much better job of evoking what's happening in the scene.

Thanks. I'll think about it.

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 thrust forth the knife, and with a cry the blow was struck-"

vs.

"His knees trembled, his eyes were watery, and spoke in a steady stream of unintelligible nonsense. With a cry, he thrust forth the knife, and the blow was struck."

In both, the aloneness of "him" is the focus. In the first, his companions are the subject of both sentences. In the second, The fog and "he" are the focus, with his companions only mentioned as an afterthought.

When editing lab notebooks, it's customary to finely cross a line through data or notes you wish to discount without affecting their legibility. It's also expected that any edits or annotations be circled, dated, and initialed.

The point is that data is never destroyed, and this is one of the many causes for the unflagging preference for tangible records over ELNs.

How do you comment things out in the "English fiction/non-fiction" programming language?

I'm writing in markdown. I use the quoting > character, instead of the more verbose [comment]: #(my comment) syntax. Emacs markdown mode changes the color of the text, and that is enough for me. I use the [comment]: $(my comment) syntax for actual commentary on the text.

I do the exact same i was thinking this article was silly..

Sad to see so much judgement in this thread from developers who can't fathom why others would need this. "Sounds like trial an error." "Develop a better memory."

Programming is not black and white, there is no right or wrong way to do it. OP discovered a problem they had and wrote a solution for it, believing that others might need to solve the same problem. Clearly they were correct based on plenty of others chiming in with their own anecdotes, or tools they've discovered that help alleviate the same issue in other ways.

If you've never had to UNDO/REDO a block of code to revisit a previous state before moving forward again, kudos. But suggesting those that do are somehow going about programming in the wrong way is not constructive.

> the wrong way is not constructive.

Well, open minded people can try other ways. Mine is sitting back and thinking instead of racing the keyboard to try out stuff until it works. Both ways (as I compare to my exclusively younger colleagues) reap results in about the same timespan, but I hardly type more than the actual code I need to type while my colleagues write and delete books ('iterate fast') in that time. It both works, but I have several converts who now work like me and actually enjoy it more (not to mention far less chance of RSI).

Whatever works for you I would say.

What is a bad thing though is that it also has to do with the pressure put by WFH in some companies and sites like Upwork => a lot of 'managers' (and sorry, I cannot say anything positive about these people, but their number increased rapidly during Covid in my experience) measure productivity of an employee by keystrokes, screen changes and # of commits. Even though I finish more tasks in a day than most of my colleagues in our projects, according to those metrics, especially keystrokes and screen changes, it looks like I'm doing 'nothing'. Whatever.

It sounds like you are a software engineer. My advise for you being confronted with these metrics is to look around a bit at other workplaces. I am not saying that you should quit, but it doesn't need to be this way.

Well, I don't have that issue, but I know quite a lot of people whose workplace changed to that. I would refuse to work like that, not to mention that keyboard logging etc is not allowed here in the workplace.

> productivity of an employee by keystrokes, screen changes and # of commits.

Aaargh, that's the most quality destroying metric possible.

The most easily gamed as well... I have no idea how these people thinking about introducing a metric to measure others don't realise that whenever that happens it just becomes another game.

It really isn't that hard to know that through experience and a little bit of forethought.

The other day I introduced this idea to a team member.

We have a separate budget for "development" and "hardening" - these two are actually stages - one starts only after the other ends and that moment is already precisely scheduled. No QA team so far.

So we play this little game of delivering something, anything and allow ourselves to leave some details behind.

I know of multiple problems in my code which made it past review, because there's no incentive to block merging on grounds other than code style, and maybe some glaring issues.

My gut feeling is that this approach is more expensive.

My guess is that the code that was thought through first will be better (easier to understand by the next developer) than the code generated by many iterations.

Most of the times you'd be right. But some of the times you'd be devastatingly wrong. You always need to check your assumptions about runtime, expected behavior and so on and there is only so much modeling you can do in your head. At some point - if the scope is too large to fit in your head at once - you will need to resort to divide and conquer, implement the part that you understand, regroup, then do the rest. And before you know it halfway into doing 'the rest' you will realize a better way to approach the problem.

I actually think this is part of the problem- there is excellent tooling for making programming much, much easier, but many programmers are unaware of how to use them.

When I was an undergrad, I wrote code in a text editor without syntax highlighting, I debugged using log statements, and I manually tested every change by running my program manually with different inputs.

Of course those are all fixed by pretty basic things, but you would be surprised how many programmers literally don’t know how to use the tools they have, or are unaware of them. And some tools are downright hard to grok- git is definitely one of those.

> I actually think this is part of the problem- there is excellent tooling for making programming much, much easier, but many programmers are unaware of how to use them.

Isn’t that just called “experience”? It’s understandable that junior engineers don’t know these tools exists, but most will learn them after a few years.

If you’re curious and interested enough, you’ll wonder if there are better ways to do things. Or talk to more experienced people and ask them how they do things.

I don’t think this is a “problem”, it’s just part of the process of becoming an experienced engineer.

Development often times entails a lot of trial and error, and there is nothing wrong with that. If you have fast iteration cycles, you can fail many times before you settle on an optimal solution.

That usually depends if you are writing something from scratch, or wrestling with other peoples libraries.

"Sounds like trial and error"

Isn't that what coding is?

People obviously have different preferred ways to think, and this holds for programming just like for math or any other cognitive endeavour. Compilers, type systems, REPLs and so on are specifically designed to be thinking aids, and it seems to me that using them to their full extent to augment one’s cognition is a perfectly valid way to write code.

I try to rememberf my local history view in the editor, it sometimes give a better overview.

For anyone that uses emacs, there is an excellent plugin "undo-tree" that solves this problem in a slightly different way. Everytime you undo a series of actions and then perform a new action, it creates a branch in the "tree". You can then visualize the tree and move through it quickly your entire buffer history.

Another cool thing about undo in Emacs is that it's context aware.

By default, you can select any block of text and the undo command will cycle through the changes only from that region of your buffer.

whoa this is cool

does it understand syntax boundaries like curly braces / functions? ('undo within function' would be key). or just line #?

That concern is isolated to your region selection tool, and orthogonal to the undo functionality :-) So, you could select by lines, or intelligently select by parentheses/braces, etc. And ask these are nicely composable, so you could easily set up custom shortcuts if you don’t like the sequence of keystrokes.

For eg, see https://www.johndcook.com/blog/2017/08/09/selecting-things-i...

Regions in emacs do not need to consist of whole lines.

For those that use vim, gundo.vim visualizes the "undo-tree" and allows you to preview / jump to any revision: https://github.com/sjl/gundo.vim

There's a fork called mundo which has an inline diff mode that I'm a big fan of — https://github.com/simnalamburt/vim-mundo

Came here to post this. The undo tree is actually built into Vim, but I didn't know about it until I discovered Gundo a decade or so ago. I rarely use it, but it's still installed and has saved me hours of work on a few occasions.

Even without undo-tree, Emacs undo history is "persistent". By that I mean that changes aren't overwritten, so the statement in the article that undoing stuff and then making edits loses the undone changes is not true for Emacs. You just have to undo back through the new edits, then you will start to redo the old undone edits, and so on. It can be tedious, but just the knowledge that it's all there is quite liberating.

Another vanilla feature I sometimes use to keep track of old code is the "kill ring". Just cut the old code and it will be available in there later if needed.

And to get something closer to OP there is always undo-propose.el[1].

[1] https://github.com/jackkamm/undo-propose-el#screenshot

This this this. It was the first thing I missed in Vim when I switched. You also don't lose in Vim, as it keeps it the history as a tree, but it is harder to navigate the tree than Emacs' linear history.

This was my first thought. A timeline is nice, but the problem with a linear undo history is that if you undo and then edit, you lose access to the state before you undid. A tree is clearly the right structure for undo history.

You could just append a new state to the end of the timeline when you “undo”, so you never lose history. This is how undo works in Emacs by default.

Heck it's how boring business apps handle bookkeeping data since forever. You never delete a record to correct a mistake, you create a new record to do it.

The tree structure is inherently flawed for storing undos when using features like undoing within a specific region, because the new state doesn't map to any previous node on the tree.

By default, Emacs has a linear undo structure, while still allowing you to never lose history.

Newb emacs user here. Heavily reliant on spacemacs and tutorials and copy-paste, but I use it often.

The undo-tree terrifies me.

It’s easier to mentally map that the default behaviour undo/redo for Emacs (which is not unreasonable, just complex).

The source for undo-tree contains documentation which very effectively describes the way the library works with examples and comparisons with how Emacs does things by default: https://gitlab.com/tsc25/undo-tree/-/blob/master/undo-tree.e...

I was too at first, until I learned the shortcut keys (to move to the next branch specifically), then everything was fine.

On this point, C-h m yields a complete list of keybindings for all modes active in whatever buffer you do it in.

More generally, for anyone new to Emacs and struggling as I once did, I can't recommend strongly enough that you learn how to use the help system (C-h C-h) and the built-in manual (M-x info). Emacs can teach you a great deal about itself, and these are the ways it does so.

It's easier than it looks! Poke around with the arrow keys a little. You'll get the hang of it pretty quick.

Tangentially, have you had the issue where undo-tree just uses a ton of memory and makes everything unusable?

And if you use IntelliJ/Android Studio there's Local History, which shows your git revisions but also periodic versions of your code outside of your commits

Undo in region is also pretty useful if you want to revert part of your code but not all.

It can even persist history across restarts if you set undo-tree-auto-save-history.

Came here to post this. Tho most times my undo tree are single characters.

You should work on you long-term memory for the language's keywords, or on your variable naming ;-)

EDIT: Or are you programming in APL?

guilty on the latter. tho only contributors to my packages and coworkers complain about it. I am fine with it.

I immediately thought of this, it is so good, like a source control-lite.

Something I always thought might be useful: I want to select a region of the code, and undo that, while keeping everything else unchanged.

My favorite IntelliJ feature is that it tracks the full history of the files in your project, losslessly and independently from your VCS. You can just go and pull source from Local history, from 5 minutes or 5 days ago (I'm not sure how far back it goes, I've never needed more than a week).

Not something I use often but as a last ditch effort to find code that I've spent hours or days on and subsequently lost to a git mistake, or reverted thinking I was going to use a different approach, it's worth the price of entry for the JetBrains tools alone.

Is that the stuff stored inside the .idea folder?

According to the documentation, they're stored under your user's home directory, separate from the repository: https://www.jetbrains.com/help/idea/local-history.html#locat...

Local History has saved me many times.

So does eclipse. The author seems unaware of similar solutions that have existed forever...

But then you end up having to clean up your git history before committing to the shared branches, with squashes and rebases, which is annoying.

Cleaning up your history isn't hard if you think about building a clean-up-able history from the start, where each commit is a unit. At least it is easy for me. If it's larger and complicated, I create branchname-v1, branchname-v2, etc. branches and squash. Those branches will still hang around in my fork of the repo should anyone need them.

As for my personal projects, I recently realized that using leveldb wasn't going to cut it for me right before I finished the database storage feature. I still finished it to create a commit that didn't break the build and then worked on switching to rocksdb. If in the future I decide to switch back to leveldb, it's always there.

Not as annoying as learning to navigate some IDE-specific way of doing it. And I usually end up cleaning up my commits, anyway. Also, if I've committed things, then I have commit hashes to refer to in my notes.

this is indeed useful, but what the parent comment is referring to is it also stores with local history outside of git. So you can check both git history for a selection, as well as local history that exists since your last commit.

I use my editor's history heavily, but never needed something beyond the Ctrl + Z / Ctrl + Shift + Z history to access things done immediately prior. If I'm unsure if I'll need some approach in the future, I make a commit. I've become increasingly good at this prediction.

> Want to know what we saw developers doing instead? They either duplicate code files or took screenshots of relevant code while in the middle of a change. Even I have done something similar before: I'm about to mess this up... I'll Ctrl-A and Ctrl-V this into a new tab before it gets too messy, and then I can put the window beside my editor to use as a reference. I even observed a professional developer with 20 years experience doing this!

I do this kinda stuff all the time in my digital art practice. Duplicate a layer, hide the duplicate, start making changes. Does it work better? Awesome, delete the duplicate. Did my idea not improve it after all? Cool, delete the new version and rename the duplicate back.

It's simple and reliable and builds easily on existing structures.

I made a similar comment and now I recognize that what we’re doing is branching outside version control. And I also recognize it’s still sensible to do, and that to the extent version control feels like friction this is yet another case where the interfaces to it aren’t good enough.

And I don’t just mean “git cli is a bad ux” (though I mean that also), but that the whole world of version control is poorly serving rapid prototyping and other exploratory flows.

It’s pretty likely aliases could serve some of this by wrapping a lot of fast paced idea checkpoints into a set of git actions. But it still would be disruptive for eg any intermediary file system side effects if it’s not faster than whatever watcher you have running.

if git was just ctrl+s or something similar (i.e. no more than a single keyboard shortcut sequence) then this whole problem would disappear, but because even in vscode it's "navigate to source control tab, ctrl+enter, enter enter(if something is not saved) "type some stuff" enter" it's too much to save "tiny" changes. not to mention reverts are a hassle.

because of this comment I just decided to create a keyboard shortcut for commits to be alt+cc so now it's a little easier, I still need to type a commit message and accept save and stage, but at least it's all doable from the keyboard.

Oh hey, I've built this! My version would watch code files and snapshot a diff every few seconds. It took a little work to tweak the constants to keep the watching performant, but it was super neat being able to replay code. The main problem I faced was that changes often occur in different places in the file, so the history replaying jumps around a lot. With some proper editor integration, I could see it being pretty useful.

My version is super incomplete because I kind of lost steam when I couldn't figure out a really great reason why someone should use this, but hey, maybe it's worth another try: https://github.com/nicholaslyang/codemkin

I would 100% use this! I do exactly what is described in the note. I use undo/redo a lot to traverse between two states of code and found this incredibly frustrating.

Until this point I thought that was just a bad practice on my end, so never saw the need/opportunity for something like a state slider.

Honestly never thought other people were using undo/redo like this.

I also use undo/redo like this and it has gotten me into frustrating locations on a couple of occasions... but still better than needing to break my flow to drop into making some well formed commit.

I understand how to do WIP commits etc, but its helpful to do a rewind/fast-forward that includes all the character changes in-between the logical “blocks” of diffs. It often helps me recapture approaches to problems that I’ve already attempted.

I used to use the history function in NetBeans to do this. Has been around for several years apparently. Many other editors seems to have this function too.

For me "Local History" feature in WebStorm solves the issue. https://www.jetbrains.com/help/webstorm/local-history.html

I've found Local History on these JetBrains IDEs to be really helpful too. Particularly when combined with "Put Label" command (which I assign to a keyboard shortcut). This lets you insert a descriptive label info the stream of your local history snapshots (such as before you attempt something), so you can go straight to one of those labels and diff against current. Useful when you're trying out an approach with parts that may be discarded, as it's handy for reverting lines of current or overwriting and inserting blocks back from the snapshots. You automatically get a label after certain events, like a test fail or VCS commit. I think there's a snapshot after every save too, and you can configure autosave to happen whenever the editor pane loses focus of you want to.

The only things to watch out for with local history in these IDEs is that the snapshots are deleted after five days by default, and all are wiped if you need to delete your IDE cache for any reason.

It has even saved me when I managed to delete a file not checked in yet. Just recreate the file with the same name, and then local history is available (or possibly local history on the parent folder would find it as well)

This is part of the IntelliJ IDEA platform, so all of the JetBrains IDE products have it. I don’t use it often, since I normally rely on Git, but it’s saved me several times after I accidentally deleted a file or made a mistake with Git.

Indeed it’s one of the reasons why I’m staying with JetBrains products. It’s really efficient, we can compare side by side the local history to understand where it went wrong all while keeping the git history clean. Because while I could do the same manually with git, when I’m in the flow thinking about/building/debugging a particular piece of code, moving out to select files to add to git and then filling a message for that piece of code that isn’t working and doing that every few minutes to preserve intermediate state is a nightmare for my productivity.

It can and should be done automatically by the IDE to enhance developper productivity by getting out of its mind. There is no reason why I should be thinking about that, isn’t that all the point of using IDE and tools to develop ? Seems like using git for that is still re-inventing the wheel

It has also been in stock Eclipse since at least around 2010, when I started using it.

True so did I, for web development though I prefer Webstorm. I was thinking of VSCode

Yes love this feature! I also try to get the habit to put in labels more often, it really helps to have some landmarks to navigate from.

This feature is absolutely outstanding, I use it all the time. Unfortunately they buried it in the "File" menu recently. It was so much easier to reach when it was unter "Version Control".

It's also accessible from context menu in the editor, I use it from there.

You can assign a custom shortcut to it via Settings > Keymap and then the action "Main Menu > File > Local History". I myself have assigned the shortcut control+shift+=

Thanks, did that. I decided on Alt+Z, because Ctrl+Z is Undo, so I though this makes sense.

And Ctrl+Alt+Z is revert changes. Either the whole (or selected) file, or the current block you're in. I use it all the time.

I've only recently started using JetBrains tools - and I did not know this feature existed!

Thanks for mentioning it - absolutely perfect!

This is my most used IntelliJ feature

> Why is it so hard to see code from 5 minutes ago while in the middle of a change?

In vim you can do:

  :earlier 5m

to see the code you had 5 minutes ago.

> (1) If you go to a prior state and then make a new change, you can no longer redo and all those changes are lost.

Vim makes a tree, so that doesn't happen with it. When you undo and make a new change, you're just making a new branch. u/Ctrl-r goes from leaf to trunk, but with g-/g+ or :earlier/:later you can walk the whole tree.

Emacs similarly doesn't lose changes in this scenario, but instead of making a tree, it has a ring and undo is an action that can be undone.

> (2) You can not see a side-by-side comparison of the previous version and the latest version.

It's probably not complicated to make a macro or function where you go to a previous version, copy the buffer, paste it in a new one on a new window, return the original buffer to the state you were in, and diff the windows for that side-by-side comparison.

A command like so suffices:

  :earlier 5m | %y | later 5m | diffthis | vnew | put | 1d | diffthis

> (3) There is no visual indicator of where you are are in your undo/redo history.

Not by default, no. :undolist provides some info, though, and the vimscript undotree() function probably provides all the state of the undotree. There might be plugins that somehow present this info in the interface.

> (5) I have found many actions in code editors that do not get added to the undo stack (e.g., changing a debugger option), which caused me problems in the midst of an annoying bug.

In vim, only stuff that changes the buffer is added to the undo tree. Navigation or changes of the state of the editor (e.g. editor options or vimscript variables) aren't added. Are there really editors where adding actions that aren't changes make sense?

> (6) There is no indication of what steps were "big" or how long ago they happened.

That's also true in vim it seems, at least how "big" they where. Each step does have a timestamp, though.

> (6) It is tedious to backtrack one small step at a time.

You can backtrack by however many steps you want. :earlier also supports specifying by seconds, minutes, hours, days, or file writes.

Most cool of all is that vim can persist the undo history. I don't know how common that is among editors, but in vim you can go to a file you haven't opened in years and undo it all the way to its beginning.

> > (3) There is no visual indicator of where you are are in your undo/redo history.

> There might be plugins that somehow present this info in the interface.

The undotree vim plugin [1] does this, and gives both the file at the time as well as a diff of what changed.

[1]: https://github.com/mbbill/undotree

> undotree

I was going to mention this plugin. I haven't fully mastered quickly jumping around in it, but it's one of those things that when it's useful, it's VERY useful.

Ditto. Unless I have to go back a lot of edits, I don't actually use the plugin that often. I've mapped my undo/redo keys to traverse the undo tree instead of the undo stack:

nnoremap u g-

nnoremap <C-r> g+

It takes a little bit of getting use to, but it takes care of most instance where I need a previous edit from a minute ago.

> Are there really editors where adding actions that aren't changes make sense?

Adobe Photoshop is one. Selection changes don't modify the document at all, but they are part of the undo stack. That's because selecting a part of an image isn't as trivial as selecting text.

Sometimes I wish the current selection could be automatically saved in the file too so you could start where you left off if you were halfway through making a complicated selection (I know you can manually save selections, but that's an added step).

I don’t know about Photoshop, but the selection is part of the document in GIMP.

> Most cool of all is that vim can persist the undo history. I don't know how common that is among editors, but in vim you can go to a file you haven't opened in years and undo it all the way to its beginning.

I absolutely love this feature. I regularly open a file and undo/redo to figure out where I was editing last.

NetBeans also have this but it's set to 7 days as default. Never looked into this before, just thought it was broken but you can save it for eternity if you want :-)

Wow, I have a lot of vim learning to do. Your pipeline is far beyond my level.

| in vimscript is like ; in other languages. I'm not sure pipeline is a good name to call it. It's just a list of commands run in sequence.

> In vim, only stuff that changes the buffer is added to the undo tree.

There is also a command history, and jumplist (movement cursor position history) for things that don't go in the diff tree.

> Emacs similarly doesn't lose changes in this scenario, but instead of making a tree, it has a ring and undo is an action that can be undone.

Emacs default undo system is really, really bad. Like worse than the "standard" one. But after installing the emacs undotree it becomes sane.

What is bad about it? It always goes back to the previous state, and if you want to skip previous undo states (so you don't undo an undo) you can use `M-x undo-only`.

It's been over a decade since my bad experience so take my words with a grain of salt. Iirc, the issues I had was that I made a huge history of undos-followed-by-redos-followed by-undos-etc etc and the more I navigated my history the more tangled and out of control it became. I think I also had a problem with often accidentally switching from undo to redo mode. Emacs documentation recommends using C-f (forward-character) to switch to redo mode, but in my opinion attaching side effect to movement is awful.

I agree. It's cool that it's lossless, but doing a lot of undos and redos makes the history quickly unwieldy to navigate. I much prefer vim's tree implementation.

I wouldn't say that it's worse than the standard, though. Unwieldy as it may be, I like that I can just keep on pressing C-/ and eventually get to the state I want without risk that I may have lost it because I accidentally made a change after a series of undos.

> Emacs documentation recommends using C-f (forward-character) to switch to redo mode, but in my opinion attaching side effect to movement is awful.

I use C-g (keyboard-quit) for that, which is the general let's-not-do-this-anymore keybinding. I think the documentation mentions C-f as an example keybinding that does the needful without much thought on being the "best" keybinding for it.

> doing a lot of undos and redos makes the history quickly unwieldy to navigate

Are you aware of the `undo-only` (and `undo-redo`) functions? They make it a breeze to navigate even the most complex undo history.

Actually, I wasn't. Thanks for that.

(undo-redo) doesn't seem to be defined in stock Emacs, but undo-tree defines (undo-tree-redo), which does the needful.

My comment was more about lamenting the defaults in comparison with vim's, but it's true that it doesn't take much configuration to make it much better.

undo-only doesn't have a keybind which makes it inconvient to use many times in a row. You could define one yourself I suppose, but at that point why not just get undo-tree?

The issue I have is that I want to be able to use C-f and C-g and many others without it changing anything about my history.

This seems cool. Is there an equivalent feature in emacs ?

What particular feature? :earlier 5m? I'm afraid not. Emacs' C-/ acts like :earlier/:later/g-/g+ in that you can navigate the history across undos, but there's no support for specifying by number of minutes. I don't know if there's a package for it though. Evil-mode (vim emulation in emacs) doesn't seem to have support for that either.

I can't imagine it'd be that complicated to add it though, if you really want it. I think it'd just be a matter of hooking to the undo function and maintaining a list of timestamps for each item added to the undo list, then adding a command that lets you specify the number of minutes and figures out the correct undo item it should go back to by using that list of timestamps.

JetBrains' various apps can do this as well with a feature called "Show Local History". I'm not sure where it is in the menus but you can hit shift twice and type it in.

It automatically commits after every change since the IDE was opened, and can easily be diffed and reverted as needed. Reverting saves another entry, so you can revert back to the future as well.

This. I've seen developers _think_ they lost code in Android Studio and spend hours trying to recreate it when it was in local history all along...

It's in the context menu for files/classes at least.

IIRC you can right-click on the column with line numbers to the left of the main editor and you'll have that option too

Eclipse has the same thing.

If you learn Vim like anything else - slowly and starting with the basics - it's not more complicated than figuring out any IDE. And once you know the basics you are fully in control how deep you want to go.

Personally I have found Vim more approachable than IDEs actually. It doesn't throw all those overloaded toolbars at you according to some one-size-fits-all principle. For me it went so far that last year I actually did a Java project in Vim instead of an IDE for the first time, because the latter had grown to be so frustrating to use.

If writing text more than 4 hours / day is what you do for a living, and you have at least 10 more years left of doing that, not learning Vim is just lazy. Vim gives you back enough time to think about what you're writing.

Also, if you go cold turkey, you'll be productive in less than a month, and arrive at a good workflow that fits you in less than six months, flow that you will improve over the years in amazing ways.

And there are a lot of people, like myself, who do use vim regularly and somehow completely missed this feature. For those people the OPs post is excellent.

Likewise, if you have any recommendations for your preferred workflow I'm sure some will find it useful. Hopefully those who don't use your preferred $EDITOR don't then rush to complain that not everyone uses $EDITOR. ;)

I am one of those "not willing" people. I encounter the same issue discussed here without even thinking about it, and solve it as such:

1. Realize I need to check how my new code looked like 5 min back. 2. Copy full file into clipboard, undo by a few steps 3. Do a temp commit on GitHub desktop 4. Paste the new code back and look at the diff on GitHub desktop, and if needed undo the temp commit from above.

Is this more clicks than the vin shortcut? Sure. But I don't have to go learn the internal tree structure representation of my text editor and spend my time in that universe. I have found a way to do what I need to with the tools I have in hand.

This is the same way how the majority of finance runs on excel when they could do better with better programing. In the end whether you get the job done in fields where you're not billed by the second is not dependent on how well you use your tools necessarily.

The other analogy is cars - for most people it's something that gets them places, for others it's a way of life if not at least a more involved proposition.

> The other analogy is cars - for most people it's something that gets them places, for others it's a way of life if not at least a more involved proposition.

But if code is your way of life, which it is for many people here, it is beneficial to learn the tools that allow you to do it easier. If someone can see how their code was 5 minutes ago in a few keystrokes, they’re going to take advantage of that significantly more frequently than someone using your cumbersome method.

As some other comments suggest, vim is the gift that keeps on giving. I'm not going to try and convince you to use it -- do whatever you want.

But for me, every little thing I learn in vim pays off... a thousand times? Macros alone have probably saved me a cumulative few hundred hours. And with every other little thing I learn, compounds with this effect. I write macros much better than I did five years ago, but I still surely have tons of stuff to learn. No IDE will ever compete because vim is just four keystrokes away at any time, no matter where my terminal is.

Not so sure about this, I think it depends on how frequently you have to do that task. If you're doing it every day or even every week you could potentially be saving a huge amount of time and effort by using a tool that does the job well. It's sort of like using a random heavy object as a hammer, sure it's fine in a pinch if you need to occasionally hang a picture but if you're working as a carpenter it's counter productive. Comparing it to the notorious abuse of excel spreadsheets in finance is not doing the argument any favours.

It's not as hard to learn as people say it is. It's just weird at first because it's modal and different than what they're used to. You can get away with using it pretty naively and still get a productivity gain.

Jetbrains IDEs have a local history feature that provides snapshots with diffs and allows partial rollbacks.

I only use it when experimenting with different approaches.

Mostly I only use the "Local Changes" tab in the Git panel that shows the diff compared to the last commit, or "Compare with branch" to see the overall changes relative to the base branch.

Local history saved my sorry butt yesterday when I thought I lost all my files due to a git-related accident. But Local History still had all my changes and restored my files.

Unclear why this isn't baked into the OS nowadays. It's not like we don't have enough disk space ;)

I just saw something similar on Twitter[1]: a script that takes a ZFS snapshot after every command. This lets you jump back to the state of the whole filesystem after every single command that you ran, giving you a sort of global history.

I figure you could adapt that to something a bit more restrained that you could use on an ongoing basis to have a "Local History"-style feature for your whole OS :).

[1]: https://twitter.com/grhmc/status/1362222849662935041

That looks amazing. I've used NetApp NFS filesystems that provided user level snapshots, where it automatically created snapshots of files. It wasn't after every command, but at regular intervals. You could access the files under `.snapshot` directory.

Searching now, it looks like this is part of NetApp ONTAP, and managed by a snapshot policy.

VSCode also has a local history plugin. One of my default installs https://marketplace.visualstudio.com/items?itemName=xyz.loca...

Thanks for sharing this. Does it have a draggable slider? Or ability to "Play" through changes?

I have the feeling JetBrains do not understand how important this feature is for some developers. It does not have a shortcut and recently got buried in the File menu, almost as if they are ashamed of it. I am using it all the time and life would be much harder without it.

In NetBeans there is two big buttons on top of every file view. Source and History. Very easy to get to and has been used a lot :-)

I came here to write this comment. I use this feature often and, like the sibling comment, it has saved my butt a ton! I love JetBrains IDE with Vim bindings

this! Indeed, JetBrains IntelliJIDEA had this feature for decades, I use it very often. It’s just a lifesaver.

I've gotten in the habbit of just commiting very frequently. I have a git alias "git cam" that just commits everything with the message "nt". Then once I've got something working, I use GitUp (which makes it very easy to merge/split/rearrange commits) to collapse all the nt commits into one or two coherent "real" commits.

Maybe a little clunky, but works well for me.

Basically same deal here, though using 'magit' and 'wip' instead of 'nt'. ('No text', one assumes?)

Doesn't help with IDE settings and such, but that's such a niche situation that it doesn't matter at all for me.

Does anyone know if there’s a good way to do this in VS Code? I often hold cmd-z until I get to some version and copy code from it. Ideally I’d like to have a separate window where I can see a previous version without affecting the current file/view.

Before anyone comments, git doesn’t cut it for this because no one commits after every -+1

Like an ongoing stream of history where I have a slider I can drag to revert on-the-fly.. That'd be cool. I mean you could easily record and do this, but that doesn't copy-paste well.

EDIT: And of course I read the article after reading the comments.. Haha, VS Code plug-in in 3.. 2..

One thing I think would help this is a dual repo setup with the local dev-only repo automatically committing on save (or if your watch is expensive committing unsaved editor state on pause). The repo could be short lived if you prefer (eg new per baseline repo branch or editing session) or a long lived series of stashes. But its history would be built into the editing experience and separate from the normal version control flow. I don’t think it would necessarily work for everyone but it could certainly fit how I work in exploratory mode without breaking my editing flow.

Yeah that is the simple and very effective solution of this whole problem. If I had to use I would use something like this.

This solves another problem I had, so I’ll try it, but it’s completely unrelated to edit history.

Don't know if it serves any other purpose than coloring, but if you want to just go back to the last (and next) edit locations, Visual Studio already has a shortcut for that (Ctrl+Shift+'-' / Ctrl+'-')

this looks like it does that https://github.com/zabel-xyz/local-history

not super polished nor is it actively maintained but has promise

Here's the vscode marketplace link for it https://marketplace.visualstudio.com/items?itemName=xyz.loca...

I use it with every project and it works great. Helped me out a bunch of times. Just need to remember to ignore the .history folder from git and other tools.

Commit early, Commit often!

If I have to commit my whole undo history then I’m using git very wrong. I commit (even temporarily) to save progress, but only when it makes sense to so. Sometimes I don’t know whether I’ll need this specific version again in the future.

Git doesn't mandate to only commit useful stuff.

This is correct, not sure why you’re getting downvotes. Feature branch for WIP makes sense.

But if there are more people in the team, it will be a great amount of noise they will have to go through before reaching any useful commit. Definitely not recommended.

There's a difference between committing to your local tree and pushing it to others. You can always cleanup before pushing.

`commit` doesn't mean `push`. Commit locally, rewrite history with rebase before pushing it to others.

That's still way more overhead compared to undo/redo

I take it you didn't read the article so.

In Git you don’t have to actually commit, you can use the staging area. It’s something I do rather often. I’m going to make a non-trivial change and I’m not sure if it’s the right approach, so I `git add -A` first, make my change, and then `git diff —-cached` to review it. This is especially useful when doing things like running formatting tools, so I can see what the tool just did. And it doesn’t require making any commits.

Having said that, this approach only works if I know up front that I’m going to want to compare the code. Far more often is making a change and then realizing I want to see the old version. A history timeline would be extremely useful here.

Even commits are malleable until you push them somewhere. I do this a lot - create commits of any meaningful checkpoint, then rearrange/squash/remove commits later that I don’t want , to create a well-formed commit that I push.

Git stash can handle your use cases too, but commits are more powerful as they let you compose multiple pieces together

You can also use git commit --fixup, or, to fix up a commit with message “wip something”, you can make comments with messages like “fixup! wip something” or “squash! wip something” and git rebase --autosquash --interactive will reorder them all (squash! allowing you to stack commit messages by writing in the commit bodies)

Yes. I usually maintain a hefty stack of commits where the top ~5 are experimental WIP nonsense for me to either clean up to or discard, the next ~10 might be code out for review. But in between pushes to remotes, every session of changes turns into a slew of fixups and I'm often rebasing a stack of 30+ commits, massaged into 2-3 change sets.

I have the same, but now at work we use the GitHub squash function in PRs. I still make fixup commits but don’t have to rebase to manually squash them any more.

Trivia for you: git stash is actually storing the changes as a set of stacked commits on a hidden branch. You can even do a git log or amend on your stash, although the stash abstraction is pretty complicated under the hood.

If you work on a branch you can push them to your remote repo anyway. Good for backups or if you move between hosts for any reason (I do this all the time as I prefer static workstations for focus and work/life balance.)

Branches rightly became a bit of a dirty word over the last decade. In a fast moving collaborative codebase the pattern you really want to avoid is using a long running feature branch — one that remains uncommitted to trunk for ever more uncomfortable periods of time.

Branches themselves — the VCS technology part — are incredibly useful when used fluently.

Eh, I use the dumb approach of:

    cp code.d code.old

if I'm going to make some trial changes :-/

Nothing wrong with that :)

No commit is involved at this point, only the staging area.

In CoCalc, one of the foundational ideas is that it should be very easy to see code and Jupyter notebooks from 5 minutes ago. Hence every editor in CoCalc includes a TimeTravel button, which you click on to get a side-by-side view of your file (or notebook) and a slider that lets you go back and forth in time at high resolution. I designed CoCalc this way because when I taught data science classes, I would walk around a classroom while the students were doing an in-class exercise and they would often say to me "I had this part figured out 5 minutes ago, but I messed it up." Some people (including me!) who get used to working this way get very addicted to it, and can hardly imagine working any other way. This is vastly superior to depending on undo/redo, and I use it all the time when doing deep coding projects. It's also useful for collaboration, since it makes it easier to figure out what somebody else did with a file or notebook.

Reading the comments, I'm stunned and disillusioned.

Are most modern developers struggling to write code without this? If so, there is a fundamental problem that has nothing to do with levels of undo.

I am more stunned by the tone your response. Why are you implying there's a "struggle" or "fundamental problem"? Sorry but your language is very condescending.

Sometimes it's easiest to hit Cmd+Z a few times to check out how something looked at an earlier stage of a change. And then it's easy to Redo everything back to the current state. Rewinding changes back can even jog your memory as to why you did something. It's fast, simple, and effective. What's so bad about that?

Likewise. This whole thread is totally bizarre.

The closest imaginable thing I might do is wrapping some block of code in an if(false) {..} or #ifdef it out, when I'm refactoring and feeling unsure about my changes. But is that even the same thing that we're talking about here?

Hello from the bizarro universe of people who do this all the time and can't imagine the opposite. Do you never rewrite some code only to realize it didn't precisely capture all the edge cases of the thing you rewrote? In those cases I use the git gutter in VSCode to view what the old code looked like and compare and contrast to the new version to see what I missed. It seems to me that that's the same as what these engineers are doing, just with a bit more primitive tooling.

Can't imagine how anyone doesn't do this - unless there's just a race of God-programmers I've never encountered that write everything perfect the first go. But I don't think so. :-)

Exactly. Sometimes you start heading down a change path, and as you discover more, you realize there is a better solution. You want to save some of your concepts, but discard others. That's what this helps solve.

Git stash can be helpful. Stash your "wrong direction" change, then apply just the good chunks from your stash.

TDD (test driven development) really help in solidifying interfaces ahead of time and also to capture regressions.

Yes, git diffs help, but once I’ve passed a parameterized suite of unit tests, never needed to undo/redo. Maybe not perfect the first go, but only need one/two tries to working code. Then refactor for readability.

TDD is definitely helpful, but I don't ever use it as a metric for code fitness. At best it proves a limited number of inputs produce a limited number of expected outputs.

Consider, for example, a bug recently introduced during a refactor at my work:

The programmer optimized a conditional based on a regex by transforming it into a simple string compare. All the tests passed, code/branch coverage was good. Except that he missed that the regular expression tested case-insensitively, and our test suite didn't test upper and lower case scenarios.

This simple mistake outlines a few flaws:

- coverage was not robust, because it didn't take into consideration the branches inside the regex (which one could interpret as a form of macro expansion)

- the limited number of inputs used to test failed to capture the broader domain of possible input

- the test did not reflect a successful refactor

Obviously this is a fairly complicated example despite a pretty simple change, and several pieces had to fail in order for this change to fail. But it affirms that even basic changes to code aren't necessarily adequately covered by TDD.

Yes, the developer who forgot to test different letter cases made a mistake. Yes, regular expressions bring their own problems. But fundamentally, the result was that passing the tests did not affirm fitness of the change. Rather, it only proved a limited subset of conditions were error-free.

Effectively, tests are loaded with false negatives, so trusting them to identify problems should be done with a massive grain of salt.

If the developer had simply copy/pasted the code he changed and compared the two, then it's exceedingly more likely that he would have noticed that his code didn't capture the full breadth of conditions in the previous code.

A bug existed in the test suite, to start, and then a bug was introduced into the codebase. A human being looking at the two lines of code as it was rewritten probably would have noticed the regression. But even a code review missed it because it was a fundamentally small change among the other, more "make sure this looks good" code.

Personally, I very much value copy/paste/compare changes and never treat the test suite for anything other than "well we haven't broken anything in any exceedingly obvious ways." Maybe you're a superhuman programmer, but I'd lean more towards "you've probably added more bugs than you realize".

There’s def. ways to write really good tests as well to avoid the limited input issue - write the test in a property-based test manner, like haskell’s quickcheck, and the test can catch entire classes of bugs.

The caps vs. no caps issue would be easily caught using randomString() as the test case.

YES! TDD has saved me from this, listen to our friend fung. I put off learning about it for so long out of laziness but the payoff is huge.

Yeah, sure it happens. Then I type “git diff”. But never have I unraveled the entire undo buffer stack only to peek at it and re-push the entire contents. That’s super weird to me.

What’s weird about it? For some - to do git diff might take more keystrokes than hitting undo 5 times.

I do all of these. I’d use undo/redo when I want to look at something I /just/ did, meaning while in the process of writing something. The git gutter when I stumble upon some change I want to see what was there before. Or Sourcetree for a full diff.

you cant do it on a first go. i write a draft of what has to happen. often i draw drafts of the solution on a4 sheets of paper(my own blackboard, the best tool i know to make software). i do research and update the drafts to a point where i type in the code. code is the last thing i do. i laught that i make coloring books and not coding :) i am quite fast and i have little problems with switching contexts. the code is much better as i "see" the whole solution. i have much better abstractions. in a recent task i have found with this way of coding, many places with bad code and made them better as they didnt fit the cleanliness of the soulution. they just stand out like the eifel tower in paris.

If there’s a specific implementation that’s especially hairy, I’ll just copy that block and comment it out before continuing. Instant reference. And if I’m rewriting more than 10 or so lines at a time of complex business logic, something is wrong.

But also, `git diff`.