On Wednesday, January 2, 2013 7:06:40 PM UTC+1, John McKown wrote:

> Oh, and if you do revise the git repo, I don't know what will happen if 
> you do a "git push" to a remote repo. It may fail. Or it may update the 
> remote in such a way that others have problems doing a fetch or pull. 
> Perhaps one of the very experienced will speak up on this issue. I really 
> hate doing revisions which impact sharing (like rebase in most cases).

Indeed, a filter-branch operation will rewrite history, so you need to 
announce this to others with access to the repo, if any. They will get an 
warning upon pulling, and will have to reset their own branches to the new 
references you've created through the re-write. 

However, I did just try this with git 1.8, and I might be wrong on this, 
but it seems Git has gotten a bit friendlier towards forced-updates 
recently, and treat the rewritten tracking branch simply as a diverged 
branch - ie. people will get a merge commit on their next pull.

Example output. From *clone-repo-number-1* I have pointed my HEAD revision 
at some rewritten commit, and then push it to to the 
*central-repo's*origin/master branch:

git push -f origin HEAD:master 
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 358 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
To /Users/tfnico/temp/foo.git
 + bd8a45c...158266b HEAD -> master (forced update)

And here I have another *clone-repo-number-2* connected to the same remote *
central-repo* "origin" that I just force-updated, doing a pull:

git pull      
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
>From /Users/tfnico/temp/foo
 + bd8a45c...158266b master     -> origin/master  (forced update)
Merge made by the 'recursive' strategy.
 fee.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

In this case, I actually wish to force the local master branch into being 
the same history and state as the forced-update one, so I do:

git reset --hard origin/master

Now all repos (*clone-repo-number-1, central-repo and **
clone-repo-number-2) *have matching history.

Using git 1.8.0 btw.


Reply via email to