Re: Git History Rewriting in a public repository - capability to remove one or more commits from a public repository
- From
Stefan Beller <sbeller@google.com>
- Date
- Feb 23, 2016, 21:59 UTC
- Message-ID
- <CAGZ79kaPPvbfXDPYBsivTtOC8jdNvWC9=xLuHgRGqmZWXy1b4Q@mail.gmail.com>
- In-Reply-To
- <D2F20E85.A04DB%sarvi@cisco.com>
On Tue, Feb 23, 2016 at 1:30 PM, Saravanan Shanmugham (sarvi) <sarvi@cisco.com> wrote:
Show 11 quoted lines
> > > Hi Git Leads, > I am looking for git capability/way to be able to remove commits > from a public repository. > > Background: > We are looking for a multi-stage commit process where commits get pushed > into a public ³testing-stage² repository. > Where we do testing of commits before they are pushed to another public > ³mainline² repository.
instead of different repositories you could have different branches, but as you like...
Show 5 quoted lines
> > When there are failures seen in the public ³testing-stage² repository. > We would like to implement some process to go identify the bad patch and > completely eject it from that public ³testing-stage² repository, as if it > was not connected.
So git revert is not an option, but you really want to purge the commit as if it never existed?
That is not possible without rewriting history (which is considered bad behavior for public repositories)
You can use a cherry-picking workflow where you cherry-pick the good commits, once you are sure they are good indeed.
Show 8 quoted lines
> > The plan is to use the Git History Rewriting capability described here > https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History > So I can pull a pull workspace from the public ³testing-stage² repository > use the above mechanism to eject one or more commits from it. > > Now I would like to be able push it back to public ³testing-stage² > repository.
when using the cherry-pick workflow above (cherry picking from testing to public), you can still merge back public to testing
> And allow other people to be able to sync their workspaces to this public > ³testing-stage² repository, correctly.
git fetch testing && git reset --hard testing-stage test-branch
would do that client side.
> > This as I understand is not supported?/recommended? in GIT.
It is supported as Git is a toolkit and you can align your workflow using different tools from the box.
But it's not what anyone with prior knowledge of "How to work with Git" expects things to be.
Show 12 quoted lines
> > Mercurial addresses this with the capability to mark commits with a phase > such as ³Draft² or ³Experimental² and having a workflow around them. > Described here > https://www.mercurial-scm.org/wiki/Phases > > http://www.gerg.ca/evolve/user-guide.html#evolve-user-guide > > > > Question: > What are the issues?
Rewriting history is considered bad practice, and that is probably the reason why there are no good tools AFAIK to verify rewritten history easily.
When you consider published history permanent, you can use gpg or local tags to know what "is already good" and only inspect new incoming deltas for correctness.
> What needs to be done in terms of development, to support this > functionality and make it work properly in GIT? > Is there additional development that needs to be done to git core to allow > this development process?
I think the workflow you described can be done using current tools. You would just need to polish things or create aliases for things as this seems to be an unusual workflow?
Thanks, Stefan
Show 11 quoted lines
> > > Thanks, > Sarvi > ----- > Occam's Razor Rules > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html