OpenUru.org

I noticed the other day when I was trying to port my cursor change to the H-uru (GoW) Git repository that there is an incompatibility: https://github.com/H-uru/Plasma/issues/26 (incorporated by reference, please read).

H-uru team members are understandably reluctant about fixing this on their end, given the annoyance this would cause to everyone who is already basing their work on their repository, quite a bunch of people.

So I’m wondering, would it be an option to fix it on the OpenUru.org end, on which as far as I can tell comparatively little activity has been going on that would be disturbed by it? What do you think? How important would you consider having compatible origins for the two repositories, would the benefit justify the hassle of rewriting history? I don’t think it’s OpenUru.org’s responsibility to fix something someone else has broken, but maybe doing it anyway would be of benefit to the community?

Do you have any idea about who (or how many people) already has clones of the OpenUru.org CWE repository and is basing their development on it (aside from the list on the forum)? In particular, do you know if Cyan does that? I plan to ask Mark directly, but don’t want to bother him yet before we have discussed the matter here.

Executing this would involve replacing the first 7 revisions of the CWE repository by their versions from the H-uru repository and rebasing the other 2 on top of them. The only change to the file tree would be the removal of the empty .hgignore file, which as far as I can tell is a no-op. (The file can later be added again, containing useful ignores, in a new revision.) Everyone who already has a clone of the repository from before and pulls from it afterward will get these “duplicates” of these revisions and will sooner or later (before it can be merged into the new trunk) need to rebase their work on them and discard the old ones. (This is complicated by the fact that ‘hg rebase’ works by repeated merging and thus cannot rebase commits between unrelated branches, however I’ve had success with ‘hg export’/‘hg import’. Doing the rebasing in Git should work too.)

I have tentatively done that at https://bitbucket.org/cwalther/cwe-hurubased, so you can examine it, and affected people (if there even are any beside me) could already try rebasing their work to give their opinion.

If I didn't want the ' at the end of my name I would have left it off.

That must have been a bug in both the software used by the H-uru guys for their initial import of r0-6 (fast-export I believe) and in the Hg-Git I used for rebasing r8. (Maybe I should have a closer look, I hope it’s not something with the potential to jeopardize the whole plan of losslessly moving revisions between Mercurial and Git.)

I can fix this in r8 (I hope), but there is no way of changing it in r2-5, as taking these unchanged from the H-uru repo is the whole point of the exercise.

Christian Walther wrote:Do you have any idea about who (or how many people) already has clones of the OpenUru.org CWE repository and is basing their development on it (aside from the list on the forum)? In particular, do you know if Cyan does that? I plan to ask Mark directly, but don’t want to bother him yet before we have discussed the matter here.

I just quickly scanned the logs, it looks like there are 68 unique individuals that have cloned CWE, 41 that have cloned MOSS, and 8 that have cloned MOULSCRIPT.

I need to do the reorganization of the three repos (soon) to move to the branching structure so now is the time to make this call as to whether to rewind the repositories to common trunks. I'm not adverse to it (we actually have a pre-OS announcement precedent alread set for this). Let's close the discussion tonight so if it is desired I can have the weekend to do it.

If I do, I'll try to maintain changeset identities as much as possible, but I suspect that cloned workspaces will become confused. I'll explore that before placing the changed repositories in service as the official copies.

_R

I think it shows a certain disregard for others to just not give a $&$*@ about this sort of thing. It should have been fixed before they opened their repo. I suppose they will not mind at all if people go around dropping letters off THEIR names?

a'moaca' wrote:I think it shows a certain disregard for others to just not give a $&$*@ about this sort of thing. It should have been fixed before they opened their repo. I suppose they will not mind at all if people go around dropping letters off THEIR names?

Funny, I was actually looking into trying to fix this on our fork while limiting the amount of chaos in existing clones and forks after someone pointed this thread out to me earlier today... I should think it was clear that nobody noticed this error until now (otherwise it would have been fixed before we did the initial push), but of course if you'd rather just complain about it, we can certainly leave it in an incorrect state for you. I'd hate to deprive you of good flaming material.


EDIT: I do genuinely apologize that we missed this in our initial conversion... Unfortunately, it looks like the only way to fix it now would involve rebasing the entire repo from your first commit, which would cause mass chaos in all existing clones and forks. Despite my above reply, I would like to fix this, but I don't think it's practical at this point. We will be more careful, but I'd really prefer if this kind of thing were brought up to us directly instead of flaming us about it when it's pretty obvious we didn't even notice it.

Alright, folks. rarified is looking at ways to help everyone.

Thanks for coming by to explain, Zrax. I appreciate it.

You're right, I shouldn't flame, and I'm sorry.

But nonetheless I feel like this is the sort of thing one should have actually looked at and noticed. Conversions are prone to these issues. I sorta feel like nobody noticing meant nobody looked.

Maybe I'm wrong, but that's why I was grumpy. I don't need more "flaming material" and I will say no more on this.

I think we only noticed this ourselves on the back of looking into Christian Walther's original post: I saw a'moaca's earlier post and didn't know what she was getting at until I looked at Christian's repo.

Anyway, I tend to agree that's what's done is done and it's probably a lot of hassle to backtrack on the H'uru Git at this point. What rarified can repair at this end is likely pretty limited, and I'll let him judge on that, but I guess we can probably resolve Christian's original point.

We might be able to replicate the coolest merge ever and create a new repository that has both GoW and OU as parents. It'll look ugly as sin, and have duplicates of the commits that were modified during the conversion... but it will create a repo that will work for what we need.

Assuming I can replicate Linus' git magic, the new repo would also be mergeable back into OU (since OU would be a parent), assuming you guys are interested in getting all the goodies we've gotten fixed up while you've been sorting out your workflow and tools. Hg-git should allow two-way work, and it's what we used for the initial conversion, but obviously someone (and I know who, and he should have known better, and I already complained to him about it) decided to erase .hgignore from history. If I'd realized that had happened sooner I would have fixed the repository before things got to be this complex.

EDIT: I should point out that if you don't pull the merged tree, this will only allow moving patches from you to us - if you want painless merges from us to you, you'll have to pull in the whole merged tree. Hopefully that can happen anyway, though.