I am looking to implement a workflow that involves
1. Developers committing a sequence of change sets, into a staging
2. Where these change sets go through some sanity testing at periodic
points, say every 10 commits
3. If there is a failure, we would like to implement automatic
bisection, building and testing to find the bad patch that is causing the
tests to fail.
4. We would like to now be able to completely eject/remove the
commit/patch from the staging git repository, as if it never went in, as
well as any other commits that might be related to it that came in after
that, and NOT just attempt to reverse it by committing a reversal patch at
As far as I understand, we can do something like the above using the
following in GIT
The above seems to be geared towards rewriting the history in my private
local git repository. And I need to be able to identify the bad commit and
remove and its dependent commits automatically with a script.
If this above kind of removing of commits and rewriting of git history
needs to be done into a public repository, such as staging repository
above, that developers will be seeing and pulling and syncing from, then my
understanding of the process is a bit murky.
>From what I understand, I can use the above tools for rewriting the history
in my staging git repository.
But what happens when developers had pulled with this staging repository,
then the history was rewritten to reject some commits and the developer
tries to sync/commit to it.
Is this allowed? What are the caveats? Is there someplace that describes
Occam's Razor Rules
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.