{"thread":{"id":"41490","subject":"Git History Rewriting in a public repository - capability to remove one or more commits from a public repository","startedAt":"2016-02-23T21:30:58Z","lastAt":"2016-02-24T01:08:26Z","messageCount":4,"participants":["Saravanan Shanmugham (sarvi)","Stefan Beller","Ilya Terentyev"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"279077","messageId":"D2F20E85.A04DB%sarvi@cisco.com","threadId":"41490","inReplyTo":null,"subject":"Git History Rewriting in a public repository - capability to remove one or more commits from a public repository","fromName":"Saravanan Shanmugham (sarvi)","fromEmail":"sarvi@cisco.com","sentAt":"2016-02-23T21:30:58Z","receivedAt":"2016-02-23T21:30:58Z","isPatch":false,"sender":{"key":"sarvi@cisco.com","avatar":null},"body":"\n\nHi Git Leads,\n      I am looking for git capability/way to be able to remove commits\nfrom a public repository.\n\nBackground:\nWe are looking for a multi-stage commit process where commits get pushed\ninto a public ³testing-stage² repository.\nWhere we do testing of commits before they are pushed to another public\n³mainline² repository.\n\nWhen there are failures seen in the public ³testing-stage² repository.\nWe would like to implement some process to go identify the bad patch and\ncompletely eject it from that public ³testing-stage² repository, as if it\nwas not connected.\n\nThe plan is to use the Git History Rewriting capability described here\nhttps://git-scm.com/book/en/v2/Git-Tools-Rewriting-History\nSo I can pull a pull workspace from the public ³testing-stage² repository\nuse the above mechanism to eject one or more commits from it.\n\nNow I would like to be able push it back to public ³testing-stage²\nrepository. \nAnd allow other people to be able to sync their workspaces to this public\n³testing-stage² repository, correctly.\n\nThis as I understand is not supported?/recommended? in GIT.\n\nMercurial addresses this with the capability to mark commits with a phase\nsuch as ³Draft² or ³Experimental² and having a workflow around them.\nDescribed here\nhttps://www.mercurial-scm.org/wiki/Phases\n\nhttp://www.gerg.ca/evolve/user-guide.html#evolve-user-guide\n\n\n\nQuestion:\nWhat are the issues?\nWhat needs to be done in terms of development, to support this\nfunctionality and make it work properly in GIT?\nIs there additional development that needs to be done to git core to allow\nthis development process?\n\n\nThanks,\nSarvi\n-----\nOccam's Razor Rules\n"},{"id":"279081","messageId":"CAGZ79kaPPvbfXDPYBsivTtOC8jdNvWC9=xLuHgRGqmZWXy1b4Q@mail.gmail.com","threadId":"41490","inReplyTo":"D2F20E85.A04DB%sarvi@cisco.com","subject":"Re: Git History Rewriting in a public repository - capability to remove one or more commits from a public repository","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-02-23T21:59:34Z","receivedAt":"2016-02-23T21:59:34Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Feb 23, 2016 at 1:30 PM, Saravanan Shanmugham (sarvi)\n<sarvi@cisco.com> wrote:\n>\n>\n> Hi Git Leads,\n>       I am looking for git capability/way to be able to remove commits\n> from a public repository.\n>\n> Background:\n> We are looking for a multi-stage commit process where commits get pushed\n> into a public ³testing-stage² repository.\n> Where we do testing of commits before they are pushed to another public\n> ³mainline² repository.\n\ninstead of different repositories you could have different branches,\nbut as you like...\n\n>\n> When there are failures seen in the public ³testing-stage² repository.\n> We would like to implement some process to go identify the bad patch and\n> completely eject it from that public ³testing-stage² repository, as if it\n> was not connected.\n\nSo git revert is not an option, but you really want to purge the commit\nas if it never existed?\n\nThat is not possible without rewriting history (which is considered bad\nbehavior for public repositories)\n\nYou can use a cherry-picking workflow where you cherry-pick the good\ncommits, once you are sure they are good indeed.\n\n>\n> The plan is to use the Git History Rewriting capability described here\n> https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History\n> So I can pull a pull workspace from the public ³testing-stage² repository\n> use the above mechanism to eject one or more commits from it.\n>\n> Now I would like to be able push it back to public ³testing-stage²\n> repository.\n\nwhen using the cherry-pick workflow above (cherry picking from testing\nto public),\nyou can still merge back public to testing\n\n> And allow other people to be able to sync their workspaces to this public\n> ³testing-stage² repository, correctly.\n\n    git fetch testing && git reset --hard testing-stage test-branch\n\nwould do that client side.\n\n>\n> This as I understand is not supported?/recommended? in GIT.\n\nIt is supported as Git is a toolkit and you can align your workflow using\ndifferent tools from the box.\n\nBut it's not what anyone with prior knowledge of \"How to work with Git\"\nexpects things to be.\n\n>\n> Mercurial addresses this with the capability to mark commits with a phase\n> such as ³Draft² or ³Experimental² and having a workflow around them.\n> Described here\n> https://www.mercurial-scm.org/wiki/Phases\n>\n> http://www.gerg.ca/evolve/user-guide.html#evolve-user-guide\n>\n>\n>\n> Question:\n> What are the issues?\n\nRewriting history is considered bad practice, and that is probably the reason\nwhy there are no good tools AFAIK to verify rewritten history easily.\n\nWhen you consider published history permanent, you can use gpg or local tags\nto know what \"is already good\" and only inspect new incoming deltas\nfor correctness.\n\n> What needs to be done in terms of development, to support this\n> functionality and make it work properly in GIT?\n> Is there additional development that needs to be done to git core to allow\n> this development process?\n\nI think the workflow you described can be done using current tools.\nYou would just need to\npolish things or create aliases for things as this seems to be an\nunusual workflow?\n\nThanks,\nStefan\n\n>\n>\n> Thanks,\n> Sarvi\n> -----\n> Occam's Razor Rules\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"},{"id":"279083","messageId":"56CCD9EA.3010404@gmail.com","threadId":"41490","inReplyTo":"D2F20E85.A04DB%sarvi@cisco.com","subject":"Re: Git History Rewriting in a public repository - capability to remove one or more commits from a public repository","fromName":"Ilya Terentyev","fromEmail":"bacondropped@gmail.com","sentAt":"2016-02-23T22:15:06Z","receivedAt":"2016-02-23T22:15:06Z","isPatch":false,"sender":{"key":"bacondropped@gmail.com","avatar":null},"body":"Hi Saravanan,\n\nChanges that rewrite history, including (but not limited to) deleted \ncommits,\ncan be pushed with the --force or --force-with-lease options, like this:\n\n     $ git push --force remote branch\n\n--force pushes your changes unconditionally, which may overwrite changes\nthat someone else pushed between the moment you cloned the repo and pushed\nyour own. --force-with-lease will check for others' pushes, so you can \nuse it\nin a dry run (without actually changing anything in the remote repository)\nlike this:\n\n     $ git push -n --force-with-lease remote branch\n\nIf someone else (like another developer with access to \"testing-stage\")\npushes anything before your attempt to push, you will receive a message \nlike:\n\n     $ git push -n --force-with-lease remote branch\n     ! [rejected]        branch -> branch (stale info)\n     error: failed to push some refs to remote\n\nGenerally speaking, your idea is, probably, better implemented with patches\nor pull requests:\n\n  1) Your developers rewrite their local history as they wish\n  2) They generate patches from their commits (with git format-patch,\n     for instance)\n  3) Send those patches to \"testing-stage\"\n  4) Apply them to staging area (without committing)\n  5) Run required checks\n  6) If checks don't pass, discard those changes\n  7) If checks pass, commit those patches\n  8) Push committed changes to \"mainline\"\n\nBut in any case, you should better consider using feature branches for that.\n\nBest regards,\nIlya T.\n\n\nOn 02/24/2016 12:30 AM, Saravanan Shanmugham (sarvi) wrote:\n> Hi Git Leads,\n>        I am looking for git capability/way to be able to remove commits\n> from a public repository.\n>\n> Background:\n> We are looking for a multi-stage commit process where commits get pushed\n> into a public ³testing-stage² repository.\n> Where we do testing of commits before they are pushed to another public\n> ³mainline² repository.\n>\n> When there are failures seen in the public ³testing-stage² repository.\n> We would like to implement some process to go identify the bad patch and\n> completely eject it from that public ³testing-stage² repository, as if it\n> was not connected.\n>\n> The plan is to use the Git History Rewriting capability described here\n> https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History\n> So I can pull a pull workspace from the public ³testing-stage² repository\n> use the above mechanism to eject one or more commits from it.\n>\n> Now I would like to be able push it back to public ³testing-stage²\n> repository.\n> And allow other people to be able to sync their workspaces to this public\n> ³testing-stage² repository, correctly.\n>\n> This as I understand is not supported?/recommended? in GIT.\n>\n> Mercurial addresses this with the capability to mark commits with a phase\n> such as ³Draft² or ³Experimental² and having a workflow around them.\n> Described here\n> https://www.mercurial-scm.org/wiki/Phases\n>\n> http://www.gerg.ca/evolve/user-guide.html#evolve-user-guide\n>\n>\n>\n> Question:\n> What are the issues?\n> What needs to be done in terms of development, to support this\n> functionality and make it work properly in GIT?\n> Is there additional development that needs to be done to git core to allow\n> this development process?\n>\n>\n> Thanks,\n> Sarvi\n> -----\n> Occam's Razor Rules\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message tomajordomo@vger.kernel.org\n> More majordomo info athttp://vger.kernel.org/majordomo-info.html\n"},{"id":"279102","messageId":"D2F22F32.A0553%sarvi@cisco.com","threadId":"41490","inReplyTo":"56CCD9EA.3010404@gmail.com","subject":"Re: Git History Rewriting in a public repository - capability to remove one or more commits from a public repository","fromName":"Saravanan Shanmugham (sarvi)","fromEmail":"sarvi@cisco.com","sentAt":"2016-02-24T01:08:26Z","receivedAt":"2016-02-24T01:08:26Z","isPatch":false,"sender":{"key":"sarvi@cisco.com","avatar":null},"body":"Thanks Ilya and Stefan for your detailed responses.\n\nIn general I am trying to avoid having to work with patch sets/queues.\nThis may be acceptable as a replacement for the “testing-stage” repo.\n\nBut we don’t want to have the developer deal with patches or patch queues\nin his workflow.\n\n1. The developer will pulling from the “mainline” repository to  do\ndevelopment.\n2. They will be committing and pushing to the “testing-stage” repository\nor branch as you suggest.\n3. To do (2) above they will need to sync to “testing-stage” repository or\nbranch, which might pull in 20-30 commits that are already in that branch\nor repository.\n4. He might have to resolve some conflicts before he commits it into that\n“testing-stage” repository or branch.\n5. During the window of (4) above, Auto bisection testing process\nhappening on the “testing-stage” repository or branch might have kicked\nout 3 commits from that repository\n6. The kicking out of the 3 commits in (5) above, would require the\ndeveloper sync to the “testing-stage” repository or branch again before\npushing it.\n\nWe want the developer workflow at (3) and (6) above, to not have to deal\nwith patch queues and stuff.\nFor him to be able to do the “sync\" to the “testing-stage” repository\nbranch in (3) and (6) above, allow him to merge the the commits he has\nalready made in his local repository with the rewritten history of commits\ncoming from the “testing-stage” repository or branch.\n\n\nWhat I am hearing you suggest as the way forward is the following\n1. Removing bad patches in “testin-stage” repository or branch\n   1. Use may be branch instead of a separate repository for\n“testing-stage”.\n   2. Pull a workspace repo for removing the bad commit and related\ncommits in that workspace by rewriting history in it.\n   3. Do git push -n --force-with-lease remote branch. If that fails\nbecause additional commits have come bring in the additional changes and\nre-attempt the push.\n   4. When 3 completes successfully the history would have been rewritten\ninto the “testing-stage”\n\n2. Developer has made commits to history space.\n3. Developer syncs to “testing-stage” repo or branch, the first time, in\npreparation for pushing his changes to that branch or repo. All should go\nwell. Since his repo has not seen history from that branch or repo till\nthat time.\n3. Takes time resolve issues.(While the history has changed in the\n“testing-stage” repo or branch)\n\n4. He syncs again, which is where we will have a problem. “git pull” needs\nto recognize that history has changed and fail. Will it do that?\n\n5. Drawing from Stefan Beller’s response, it looks the developer has to\neither manually or through git extension\n    1. Recognize that the history has changed, during a git pull failure.\n    2. Use \"git cherrypick” get his own commits in his workspace have them\nrecommited over the new history that is being pulled from “testing-stage”\nrepo or branch. Do something along the lines of\nhttp://think-like-a-git.net/sections/rebase-from-the-ground-up/using-git-ch\nerry-pick-to-simulate-git-rebase.html to achieve that.\n\nDo I have the workflow right?\n\nThanks,\nSarvi\n-----\nOccam's Razor Rules\n\n\n\n\n\nOn 2/23/16, 2:15 PM, \"Ilya Terentyev\" <bacondropped@gmail.com> wrote:\n\n>Hi Saravanan,\n>\n>Changes that rewrite history, including (but not limited to) deleted\n>commits,\n>can be pushed with the --force or --force-with-lease options, like this:\n>\n>     $ git push --force remote branch\n>\n>--force pushes your changes unconditionally, which may overwrite changes\n>that someone else pushed between the moment you cloned the repo and pushed\n>your own. --force-with-lease will check for others' pushes, so you can\n>use it\n>in a dry run (without actually changing anything in the remote repository)\n>like this:\n>\n>     $ git push -n --force-with-lease remote branch\n>\n>If someone else (like another developer with access to \"testing-stage\")\n>pushes anything before your attempt to push, you will receive a message\n>like:\n>\n>     $ git push -n --force-with-lease remote branch\n>     ! [rejected]        branch -> branch (stale info)\n>     error: failed to push some refs to remote\n>\n>Generally speaking, your idea is, probably, better implemented with\n>patches\n>or pull requests:\n>\n>  1) Your developers rewrite their local history as they wish\n>  2) They generate patches from their commits (with git format-patch,\n>     for instance)\n>  3) Send those patches to \"testing-stage\"\n>  4) Apply them to staging area (without committing)\n>  5) Run required checks\n>  6) If checks don't pass, discard those changes\n>  7) If checks pass, commit those patches\n>  8) Push committed changes to \"mainline\"\n>\n>But in any case, you should better consider using feature branches for\n>that.\n>\n>Best regards,\n>Ilya T.\n>\n>\n>On 02/24/2016 12:30 AM, Saravanan Shanmugham (sarvi) wrote:\n>> Hi Git Leads,\n>>        I am looking for git capability/way to be able to remove commits\n>> from a public repository.\n>>\n>> Background:\n>> We are looking for a multi-stage commit process where commits get pushed\n>> into a public ³testing-stage² repository.\n>> Where we do testing of commits before they are pushed to another public\n>> ³mainline² repository.\n>>\n>> When there are failures seen in the public ³testing-stage² repository.\n>> We would like to implement some process to go identify the bad patch and\n>> completely eject it from that public ³testing-stage² repository, as if\n>>it\n>> was not connected.\n>>\n>> The plan is to use the Git History Rewriting capability described here\n>> https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History\n>> So I can pull a pull workspace from the public ³testing-stage²\n>>repository\n>> use the above mechanism to eject one or more commits from it.\n>>\n>> Now I would like to be able push it back to public ³testing-stage²\n>> repository.\n>> And allow other people to be able to sync their workspaces to this\n>>public\n>> ³testing-stage² repository, correctly.\n>>\n>> This as I understand is not supported?/recommended? in GIT.\n>>\n>> Mercurial addresses this with the capability to mark commits with a\n>>phase\n>> such as ³Draft² or ³Experimental² and having a workflow around them.\n>> Described here\n>> https://www.mercurial-scm.org/wiki/Phases\n>>\n>> http://www.gerg.ca/evolve/user-guide.html#evolve-user-guide\n>>\n>>\n>>\n>> Question:\n>> What are the issues?\n>> What needs to be done in terms of development, to support this\n>> functionality and make it work properly in GIT?\n>> Is there additional development that needs to be done to git core to\n>>allow\n>> this development process?\n>>\n>>\n>> Thanks,\n>> Sarvi\n>> -----\n>> Occam's Razor Rules\n>>\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message tomajordomo@vger.kernel.org\n>> More majordomo info athttp://vger.kernel.org/majordomo-info.html\n>\n\n"}]}