-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Source History #47
Comments
And for anyone investigating my clone, the number of branches there now might be confusing. A |
There was no intention to loose any history. The import should have maintained all attribution for all commits that could be determined. So if this was missing from the original SVN version then yes it would have been missed here too. I'd be happy add appropriate attributes if this can be done easily without causing issues for others tracking this. |
Thanks for your reply. And I see. Sadly attribution is something git doesn't manage through repository-wide attributes or metadata, and which can't be amended without rewriting history. Git is dumb like that (it's called the 'stupid content tracker'). Since svn stores nothing but a username in the commit, but git tools identify user Identities by email, the git-svn importer, without more info, can only convert them to something like
Git itself does not care about valid e-mails, but tools which care about the email, like git email patch, or github for attribution, have nothing to go on here. So unless you know who this person was (which we do ;), you also can't possibly contact them in future, e.g. about copyright or license changes (as I did for another project). One example case where history was lost in this conversion, is this: You'll notice the first is empty, because the content related to a path which was outside the imported subdirectory in the git conversion here. The same is true for all other commits which touched the Again no simple fix is possible. The options are limited to doing something now, before yet more clones might be affected later on, or not doing anything and living with the partial history. |
I don't think enough people maintain forks of this repo for it to be a big issue, as it lets face it its a legacy code base. Given that if you could provide a step by step to do this I'd be happy to do this. |
Awesome! I should have something shortly. I also see a lot PRs got merged, so they don't need to be rebased later. That's great. Oh and it seems you have pushed @illwieckz's history, the tags at least. |
As promised I've done the preparation work for a new git here, but if you want the actual steps I did to clone svn, clean up, and graft current git onto it, I can document that with some more time. For now, here it is for review: https://github.com/nyov/qstat-tmp /edit: I've also trimmed the initial few commits which are, as illwieckz said, just noise, as well as the empty cvs release branches. No information is lost because of these, but why this repository shows roughly 10 commits less: Let me know if you would find this history suitable or if there seem to be any issues. I believe just putting the new/alternative history into the repository should work fine, but I'll run a few tests and write up the process. |
Very sorry we never got to this as I never got the issue notification emails. Given how old this is now going to close, but feel free to reopen if you want to take this forward. |
Hello @stevenh,
for a while now it has been bugging me that I have not noticed your move to GitHub early on and as result did not tell you about my SVN mirror of qstat (at https://github.com/nyov/qstat-svn).
This bugs me, since I have gone to some pains to nicely migrate it to git, e.g. doing my best effort of using svn-author renames for attribution, and I feel your history here is partly lacking that.
I thought I was ready to move on and leave things be, but apparently not quite.
And I am aware I'm not the first to bother you with that kind of request, but since it becomes increasingly impossible with time, to make a favorable case for changing history (over hurting existing clones), I feel I should at least make a token attempt now to see if you will consider building future work on a nicer? history yet, then be silent about it ever after.
I also feel that by only importing the
qstat2
directory of the svn repo, some interesting history (as the old website) has been wiped.My version started as an svn mirror (and potentially still is), so (unlike #15) I have not rewritten any early commits, to keep the history faithful and the mirror-workflow working. (I've converted some svn release branches to git tags however.)
But it also means the whole subfolders structure has been imported. So there are
qstat2/
, andwebsite/
folders currently in trunk.I am not against the current repository layout here, but I feel the website should retain it's place in the history. Dropping it at this point is not the same as having it wiped out from the whole history.
Additionally I did some work in 2013 to resurrect the website(s) as plain static html and move it to a
gh-pages
branch. I hope that might be another point in favor.(And it's interesting to follow the program's roots back to 1997! It would be criminal not to keep that history -if only partial- of our glorious Quake days, while possible? ;)
There has also been an svn tag
legacy
with binaries for older qstat versions (2.5, 2.4, 2.3). I've dropped that tag in git, to not bloat the repo with binaries, but committed the unpacked sources as separate version tags.Finally I had also committed patches on the SF bugtracker into branches (pending merge or cleanup), though these seem to be mostly addressed in this repo by now.
So that's my dilemma. I don't feel like driving down a different road with a lackluster fork, and maintaining one is not within my time schedule. But I also don't quite feel like feeding it to
/dev/null
without a try to reconcile in some way, first.I am aware rewriting history in a published project is a big no; however I also feel that should be balanced against an effort to attribute those contributors for future code archaeologists (I see you rewrote your own svn user), and not having to work with an ugly history indefinitely.
After all, projects are often enough still slugging around artifacts of lackluster cvs2svn migrations now, do we really want to immortalize "ugly" history as produced by default svn2git migrations (such as the empty commits of the "This commit was manufactured by cvs2svn to create tag xyz" variety in this history currently); what might that become next time?
My mirrors history is not without some warts either (
git-svn-id
lines), but without having to keep up the mirror sync if svn is dead, that could be rectified now.Further it might be less the case of rewriting history here, as instead providing an alternative one, since both trees would have no common ancestor commits. Migrating local changes between trees would require some
git rebase --onto newbase oldbase HEAD
git-fu, but people could do it in their own time (having both trees in parallel) and might be agreeable to do that once for the long-term benefits.Or perhaps 'changing history' could yet be acceptable as part of a potential repository location change to it's own umbrella "Organization", such as https://github.com/quakestat ?
Or as part of bumping the major release version (it's been "qstat2" for a long time now, and Q3A and Q4 have come and gone)?
I'd be glad to hear your view on the matter.
Thank you for your time.
The text was updated successfully, but these errors were encountered: