i would be using fossil for source version control if more stuff supported it

having bug reports and wiki pages with the code standard and not some adhoc code workflow is really cool actually, but i extremely don’t have spare bandwidth to make the things that expect git work with it… and it’s kinda pervasive

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

@Lady@glitch.cat.family oh? i'm curious... how would you want to? (and not just because that always leads to good convo and i like you, but that is a large part of it)

@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?

@Lady@glitch.cat.family i would say that it's perhaps important to remember even your bad ideas and dead ends so as not to repeat them, but i would be a hypocrite because part of me sees those things as clutter that distracts from doing better.

that is a good point you bring up. i have used rebase in the past just to make sure that the history i push matches what i intended even if i fell short of those intentions...

i do think it would be good to push some of the functions of a "git forge" into the repo itself (like the aforementioned bug reports and wiki pages) in a platform-independent way, but it needs to be an agreed-upon standard and i dont see that happening so long as things like gitea and forgejo are "good enough".

and thus, the right thing is once again sacrificed upon the altar of good enough... or that's how it feels anyway. i don't really know what the "right thing" is anymore, to be perfectly honest... just my idea of what it should be.

@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 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 guess branches probably make more sense than tags here but refs regardless)