Hello Chaps + Chapesses,
Keeping this off in a separate post so we're not cluttering up the other topics.
We had a wee frenzy on the WIP branch with a large number of automated commits - and the (current) revert approach is a few additional commits after that to "undo" the >1200 automated commits.
Please don't attempt to fix this yourself "to see what happens" until we've chosen a course of action (which might be "do nothing") and who's doing what .-)
The why:
How I believe we can remove them:
The result of the suggested approaches:
I'm all ears about "don't do this, just leave it" - or even if there are other approaches that means they are gone from the cache etc.
I'm throwing this out there now before 0.0.6, as it's the least worst time to resolve it if we want.
Feedback most definitely welcomed.
D
Keeping this off in a separate post so we're not cluttering up the other topics.
We had a wee frenzy on the WIP branch with a large number of automated commits - and the (current) revert approach is a few additional commits after that to "undo" the >1200 automated commits.
Please don't attempt to fix this yourself "to see what happens" until we've chosen a course of action (which might be "do nothing") and who's doing what .-)
The why:
- The >1200 commits + their content are in fact still there, stored for eternity as is (because they form the history of a branch)
- They bloat out the change log, commit history and the GIT object cache (and we are on SGIs, let's try and keep stuff reasonable)
- At some point in the future, we'll really merge the >1200 correct specs, I guess, but let's deal with that when we get there
How I believe we can remove them:
- On the WIP branch rollback to a commit before they began + "force push" that as HEAD pointer of the WIP branch to the sgug repo
- Care of non-automated commits (HAL has one, not sure if there are others) -> looking into cherry picking those onto the wipnonautomated branch
- Other options - delete WIP + recreate it from another without those commits
- The above is "rewriting branch history", read up on it, mostly it's considered harmful
- We could also say "you're dead to me now, wip" + use a different branch entirely
The result of the suggested approaches:
- Results mostly the same for the above choices, conflicts on "pull" from WIP - which needs either a force pull or re-clone without the conflict
- Github style forks (personal repos) will need to force push the WIP change (or delete + recreate their fork)
- "Fresh" clones of the repo after the change will be fine (so backup the old repo to the side, kind of thing so you're not losing anything)
I'm all ears about "don't do this, just leave it" - or even if there are other approaches that means they are gone from the cache etc.
I'm throwing this out there now before 0.0.6, as it's the least worst time to resolve it if we want.
Feedback most definitely welcomed.
D