I am back with small project (work in progress al...
# devlog-together
o
I am back with small project (work in progress already finalized), Have you ever thought that git diff does not really show the history of changes you made and just shows the final state, this can be solved with more granual commits, so my project - https://github.com/uprun/git-auto-commit - creates commits when file changes, in such way changes will be sent real-time and the transformation history is saved as well.
k
I did this many years ago.
i
These are interesting projects! Having more history to explore (eg: commit on save, or even commit on keystroke) feels likely to offer a bunch of benefits… if we can crack the UI challenges it brings. I like how you handle this, Kartik, by focusing on the "when I have something to say" communication part of creating a commit. Like, with git, I usually think of the snapshot of the codebase as the thing I'm capturing, and the commit message is just a summary of what's changed since the last snapshot. But by making it log-first, it's the train of thought that's being captured, and the snapshot of the code is just the context needed for each thought. I love this inversion. Oleksandr — how do commit messages work in your project? Any thoughts on what you might do there? For Patchwork, @Geoffrey Litt and @Paul Sonnentag did some interesting things that are relevant here. For one, they did a commit-per-keystroke, but then used some smart heuristics to batch together these changes into meaningful units of work. Another great thing they found is that using AI generated commit messages is pretty good, actually. Though I think I like Kartik's approach even more.
k
I don't quite follow "transformation history," @Oleksandr Kryvonos
o
> Oleksandr — how do commit messages work in your project? Any thoughts on what you might do there? @Ivan Reese I put just time-stamp there, but I have another approach: 1. I always start develpment from "main" branch into a feature branch 2. inside feature branch commits do not have any meaningful text except for the time of change; 3. when I merge back the feature branch I summarize what changes I made
I don't quite follow "transformation history," @Oleksandr Kryvonos
@Kartik Agaram I will explain - in my workflow what I do with code usuallly is: 1. I extract block of code into a function 2. I replace piece of expression with a meaningful variable name (similar to step 1) 3. I add condition around block of code 4. I write a function from scratch 5. I copy and paste existing function and modify it for the new case. After each of these steps I often save the file to check whether it still works. This is what I call transormation history. List of actions above is not finalized of course.
and now I finalized the project, seems like it already covers all the cases I wanted and I only spent 3 days on it. I will use it now in all of my personal projects. I shall see what is missing.