Re: Git History Rewriting in a public repository - capability to remove one or more commits from a public repository

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Saravanan,

Changes that rewrite history, including (but not limited to) deleted commits,
can be pushed with the --force or --force-with-lease options, like this:

    $ git push --force remote branch

--force pushes your changes unconditionally, which may overwrite changes
that someone else pushed between the moment you cloned the repo and pushed
your own. --force-with-lease will check for others' pushes, so you can use it
in a dry run (without actually changing anything in the remote repository)
like this:

    $ git push -n --force-with-lease remote branch

If someone else (like another developer with access to "testing-stage")
pushes anything before your attempt to push, you will receive a message like:

    $ git push -n --force-with-lease remote branch
    ! [rejected]        branch -> branch (stale info)
    error: failed to push some refs to remote

Generally speaking, your idea is, probably, better implemented with patches
or pull requests:

 1) Your developers rewrite their local history as they wish
 2) They generate patches from their commits (with git format-patch,
    for instance)
 3) Send those patches to "testing-stage"
 4) Apply them to staging area (without committing)
 5) Run required checks
 6) If checks don't pass, discard those changes
 7) If checks pass, commit those patches
 8) Push committed changes to "mainline"

But in any case, you should better consider using feature branches for that.

Best regards,
Ilya T.


On 02/24/2016 12:30 AM, Saravanan Shanmugham (sarvi) wrote:
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.

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.

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.
And allow other people to be able to sync their workspaces to this public
³testing-stage² repository, correctly.

This as I understand is not supported?/recommended? in GIT.

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


Thanks,
Sarvi
-----
Occam's Razor Rules

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message tomajordomo@xxxxxxxxxxxxxxx
More majordomo info athttp://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]