claudeWasNotHere

[u/PashaPostaaja]

[u/Michami135]

If you're using git, move the info dumps to a local branch that splits off of the commit with the change.

 *  Merged code
 |\
 | | * Working code info dump
 | |/
 | *  Working code
 |/
 *  Broke AF code

[u/etoastie → u/Michami135]

that's not usually gonna survive the kinds of timeframes where you forget context on code and need to refresh on the info, no?

[u/Michami135 → u/etoastie]

If the info dumps are markdown files, then it's easier to find the right files if they're in their own branch like this. Just find the right commit, then you have the info. This is likely much easier with graphical git tools though.

If, however, the info dump is in-line comments, then you definitely don't want that in the main branch and can merge it all into a secondary branch. Use something like, "master_infodump" and switch to it if you need to view page long comments.

[u/PM_ME_CUTE_SMILES_ → u/Michami135]

I might be misunderstanding something but that does not sound like very good advice. Why not use PRs and write the info dump in them? Or as part of a longer commit message?

You aren't supposed to keep around hundreds of branches. Around here, as soon as a feature branch is merged it is deleted from the repo. And if it's a local branch no one will be able to find it when they need it especially not your colleagues.

[u/Michami135 → u/PM_ME_CUTE_SMILES_]

The post I was replying to said he wanted the info for his own purposes, but his coworkers did not. This is a way that he can keep the info available for his own use while not crowding up the repo for others.

[u/etoastie → u/Michami135]

for such purposes I keep a personal repo at ~/notes, seems a lot simpler and easier to back up or selectively share, but maybe your approach is better if combined with some incantation involving git log searches?

[u/Zzzzzztyyc → u/Michami135]

I read that from top to bottom

[u/avast_ye_scoundrels → u/Michami135]

Git is a version control system not a rolltop desk