"Sean" <seanlkml@xxxxxxxxxxxx> writes:
>> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
