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