Git : How to reset the history of all the repositories associated with a project?

We are two developpers working on a project, using a central repository on BitBucket.

Sometimes I want to reset the history to a specific revision (I know this loses information) :

  • SmartGit Hg “Authentication Failed”
  • Build Bamboo from Bitbucket, Deploy to Azure Cloud
  • How to use special SSH key for BitBucket and GitHub to push/pull?
  • git lock keeps coming back on commit rendering GIT useless
  • How to mark an issue as resolved from the commit log?
  • git push hangs after Total line
  • git.exe reset --mixed 0e827d5fcb7d9b
    git.exe push --all --force

    This correctly resets the history to the revision I want. But if the second developer doesn’t do the same thing, if he doesn’t reset his own local repository, then the next push he is going to make will add back all the commits I removed with that reset!

    When there are only two developers on the project, it’s not that bad. I could probably ask the other dev to run the same reset on its local repo and the history on BitBucket will stay as I want. But I’d like to know if there is a way to force the reset of the history of all the repositories associated with that project? A way to force the second dev to have its local repo to be resetted as mine before he can push to BitBucket again?

    Or maybe I’m missing something obvious (I’m not a Git master)…

  • I've added a remote called “mine”, but my branch is showing up under “origin”
  • How not to display the .class in git
  • How do you share your git repository with other developers?
  • Checking out an old commit and maintaining the head on the master branch?
  • Git subtree pushes a new tree
  • git delete remote branch not working: branch not found
  • 3 Solutions collect form web for “Git : How to reset the history of all the repositories associated with a project?”

    You could simply reset and create a separate branch.

    git checkout -b newBranch 0e827d5fcb7d9b
    git push -u origin newBranch

    Pushing that new branch would allow you to have your own branch to reset and force push without bothering the second developer.

    But if you want to force the second developer to reset his/her own workspace before pushing back, you should:

    • reset (as you are doing)
    • amend the commit (forcing the commit 0e827d5fcb7d9b to have a new SHA1)

      git commit --amend -m "reset branch"
    • force push

    Then any push from other developers would be rejected by default, as being non-fast-forward.
    They would need to fetch, and either rebase their own branch on top of origin/master. Or reset they own working tree to the new upstream/master.

    With your current model of all devs having write access to the “central” repo, this is impossible.

    However, this entire workflow does not scale well for too many developers. You might want to consider another topology of repos, where each dev has a private and a public repo. All devs have write access to their own public repo (SSH), and read-only access to the others’ public repos (HTTP?).

    Each dev pushes his changes to his own public repo, and asks the Dictator to pull from it. The Dictator in turn fetches from the dev’s public repo into his own local one, and inspects the branch. He rejects it if it’s based on a previously deleted commit.

    This assumes having a Dictator in the project who is responsible for merging others’ stuff. The dictator’s origin remote will point to his own public repo and he will have other remotes to his fellow devs’ public repos to pull from. The other devs will also have an extra remote, best called upstream, pointing to the Dictator’s public repo, to fetch the official state of the project.

    No, there is no way to force other developers to do anything.

    It helps if you understand that a branch in git is nothing of substance. It is simply and literally just a string pointing to a commit. It has no structure and nothing else to it.

    This means that git push --all --force does nothing special except updating all the branch “sticky notes” on the remote to point to whichever commits you have them pointing at in your local repository.

    To get the other developers to take your changes, you have to communicate with them and tell them to do something like git fetch ; git branch -D somebranch ; git checkout somebranch which will have the effect of deleting their own somebranch sticky note and replace it with yours (that they just fetched from the remote). somebranch can be master since there is nothing magic about the master branch at all, it also is just a sticky note pointing to some commit.

    If you do as you said, i.e. a reset followed by a forced push, you have created havoc with the other developers anyways; they basically only have the choice of either taking your changes as is, or overwriting them in the same fashin; merging or other things are pretty much out of the question as they will likely end up in chaos.

    Git Baby is a git and github fan, let's start git clone.