I think automation I suggest doable considering a little bit more detail
on the problem that might not be apparent in my original email.
There are 2 repositories
1. golden_repo
2. incoming_repo(think staging repo)
Every patch that will eventually go into golden_repo has to go through i.e.
commit into the incoming_repo for extensive build and testing.
Developer Workflow:
1. Developers pull from golden_repo and do their work in their workspace
2. When a patch is ready for commit, they submit the patch for approval.
3. The patch goes through code review, unit testing, and short smoke
test, etc based on the latest in the golden_repo
4. The patch then gets commited into incoming_repo(staging repository)
5. The incoming_repo may contain other commits that are also in the
process of being tested before they are merged into the golden_repo
5. More extensive build and smoke testing happens in the incoming_repo,
on a sequence of N commits, in order, as a pipeline.
6. When the more extensive build and smoke tests pass for a sequence of
N commits in the incoming_repo, these commits are pushed from the
incoming_repo to the golden_repo
Smoke Failure
7. When this extensive build/smoke fails in the incoming_repo for a set
of N commits, the system will automatically do bisection of the commits to
identify the bad commit.
8. Once that is identified, the idea is to remove the bad commit. The
other commits to be removed are only the ones that have a merge conflict
because of he removal of the bad commit.
So "as well as any other commits that might be related to it" is simply
merge conflicts that will need a human touch to resolve.
So they can be prevented from going in and bring a human to address the
issue.
If this can't done the other alternative, which is currently in use, is to
hold every other patch in the queue until a human can come and resolve it
manually.
This way, if there are 10 commits in the pipe and 1 is bad and 2 others
have a merge conflict with the bad one.
We can now eject 1+2 commit and let the rest of the 7 commits go into the
golden_repo.
That said, the question is less about the logistics of detecting the
related patches, but the idea of ejecting them out.
When such an event happens on the incoming_repo, its history will change.
Problem:
1. Developers will typically be pulling and building out of the
golden_repo.
2. But then they are ready to commit, the commit has to go into the
incoming_repo
3. The change might have a conflict with the changes in the
incoming_repo, that they might need to resolve.
4. They would need to sync with incoming_repo and resolve the conflicts.
So far so good.
5. If after doing this they took some time to do this and the history on
the incoming_repo was rewritten during that time becuase of a bad commit
6. GIT would need to handle the case of syncing again with the rewritten
history in the incoming_repo
This last part is what I am trying to understand how to do in GIT.
Since like you say, rewritting history in a public repository such as the
incoming_repo is discouraged.
But that is what I am trying achieve in a smooth way.
The functionality I am looking for is similar to the following in core
Mercurial
https://www.mercurial-scm.org/wiki/Phases
And the following evolve extension that is built on the above core
functionality.
http://www.gerg.ca/evolve/user-guide.html#evolve-user-guide
Hope that clarifies the question,
Thanks,
Sarvi
On Friday, February 12, 2016 at 11:01:47 AM UTC-8, Konstantin Khomoutov
wrote:
>
> On Fri, 12 Feb 2016 10:32:59 -0800 (PST)
> Sarvi Shanmugham <sarv...@gmail.com <javascript:>> 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.
