Lady in Love @Lady@cat.family

@aescling @wallhackio @Satsuma @alyssa no, short of just dropping the article

@wallhackio @Satsuma @aescling @alyssa sats lmao

@Satsuma @aescling @alyssa @wallhackio “i can imagine clodsire saying this to his cat”

@aescling @Satsuma @alyssa

@Satsuma @alyssa @aescling tbh i would probably only bother gendering real cats like half the time but it's a problem in this situation

@aescling @Satsuma @alyssa protip: don’t buy a house it is constant doing things you don’t feel like doing

@aescling @Satsuma @alyssa you’re really bad at doing things you don’t feel like doing huh

@kit re: preserving your bad ideas: i think it is important to remember bad ideas but there is no reason to preserve bad code. what use is there for reading code which is a bad idea and doesn't work? are you ever realistically going to do that? or can you just make a note of it and move on

@kit this is another case where i want history rewriting tho. it really bugs me when i click the wrong tag in gitlab and then me adding and removing that tag is preserved forever in the issue history. it was a silly mistake and preserving it helps nobody. let me drop it from the record

@kit (i guess branches probably make more sense than tags here but refs regardless)

@kit there isn't any reason why you can't do issues as tags pointing to trees of empty commits whose messages give the issue history. then you just need a way of indicating issue status (open/closed/etc) which can be done with commit trailers. this would probably be good enough for most usecases and not that hard to build a user interface for. but it's all ultimately local project convention

@kit i mean i think this is the good and bad of the linux philosophy; there is no perfect way of doing issue tracking or project documentation, so git can’t mandate an approach to doing issue tracking or project documentation, so everyone does it differently. but specific forges can make those decisions for themselves, even though they may not be great for all usecases

@kit fossil is very concerned with creating an immutable record of code changes, or an accurate depiction of code history, or not “throwing away” data

it takes issue with git rebase, for example, calling it “dishonest” and saying it “omits historical information” https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

any archivist knows that what you throw away is as important as what you keep. i want full control over the authorship of the code history so that i can publish it as intentional statement, including and up to throwing out and rewriting large parts of it to make more narrative sense. is this “dishonest”? only if your interpretation of the repository is as a factual and immutable ledger of code changes, and not a narrative explanation for how code, in its current form, more or less, came to be. i think the second is the more powerful and useful interpretation, personally

broken code, bad ideas, and dead ends are definitely data, but are they useful data? why is the expectation that repositories preserve these things?

@kit fossil is interesting but unfortunately approaches code repositories in the exact opposite way from how i would want to

@wallhackio i was looking thru photos.app