so previously I created a small tool that creates commits on every file change and though it was very fun in the beginning it turned out to be a trouble to remember what I actually did so now I downgraded it to just "create a new feature branch if I make some changed on main branch and stage everything" https://github.com/uprun/git-auto-commit

Comments? I often do exploratory programming and end up thinking "this worked just a 1/2 hour ago, maybe I should revert to that?" (Or "...just yesterday..."). I am learning to hate off-the-shelf git. I have always thought - but haven't done anything about - that I want an auto-git that saves every change and lets me rewind. Is this the kind of thing that you found to be too much trouble?

@guitarvydas I pointed out previously my idea of creating a commit at the point of a comment to self. I still like this approach a lot even though I stopped using it at some point as I grew more fluent with git. I suppose it depends on what the goal is. In that previous thread the goal seemed to be to see a very fine-grained history. @Oleksandr Kryvonos I don't follow what you mean here by "it turned out to be a lot of trouble to remember what I actually did". Doesn't the commit history show you exactly what you did? Is it just too noisy? It seems to me the current approach of staging things drops the fine-grained history entirely. So maybe I was misconstruing your goal above. I'm curious to hear more. On a tangent, I was reading about magit yesterday. I wonder how much of a difference using it would make to the experience of git.

@Kartik Agaram previous goal indeed was to have a fine-grained history, but it was noisy

Has the goal shifted now? What is it now?

The way that I read this, it sounds like you have to stop and make a comment to self, pulling yourself out of "The Zone" (aka "Flow state"). Did I understand this correctly? If so, I want to aim for tools that don't interrupt my train of thought. An aspect of "exploratory" programming is that it is not methodical, you can't plan ahead nor push buttons after/before-the-fact, you need to keep motoring forward without needing to notice your tools.

@guitarvydas yes it is correct - now I will need to get out of the flow "The Zone" and write the comment myself.

I'm definitely interested to hear more as you figure out what you want for yourself. Have you looked at

jj

? It has an interesting-looking flow where every edit is automatically part of an automatically updating commit -- until you decide to draw a line and create a new one. I haven't worked much with it myself, but in principle it seems like a promising best of both worlds: save from the start, but you aren't forced to prematurely attach a name to what you're doing.

@Oleksandr Kryvonos I conclude that "staying in The Zone" is vital during design and exploration. Most programming languages and IDEs don't emphasize this aspect and tend towards a "waterfall" model of development, i.e. you need to predict where you're going instead of simply discovering it. This sounds loosey-goosey, but is critical to actual design work. It might be a big factor in why some people love early languages like Lisp, Smalltalk, Forth, etc.

@Kartik Agaram thanks for the suggestion, I try to use Unix philosophy of "one condenced and understandable tool for one job". Next I want to create a pattern matching natural language agent similar to ELIZA ( https://github.com/norvig/paip-lisp/blob/main/docs/chapter5.md )

@Oleksandr Kryvonos are you aware of Prolog, miniKanren, Nova, Ceptre, etc., for pattern-matching? That stuff was shunned in 1950 because backtracking was considered too taxing on the hardware. Today, backtracking is cheap and cuts through problems like Eliza like a hot knife through butter. [I conjecture that LLMs are just massively parallel pattern-matching devices].

@guitarvydas yes I am aware of Prolog, the other names are new for me

@Oleksandr Kryvonos I am compiling a list of URLs plus explanations. But, I forgot to ask: what is your goal in creating an Eliza?

@guitarvydas I do not really believe into LLMs so I will create something simple and explainable.

FYI, this article contains many of the references about pattern matching that I mentioned. See the "References" section.

Thanks a lot, I will look your article