Frequently. Just this evening I was looking in the HN repository for the last version of the code that pg wrote, to remind myself how he used to do something.
One of my favorite tricks is to make a file out of all the changes in the history:
git log -p > bigass
and then grep through the file (edit: which I like to do in Emacs—hence the file) to see every appearance of some construct. There's a lot of knowledge in there. It's particularly useful when you remember that you did something, but forget how you did it.
In fact, I use git proactively this way, to store things in the version history that I might want to remember later. 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). The codebase remains unchanged, but what I just did is now there forever for future me to recover.
Such an approach only works if your system is small, but I like to work on small systems and prevent them from becoming large systems. There's a beneficial feedback loop here: as you get comfortable working with history, it gives you more confidence to delete things, helping to keep the system small.
I've also found this technique useful for solving the chronic problem with documentation: that it inevitably fails to get updated. When I write something about the code, I commit it and, as above, immediately revert the commit. Now it's permanently glued to the state of the code when I wrote it. When I read it in the future, I can do so alongside a diff of the code from then to now. This makes it easy to see what has changed in the meantime, in which case I can update the document and commit/revert it again.
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 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 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
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.
> 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.
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.
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.
One of my favorite tricks is to make a file out of all the changes in the history:
and then grep through the file (edit: which I like to do in Emacs—hence the file) to see every appearance of some construct. There's a lot of knowledge in there. It's particularly useful when you remember that you did something, but forget how you did it.In fact, I use git proactively this way, to store things in the version history that I might want to remember later. 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). The codebase remains unchanged, but what I just did is now there forever for future me to recover.
Such an approach only works if your system is small, but I like to work on small systems and prevent them from becoming large systems. There's a beneficial feedback loop here: as you get comfortable working with history, it gives you more confidence to delete things, helping to keep the system small.
I've also found this technique useful for solving the chronic problem with documentation: that it inevitably fails to get updated. When I write something about the code, I commit it and, as above, immediately revert the commit. Now it's permanently glued to the state of the code when I wrote it. When I read it in the future, I can do so alongside a diff of the code from then to now. This makes it easy to see what has changed in the meantime, in which case I can update the document and commit/revert it again.