Comment by hn_throwaway_99
6 years ago
Wait, is that something you would want? I would find it pretty awful if my git history for my code had all the other things like issues and PR metadata in it. Could potentially see it being useful if it were stored in an "auxiliary" repo that I could pull separately.
The big advantage would be that all that metadata would also be decentralised, i.e. I'd have a backup of all that on my own PC, and I could push it to a different host to automatically transfer everything, whereas e.g. GitLab has had to write custom import scripts for GitHub metadata, and you just have to hope that everything maps cleanly if you use it.
Of course I want it. History is history. Furthermore, why should PRs, bug reports, and build artifacts not be able to refer directly to source objects and revisions, and vice versa?
A simple way to represent it might be as an ASCII dump of one or more databases representing it all, so you could roll back to any day's state; or as an update-log transcript, so you could roll back to the state after any given transaction. Both amount to successive diffs, so are reasonably compact.
> History is history
Except PRs, bug reports etc. can't affect the runtime behavior of your program, only code can. There are many times when I am looking through a dependency's history to see "what changed?" in order to decide if I want to pull a new version, and the ONLY thing I want to look at in that case are code changes.
> Furthermore, why should PRs, bug reports, and build artifacts not be able to refer directly to source objects and revisions, and vice versa?
I do that all the time in GitHub today.
I certainly understand wanting that auxiliary data to be versioned, and I also understand wanting it to be in a portable, distributed format like Git. I just definitely don't want it cluttering up the history of my code
Also, security is a big deal. I often want to allow pretty much anyone to open a PR or an issue, but I don't necessarily want that now to be part of the repo every time someone clones it.
> Except PRs, bug reports etc. can't affect the runtime behavior of your program, only code can
Are your repos free of docs, READMEs and tests, then?
> I just definitely don't want it cluttering up the history of my code
Separate branch?
> I often want to allow pretty much anyone to open a PR or an issue, but I don't necessarily want that now to be part of the repo every time someone clones it.
That is a good point; perhaps solvable by having the webapp frontend provide the GUI but make commits itself? That should give you the best of both worlds.
Fossil keeps them in the same repo but as a separate kind of object.