Totally understand the dislike for subscriptions. I did go that way because it makes it much likelier I'll be able to work on the app long-term (which I'd really like!).

Retcon's actually already available on Homebrew—someone kindly added it, unprompted!

I understand your reasoning

If there's a conflict, Retcon shows that to you, but you can keep freely moving commits around—it's not blocking. Once you're happy with how your history looks like, you can start actually resolving any remaining conflicts, and after that the history gets actually written.

Sometimes, just moving things around further is enough to resolve the conflicts, too, if they're simple enough!

Thank you!

It's a regular video recording, and then I noted down the chapter timestamps in an array. (see heroVideoChapterStartTimesSeconds at the very top of https://retcon.app/main.js) As the video is playing, the player uses this to know what chapter to highlight, and how much to fill its progress bar. (that's updateVideoChapters())

I'm actually working on adding this to Retcon right now! It's one of the biggest feature requests.

So far the implementation goes like this: you enter Edit mode on a commit; you unstage some lines; and you confirm. The lines are yanked from the commit, and added to a new commit that you just have to title. I just use it on the Retcon repo and it's real cool to have.

(Retcon dev here)

lazygit is really cool, and is a lot more full-featured than Retcon. But, the core "rewrite with zero friction" feature of Retcon is still unmatched, I think.

For instance: while lazygit does allow you to reorder commits without entering a separate mode, that's only if each move is conflict free. If you have two commits that need to both be moved at once, then in lazygit, you'll have to resort to a regular interactive rebase (so, with the separate planning and execution steps, no undo or preview along the way, etc).

In Retcon, if a commit move results in a conflict, that doesn't matter; you can keep making changes to your history anyway, and then resolve any remaining conflicts when you're ready. It makes the workflow super fluid.

There's probably still a ton Retcon could learn from lazygit/magit/jj, though!

> In Retcon, if a commit move results in a conflict, that doesn't matter; you can keep making changes to your history anyway, and then resolve any remaining conflicts when you're ready.

I didn't realize Retcon could do this from the website, nice!

I wonder how similar your approach is to [jj's approach to conflicts]; whether you reinvented the same way of modelling conflicts in the repo or use a different one. (See also the link to the technical docs from that page)

https://gitbutler.com/ also [borrowed this idea] from jj.

[jj's approach to conflicts]: https://martinvonz.github.io/jj/latest/conflicts/

[borrowed this idea]: https://blog.gitbutler.com/fearless-rebasing/

So, there are several tools exploring these ideas, but there are interesting differences in (for example) how close to Git each of these approaches stays.

Thanks for the link; jj's approach seems really solid.

Retcon is pretty different: during a rebase, the state of everything is only stored in RAM, not serialized to the repo. So while you can postpone resolving conflicts until you're done putting commits in place, you do have to do so before you go do something else in your repo.

The RAM representation is basically a list of commits (well, commit-likes), what I call a virtual history. It's the history you want to get to, but that's not currently representable with a regular, physical Git history.

Hmm, could you explain your exports idea further? I don't think I'm getting it.

The different extensions are a good idea; my current recommendation is to use .lem.js (for compatibility with editors), so that could be changed to .lem.ts easily!

I'd love to have proper TypeScript support at some point, too.

Well looking at the left (Tasklemon) and right (Node.js) in the example, I'm wondering what it take to make them be the same thing. Off the top of my head something like:

#!/usr/local/bin/tasklemon stdlib

  home.children().forEach(child => {
    if (child.extension === 'tmp') child.delete();
  });

where 'stdlib' in a tasklemon config dir has the preamble:

  const fs = require('fs');
  const os = require('os');
  const path = require('path');
  
  const home = {
    children: function() {
      const homeDir = os.homedir();
      fs.readdirSync(homeDir).map((file) => {
        return {
          extension: path.parse(file).ext,
          delete: function() {
            const absPath = path.join(homeDir, file);
            fs.unlinkSync(absPath);
          },
        };
      });
    },
  };

So basically each 'feature' of Tasklemon is just a nice DSL for js/ts.

And for handing async callbacks, run the contents of the script in an async function so you can await values anywhere rather than have to pass in callbacks.

I'm not sure what your point is; of course, you can write JS on top of Node that exposes its functionality with a nice API: that's exactly what Tasklemon is!

Did the intro maybe give you the impression that TL was built standalone, instead of on Node?