4 ms·

My development enviroment has this, 's called git diff and git log?

• acangiano 17y ago
  Not quite the same thing.
  • thwarted 17y ago
    UI difference. That and when browsing code history, the focus is on commits rather than the order in which the keys were hit. When I'm checking code history, what was typed in between commits would be useless information 99% of the time.
    • DanielStraight 17y ago
      Much more than UI difference. It's seamless and automatic. That's what makes it different. You CAN do this in any environment, but you might not. I've quite often done some work, decided I didn't like the way I did it, gone back and done something else (never committing the first method), then decided I wanted to original way back. No one has time to commit EVERYTHING they may want to undo. Also, browsing through history in a version control system takes much longer than dragging a slider.
      • aaronblohowiak 17y ago
        "No one has time to commit EVERYTHING they may want to undo." - why not? Committing locally takes ~0.25 seconds ( bash script called from command line in vim makes it painless.) then when you're ready for your real commit, you just rebase -i to squash the in-between ones, and then push. as for the slider.. eh.
        • catch23 17y ago
          Yeah, but not everyone wants to have their commit logs full "testing sample code 2" etc. Maybe you're profiling and you're trying out different pieces of code to see which ones might be faster -- happens all the time in javascript because browser implementations of javascript aren't identical. I don't do these intermediate commits otherwise my log would be a pain to read and 95% of the commit messages would be me testing out random code samples. Another useful case for it is when you're just putting in a bunch of debugging statements that you don't want to be committed later. I find myself doing undo/redo all the time for doing stuff like this. I think a more advanced undo/redo would definitely help out.
          • aaronblohowiak 17y ago
            >not everyone wants to have their commit logs full "testing sample code 2" etc That's why you squash the commits when you are done with the profiling. Squashing the commits makes it seem like just one commit (and one commit message) in the log. This way your log is clean, but you get the advantage of frequent saves. If you dont want to do this, you could probably hook up something with FUSE
  • Pistos2 17y ago
    I commit to version control very often. Further, with version control, you annotate the commits with meaningful messages, and you (presumably) commit at meaningful points in time. For example, you (usually) wouldn't commit in the middle of developing something (when it's obviously broken, even syntactically). Snapshooting at arbitrary points in time would not enjoy these benefits of intentional version control commission.
    • acangiano 17y ago
      I'm obviously not arguing in favour of replacing git, hg or svn with this. It would be a fun, additional feature to have. You could then watch how the code evolved over time, easily move step-by-step, hand it over to a less experienced developer to teach him how to refactor code, and so on. I would find it useful.
    • akkartik 17y ago
      That mirrors how I hack. I like to think in terms of the changelog message, what I want to say about the current snapshot, front and center. The fact that the snapshot is saved at that point is almost implicit. http://akkartik.name/codelog.html http://akkartik.name/codelog.html (from 2005; now I use git instead of darcs)
• iamwil 17y ago
  Sure, developers have this sort of power. Lay people don't. Their target audience is more than just devs.
  • apotheon 17y ago
    Editor integrated version control is what this is talking about, though.