SGUG RSE: WIP + Automation

Shall we rewrite history?

  • Do nothing, ass

    Votes: 2 33.3%
  • Rewrite history for me

    Votes: 1 16.7%
  • Let's use a new branch

    Votes: 3 50.0%

  • Total voters
  • Poll closed .


Active member
Jun 1, 2019
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:
  • 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
Any other suggestions / ways to get these out of the history / object cache?

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)
Point of view of work -> this is just a few git commands to alter the WIP branch of sgug - tricky bit is what it breaks for people cloned off it.

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.



May 3, 2020
San Diego, Ca
I think you have a lot of leeway at this point, it's WIP, it's BETA, it's disposable. You've made a huge amount of progress as you/we/the team gets closer to stable then the commit issues/logs will be more important. At this stage I'd do not worry about too much do whatever is easier for you.



Dec 26, 2019
New York City
I vote for doing nothing + adding protection rules to WIP:
  • Don't feel like we gain a ton by rewriting history, other than easier search. It will upheave everyone's wip and cause conflicts, which IMO is more painful.
  • We should adopt a policy of squash-on-merge to not deal with this.
  • Add protection to WIP and require one review with explicit criteria around what a review entails. For wip, maybe a build log with every new package is the way to go. Doesn't have to be heavy!


Feb 8, 2019
I thought we created wip to be a disaster zone. Filled with sharks.

When I merged the 1600ish automated piles of poop into it, I didn't think it'd cause any trouble. (I also didn't realize they contained FC32 stuff at the time).

If history/objects are a problem:
  • rename wip to wip_stuffed
  • make a new branch off wip_stuffed called wip at just before Massive merged my python poop for me
  • merge the non-automated branch into the new wip branch
  • delete wip_stuffed
That'll solve the wip problem this time, but we need to decide if wip's still a work in progress or not. If wip's no longer wip, something will end up being the new wip, and will wind up in the same state as current wip, since this is where we run wild experiments with a great chance of disaster.

For 0.0.6 consider the following steps:
  • create 0.0.6 from master
  • freeze non-bugfix commits into master
  • put stuff we like from wip into 0.0.6
  • make that stuff work and be pretty
  • more people than Sir Hams look at 0.0.6 to ensure True Qality
  • we bless 0.0.6
  • merge 0.0.6 into master and release!?


Active member
Jun 1, 2019
Looks like "use a new branch" is winning. Closes in an hour and a bit.

For reference, we _have_ a branch without the automated stuff which is up to date (wipnonautomated) - if we end on "use a new branch" we're pretty much all ready -> I'll cut the 0.0.6 release branch from that and off we go.

If we go down the "use a new branch" - I'd like to delete the wip branch - so we don't leave it around for people to make mistakes from.


Active member
Jun 1, 2019
"New Branch" it is.

Ladies and Gentlemen, please move your (new) commits over to the wipnonautomated branch.

I have added branch protection to wip (to stop any further pushes) - and will plan to delete it one week from now.

Thanks to those who helped get us over the little bump + provided feedback.


Active member
Jun 1, 2019
`wip` branch (and a few others) are now zapped from main sgug-rse GIT repo.

If you want to clean up your local repo, something like this should help:

# Assuming you have the sgug-rse repo as "origin"
# This should fetch and prune the deleted branches
git fetch -p origin

# Then garbage collect the orphaned objects in the local GIT cache
git gc

# You can check if you still have the wip branch by listing the branches
git branch

# And a "visual" check can be done through the gui
git gui
# Now select "repository->visualize all branch history"
# If you don't see all the automated commits listed there, all is good.
  • Like
Reactions: Unxmaal

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu