This is good. I'm stealing it. It's using git as sort of a super-brain, helping you remember stuff you wouldn't otherwise. It's how I use gmail. Instead of shooting for inbox zero, I just leave anything in there that I might want to remember later and delete the rest. Then, many times years later, I can search through looking for important correspondence. Both of these stories are good examples of how simple but flexible tools can be used perhaps in ways not anticipated by their creators or the majority of their users.

I use gmail the same way. I do feel that the search functionality could be improved though which I find ironic.

I use gmail that way too! Never made the connection to the git thing though.

Gmail search used to be the best. Now it fails to find anything useful most of the time

Inbox zero isn’t deleting everything, it’s archiving those that are done so they aren’t in your immediate inbox.

What you’re doing sounds compatible with that.

> git log -p > bigass

> and then grep through the file (edit: which I like to do in Emacs—hence the file)

Since you already have Emacs, I would suggest you do M-& git log -p RET instead. No need to round-trip the data through a file.

I had a feeling someone would come up with a suggestion like this! Cunningham's Law and all that. Posting wrong or insufficient things on the internet is a great learning strategy.

However, I get:

  WARNING: terminal is not fully functional
  -  (press RETURN)

and on pressing return, I only get enough data to fill the buffer.

I always set PAGER=cat in Emacs. If you're running a VT100 emulator in Emacs this may be bad, otherwise it avoids the problem your describe.

I find the temporarily localized documentation idea quite interesting – anyone else here tried that?

> Such an approach only works if your system is small,

I see no reason why this wouldn't scale if you (and other people working on the same codebase) just maintain individual branches (say "dang-braindump"). Just do exploratory/documentation work on that and cherry-pick, rebase -i or git merge --ff --squash --no-commit to skip the reverts.

> I find the temporarily localized documentation idea quite interesting – anyone else here tried that?

I've done this a bit.

For several of my $DAYJOB projects I maintain documentation as Markdown files in the project, which get rendered into a website at build time. The project changelog is kept in version control the same way (https://keepachangelog.com).

Several times I've tried an experiment or alternate approach that didn't work out and done exactly this, complete with documentation, so the state is preserved. It's easy to document a prototype if it just means throwing a few paragraphs into a text file with the prototype.

Add a note in the changelog about adding the prototype then commit.

Make the revert commit and add a note in the changelog that you've removed the prototype.

Keeping a good, human-readable changelog as described above makes this strategy more scalable. You can document failed experiments you backed out, features that have been removed, and the like, in a few quick summary lines, keeping devs aware of them across the project's lifespan.

New devs can review it for the big-picture history and use the changelog's revision history to see what commits they need to see for the details.

Using a changelog this way also makes it reasonably possible to delete code but still remember it existed years later, something that's otherwise a surprisingly hard problem (especially if the project has high turnover).

Thanks for sharing! I'm not a big fan of changelogs, personally, except for publicly released projects. I prefer to have workflows that use version control for this. Reverting on master, but tracking the prototype in the changelog is a nice hack, but has a cost in terms of clutter, ability to bisect etc. I think I would prefer something branch based, but I haven't yet properly thought about the best way of doing it. If you have a special prototype branch from which you merge in master and do your prototyping, reverting and optionally notes.md there, you might effectively be able to replace the changelog based flow with just doing git log --no-merges --first-parent. What do you think?

I think as the number of branches grows, people will just start to drown in the huge list of unmerged branches and will start to work as if only trunk/master exists.

With a text file that summarizes all the project's main line of history in a structured, linear way, it's very simple to extract just what you're interested in or find all the entries for a particular thread of research across history, quickly.

I don't think the tooling around git branches really enables that kind of operation in a quick, easy way, partly due to the inherent nature of branches.

I'd be interested to see what your hypothetical workflow turns out like in practice, though. It's certainly possible I'm just not seeing the potential.

I’m stealing this too! I often try to persist exploratory history as separate remote branches, but for some reason a lot of the devs I’ve worked with are very adamant about deleting any and all “unneeded” branches, and I end up appending such branch names with a “-dont-delete”, but that starts to get abit passive aggressive. Now I can just do this and nobody needs to know

Or at least by the time they know, it will be too late :)

There are some disadvantages. It can mess with git bisect, for example.

What's the advantage of doing this over just making an experiment branch? A branch would be easier to find than a reverted commit somewhere in the mainline branch.

For me I end having a bunch of “exper-xyz” (experimental) branches that are often small changes that I may never merge into master. The problem is I loose context of that branch, so I kind of like the idea of the reverted commits, will need to try it, for small changes at least.

Then I'd have too many branches and no longer a single place to search.

> For example, if I write exploratory code to test out a feature or throwaway code to do some analysis—anything I might want to use again, but don't want to commit to the codebase—I'll add it as a commit and then immediately revert the commit (i.e. make a new commit that deletes what I just added).

Why not use a named stash for something like this? It'll keep your history cleaner, and you can always find the stash by name later.

Too complicated for me. I didn't even know that named stashes were a thing, and I wouldn't remember the names.

The nice thing about the approach is that there's only one place to look. I don't think it makes the history less clean, since it only contains things that were at some point, if only briefly, in the system.

Can stashes be pushed to a remote repo?

Along these lines: git-log has a --grep option which returns only commit messages that match a regex, and git-grep searches over revision controlled files like above.

>I like to work on small systems and prevent them from becoming large systems.

This is very wise!

Similarly, ‘git log -S needle’ will surface all commits with ‘needle’ in the diff.

Yeah, the grep option is on the log messages. Use -G if you want the regex in the diff.

You can pipe through `less` and then search using `/`, no need to redirect into a file (and this way you don't have to wait for the history to be done dumping before you start your search, which can be a pain for very huge repos).

I do that when I know just what I'm searching for, but for this sort of meandering around, I prefer to explore a file in Emacs. I can quickly get a list of everything that matches a certain regex and hop between the locations etc. It's much easier and faster (for me—a lot of this is just whatever one's used to). You're right that for a much larger repo, waiting for a file to dump, not to mention Emacs to open it, would make this impratical.

can anyone truly ever gitlog bigass?