Re: Rollback of git commands

"Sean" [off-list ref] writes:

quoted

After doing the commands I located my last commit before the rebase
and edited master back to  it. But my system was still messed up since
moving master got me out of sync with the state stg stored in .git/*.
The 'stg repair' command had changed the stored state.

 From your description is seems that Git proper was able to handle the
situation just fine.   It sounds instead like you're describing a problem
with Stg where it became confused without a way to restore _its_ meta
data.  There's not much Git itself can do to help in this situation
unless Stg stores all of its meta-data as standard Git objects, rather
than just using the .git directory.

Essentially, he does not want to use "git rebase" and have a way to
disable the command on a branch that stg is actively munging.  And that
is something git proper can help with the user, which is why I earlier
referred him to pre-rebase hook.

As you suggested, however, git proper should not know the internals of
Porcelains, so I'd rather not to have that logic deep in git-rebase
itself.  But the pre-rebase hook shoud be the appropriate place for the
user to actually populate with stg specific logic ("is stg set to
actively munge this branch") and activate it for his repository.