How does git remove the nuclear bomb detonation code and the change from topgit 0.7 to 0.8?

From: http://blog.ossxp.com/2010/01/184/

We have used topgit and git to implement internal version control for a long time. Today, we require you to completely clear the push option in git configuration.

You must use the following command to first find the GIT configuration file with the topgit error:

$ find . -maxdepth 4 -name .git -type d | \  while read x; do \  grep -H push $x/config; done

Then, use VI to open the config files that contain push statements one by one and delete the contained push statements.

Why are we doing this? This involves git's non-fast-forward and topgit 0.7 bug and 0.8 improvement.

Why is the title so scary? What is a nuclear bomb password? In fact, this is a saying we often use in Subversion training to combat commercial version control tools. That is to say, SVN can completely delete sensitive data (including historical deletion) in the code library that is incorrectly submitted ), this is difficult to implement in commercial version control tools. Git as the open source version of the library No. 1, of course, can support the thorough deletion of sensitive data (but not before the deletion of others pull to go, or one by one to "Shut Down": X-P :).

Git's nuclear bomb removal password is the issue of non-fast-forward.

About git fastforwards

When git executes push, it will execute a check: that is, the top node of the remote branch should be the child node of the new node to be pushed locally, otherwise the error "non-fast-forward" will be reported ".

For example:

• The version update in the remote version Library (someone else may have pushed a new commit), the local version is still the old one, and the push is rejected. (If yes, other people's submissions will be deleted)

  Remote version Library: --- O local version Library: --- O

• A local modification made based on an old version rejects the push to the server;

  Remote version Library: --- O local version Library: --- O \ -- o'

Under normal circumstances:

• In the first case, you need to execute git pull and update it to the latest version locally. Of course, you do not need to push it.

  Remote version Library: --- O local version Library: --- ORun the following command locally:Git pullAfterLocal version Library: --- O

• For local changes based on an old version, you must first execute git pull and complete the push of the kimono service version to the server;

  Remote version Library: --- O local version Library: --- O \ -- o'Run the following command locally:Git fetch; git merge; git commitAfterLocal version Library: --- O \ -- o '--- \ o"Then push to the remote server:Git pushRemote version Library: --- O "\ -- o '-----/

But what if we really want non-fastforwards?

• Sorry! To undo the push from the previous database to the remote version Library

  Remote version Library: --- O (master)Run the following command in the local version:Git reset -- hard head ^AfterLocal version Library: --- O (master)Execute force push:Git push origin + master: Master(Note the plus sign)Later, the remote version library changed to --- O (master)

• Similarly, if remote submission contains errors, you must force local changes to overwrite the changes in the remote version library.

  Remote version Library: --- O local version Library: --- O \ -- o'Execute CommandGit push origin + master: MasterAlso pay attention to the plus sign in the command to forcibly overwrite the remote version LibraryThe remote version library changes to: --- O'

Topgit 0.7 bug

When we used topgit 0.7, branch changes were overwritten, which made me very worried. Is it wrong to select topgit? The problem was located later: two lines of Push configuration were added to the. Git/config file for topgit:

[remote origin]  ...  push = +refs/top-bases/*:refs/top-bases/*  push = +refs/heads/*:refs/heads/*

Do you see the plus sign in the Push configuration command? Topgit (version 0.7 and earlier) is the culprit.

See
Tg-remote.sh for topgit 0.7

28 ## Configure the remote2930 git config --replace-all "remote.$name.fetch" "+refs/top-bases/*:refs/remotes/$name/top-bases/*" "\\+refs/top-bases/\\*:refs/remotes/$name/top-bases/\\*"31 git config --replace-all "remote.$name.push" "+refs/top-bases/*:refs/top-bases/*" "\\+refs/top-bases/\\*:refs/top-bases/\\*"32 git config --replace-all "remote.$name.push" "+refs/heads/*:refs/heads/*" "\\+refs/heads/\\*:refs/heads/\\*"

How can this problem be solved?

At that time, we thought of the following method: configure the GIT server so that the GIT server does not allow non-fast-forward push. The configuration is as follows:

[receive]denyDeletes = falsedenyNonFastForwards = true

Improvement on topgit 0.8

After the topgit upgrade, we found that the annoying non-fast-forward push statement is missing, that is, when the TG remote-populate origin is executed. git/config generates a nasty Push configuration command, but provides a Tg push command to facilitate branch push.

Of course, the GIT server is still configured at this time, and the push of non-fast-forward is not allowed. After all, someone else is using the version of topgit 0.7 or earlier, or there is a git configuration created using the version of topgit 0.7 or later.

Days Without non-fastforward

Many times, if you are confident about pushing and find that there is a problem, you want to cancel the push. Or some of the commits should be performed in the branch, while some of them should be performed on the master line, and the push to the server needs to be revoked.

Because non-fast-forward is not allowed on the server, the Administrator must manually modify the server configuration and temporarily enable non-fast-forward submission. After the user completes the non-fast-forward push, the server settings are disabled. My wife is in trouble.

The Administrator is angry.

The Administrator is angry and the result is very serious:

• TopgitRequiredUpgrade
  Group newsFor the improved topgit version 0.8, see
  Http://github.com/ossxp-com/topgit (see each branch for improvements)
• You must check all. Git/config files and delete all the push statements introduced by topgit!
• The server is configured to allow non-fast-forward submission.

The Administrator provides a more violent command to directly Delete the push statement in the config file:

$ find . -maxdepth 4 -name .git -type d | \  while read x; do \    grep -q push $x/config  && \    sed -i -e '/^\s*push\s*=/ d' $x/config; \  done