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 
the end.

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 
that workflow?



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 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to