On Fri, 12 Feb 2016 10:32:59 -0800 (PST)
Sarvi Shanmugham <sarvil...@gmail.com> wrote:

>    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, for one, doubt it's possible to have one at all--if not for certain
very narrow restricted cases.

I'm afraid when it comes to something written by human, one cannot
fully defer to automated solutions.  I'd say that your automation could
go as far as automatically detecting the faulty commit but it then
should stop there and wait for a human to inspect the situation and
fully comprehend what to do with the commits recorded on top of the
faulty one.

> As far as I understand, we can do something like the above using the 
> following in GIT
> https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History   
> The above seems to be geared towards rewriting the history in my
> private local git repository.

No, `git filter-branch` and `git rebase` do not care which repository
they operate on.  One minor caveat--which might or might not apply to
your case--is that in certain modes of operation these commands might
require the work tree to be present for the repository (that is, they
won't work in a bare repo).  Say, `git filter-branch` in the
"--tree-filter" mode and "edit" action on a commit in the script
generated by `git rebase` will all require work tree.

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

There's no magic about it: it's all explained in the section titled
"RECOVERING FROM UPSTREAM REBASE" in the git-rebase's manual page.

In short, don't do that.  That is, make sure your staging repository
cannot be pulled from.

That's too blunt a statement, but you can make it softer.
Say, make sure that the devs can only pull from a branch which does
only contains "blessed" commits--those which actually passed your
automated staging check discussed above.
The "make sure" there might be as simple as a policy--you don't need to
actually guard your branches against fetching using some access
controlling tools (though you might, if needed).

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