Konstantin Khomoutov <flatw...@users.sourceforge.net> writes:
>>    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.
> I'm afraid that "as well as any other commits that might be related to
> it" bit was not thought out very well.
> Say, the devs pushed 10 commits to your staging repo; the 3rd one
> was detected to having had introduced a faulty change.
> Do you have a robust algorythm to figure out which of the remaning 7
> commits are related to that faulty one?

I'm sure that the only effective way to do it accurately is to require
the developers to flag each commit's dependency on previous commits.
Then again, in a way, that data is captured by the history of the new
commit *in the developer's* working tree.


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