Such a tool would be a great starting point for a commit message, but I’d probably want to edit it a bit. That said, if I had such a tool I think I would (likely) be able to completely automate versioning my libraries. It could use conventional commits and trigger calculating the next version using semantic versioning.
For a small project, git’s difftool already can help a little. For me, I usually use kdiff3 as default, and reach out to meld when suitable. Strip the .txt
to have the same toy project attached below at hand.
-
in the simple diff of a specific file, I just call
git difftool
with the two (short versions) of the commit hashes and the name of the file in question. In the toy project, there isn’t an other (visible) file in the folder currently accessed, andgit difftool 75c944d 52a75a6
was specific enough. Defaultkdiff3
then displays the two commits side by side, scrolling up/down in one pane simultaneously does the same in the second pane, too. -
One can overwrite/explicitly define the default difftool GUI with the flag
-t
(or--tool
) plus the name of tool to use. Here, I opt formeld
instead ofkdiff3
. The blobs indicate the appearance / disappearance of the line which, comparing the commits in question, was moved.While
kdiff3
displays it only (i.e., without the joining lines) with newly populated/empty lines (vimdiff like): -
Case 3: The diff can extended to compare a directory, indicated by the flag
-d
. Again opting for meld here:The symbol would be a different one if a file was edited, or (by
git rm filename
) no longer be monitored by git.
I agree, this approach doesn’t provide a report (yet) the way (I assume) you would like to have. But instead of reporting the lines changed between two two commits git diff
equally can be modified. E.g.,
$ git diff --name-only c77705b c9f8e21
file2.txt
indicates changes happened only to file2.txt
. Among the many commands (and modifiers) git
provides, only the ones one uses often enough are the ones retained physically, or mentally.
2024-01-20_test_case.zip.txt (27.6 KB)
I migrated to Emacs in the early 2000s to help with programming Common Lisp. I was also looking for a plain-text system for managing my notes (InfoCentral → InfoSelect → MS Word → I’m-not-going-to-migrate-one-more-time), so I adopted Emacs org-mode. It gives me reasonable markup, and I even use it to export to LaTeX for good looking PDF.
I’ve used both the deft and org-roam to manage my set of notes (about 2,500 in a Zettelkasten; about 13,000 .org
files elsewhere). Mostly I rely on org-roam
, which gives me capabilities similar to Roam and Obsidian.
I use a private GitHub repo to save these notes and for (largely unused) version control. The Emacs magit
interface to Git makes things very easy to manage.
I’m curious, what notes is everybody taking? That requires so much organization? I have a paper and pen journal I use for writing scratch notes and keeping a short to-do list, but other than that, the emails stored in Outlook tend to keep anything else I need. Perhaps it’s because I’m not really in academia anymore, but I’m really struggling to figure out what everybody is preserving.
I wish I could get away with such a simple system! For me, I work on tonnes of projects at any given time and it often means swapping between different strands of work. Sometimes it can be months before I get chance to focus on a project again, and my memory isn’t good enough to remember everything that I’d already researched, discussed or implemented. Pen and paper gets me so far, but it needs to be text-searchable to save wasting me time. A few common use of e-notes for me:
- Trying to remember some key bit of info someone said about something during a meeting at some point in the past year - I need to keyword search those terms in my meeting notes.
- Writing notes on papers or research I’ve done and storing them in a catalogued manner, so I can quickly search for e.g. the author’s name and get the notes I’ve already written on the subject.
- Writing wiki-type notes on a subject, i.e. being able to link to other notes that I’ve already written. I often write a “cheatsheet” on a subject that is basically an annotated index, with links, of all the other notes I’ve written on it.
- Similarly for project management, I like having a project page that links to all the notes, meetings, tasks and papers that are relevant to that project.
Maybe this is all just a reflection that I’ve got rubbish memory
I tend to keep short notes. When I was working as a manager, every 1-on-1 session with an employee had a separate note file. Same with meetings. These pile up fast, but it made it easy to grep for a topic and see when it came up.
I have a .org
file for all people I need to keep notes on. (Goes back to at least the 1990s. I can tell you about almost anyone I ever interviewed…)
As I work on the myriad Fortran-related projects I’m toying with (each subproject is its own .org
file), I take small notes on progress (in journal entries), and lots of notes on papers and books I’ve been reading or meaning to read.
Even when reading for pleasure, I create a .org
note file on each book. It helps me remember what I’ve read, so I don’t try to read it again.
I started taking these kinds of notes 30 years ago; they kind of pile up.
And those who know me well know that I am something of an OCD digital pack-rat, in any regards. It’s a bug, not a feature.
I am using Zim for my notes for ten years. As it is just wiki .txt
files, I guess it would be relatively easy to synchronize it with GitHub or GitLab with a small script that could be launched with a personalized icon.
Well, I don’t do it because I am deadly old fashioned and don’t like the idea of putting my notes in the Cloud, even in a private encrypted repository, with point to point encryption, etc. I use it not only for computing/professional notes but also personal notes. I have practiced computers for more than 12 years without any network, so localhost
does not sound like prehistory for me… It rather sounds like
private life
(yes, it did exist, once upon a time…).
I will take a look on zim.
Note that it does not use Markdown but its own wiki syntax. But it does not really matter as you will generally not use that syntax directly but work in the GUI. But if you synchronize these files in a repository, and want to work online, you would of course have to use that (basic) syntax.
It is a Python program available for Windows, macOS, Linux (generally in the package manager of major distributions) and FreeBSD.
One thing I appreciate is that it does not compel you to use a specific method, like for example Getting Things Done, for managing your notes and TODO lists. It is just a general tool.
I have just some problems to print since Ubuntu have put Firefox in the Snap system… (for printing, Zim generates a HTML page and launch your navigator, but with Snap there is now a filepath problem…) The workaround is to go in the
\tmp
directory and open manually the file. See Print to browser doesn't work on Firefox snap package · Issue #2025 · zim-desktop-wiki/zim-desktop-wiki · GitHub
Thank you for the detailed answer. Perhaps I just don’t have enough going on to require lots of notes! I don’t manage projects, I’m not a manager, I don’t do very much research anymore.
About meeting notes - Do you takes notes in the meeting? I’ve tried doing that, but I find I can’t pay attention if I’m writing stuff down (had the same problem with lectures in college). Do you takes notes after the meeting? Currently, I really only write down stuff that I have to do from the meeting.
That’s amazing you have all that information! Perhaps I need to think more about writing stuff down instead of just letting it “flow” through me. It might help stuff stick more. If I ever become a manager, I’ll keep this in mind. I like the idea that my manager cared enough to record our interaction so he wouldn’t forget.
Generally I jot stuff down with pen and paper during a meeting, then type them up properly later. I used to type them up during the meeting but find going over them again afterwards is a useful strategy for consolidating the content of the meeting. I used to work as a notetaker and so got plenty of practice scribing whilst (trying to) listen - it’s difficult. Makes you really appreciate those presenters that labour and dwell on points!
I like like the principle of Zim, but it’s too bad that it doesn’t support markdown at all, which is now a de facto standard. Viewing/editing the notes on Github (or any other markdown editor) with proper formatting would be nice…
Markdown support has apparently been a constant request for years from the users. Support markdown and display files with .md extension in the index · Issue #26 · zim-desktop-wiki/zim-desktop-wiki · GitHub
I have found zttlr, which is similar to Zim in terms of philosophy, but fully markdown based (probably a bit less versatile, though). Unfortunately it won’t run on macOS 10.13 because of a long standing and won’t-fix bug, which happens to be my main OS (but that’s another issue).
A long time ago, I played around with VimWiki: https://vimwiki.github.io/. So if you are a big Vim user, this might be useful.
I usually do this, too. I make mind maps with pen and paper, and will transcribe those (or just scan the page). Pen and paper make it easier to pay attention, take detailed notes, and not have the laptop be a distraction or physical barrier when I’m meeting with people.
After learning the basics of git, you’ll find that using the commandline becomes inefficient for complex things.
I will recommend tools that can help you do things quickly.
I use, lazygit, and gitcola.
lazygit is my preferred tool, as it works in the terminal, and has vim bindings: GitHub - jesseduffield/lazygit: simple terminal UI for git commands
gitcola is simpler to use: https://git-cola.github.io/