views:

133

answers:

1

Our project has been using git for a week or so now, and we're all enjoying it a lot (usíng it in a tight collaborative group turns out to be quite a different git experience). To keep things as simple as possible, we do not do any rebasing or history modifications. But we did make a few mistakes in the first week. A few commits were made that shouldn't have been done, and we managed to merge a feature branch into the wrong integration branch (1.1 instead of 1.0). And we didn't find out about these things until they were long into our history.

Now I see a lot of warnings about rewriting history, but I'm not really sure I understand the dangers involved. We use a shared bare repository, and all branches are pushed there for backup.

I would expect that if you rewrite history (say remove a commit), the full list of subsequent commits will "loose" that commit (and maybe not compile/work). I would also expect that if this happens I could actually choose to fix this at the top of history (and just leave that part of history as non-compiling).

  • If I rewrite history (and everything compiles/works in all affected branches), will my co-workers need to do any special commands (i.e. will they "know that I have done it" if I did it well?)?
  • Will any users with local changes that I do not know about be eligible for merge failures on git pull ?
  • Am I missing anything essential here ?

Any references to articles/tutorials on this subject would also be really nice.

+5  A: 

Required reading is Problems with rewriting history in the Git User's Manual.

If I rewrite history (and everything compiles/works in all affected branches), will my co-workers need to do any special commands (i.e. will they "know that I have done it" if I did it well?)?

They will know, and Git will tell them in no uncertain terms that something is wrong. They will get unexpected error messages, and may in the process of trying to resolve the resulting merge conflicts, inadvertently revert previous commits. This problem creates a real message, and if you're curious to see what happens you can always try it on a temporary copy of your repositories.

Will any users with local changes that I do not know about be eligible for merge failures on git pull ?

Absolutely, see above.

Am I missing anything essential here ?

Avoid rewriting history at (almost) all costs!

Greg Hewgill
I had actually read that part of the manual, it feels like I've read all of the manuals RSN ;) Do the rewritten branches always get new identities? That does indeed explain why it should never be done...
krosenvold
Because of the way Git identifies commits by their content *and all previous commits*, any change (however minor) to a commit will look like a totally new branch of development to Git. There is no way to make a rewritten history look "almost the same".
Greg Hewgill
Thanks, strange how just missing a tiny piece of information in git can make all the difference.
krosenvold
That's widely considered to be a *feature* of Git's repository format. What if that tiny piece of information was critically important? See: http://keithp.com/blogs/Repository_Formats_Matter/ for a great post on that topic.
Greg Hewgill
Sorry, I'm not being totally clear: I hadn't understood that rewriting histroy *has* to create a derivate branch. Now that I know I no longer have any unanswered questions about rewriting history ;) I understand that I'm totally pulling the rug on any feature branches created after the point of rewrite.
krosenvold
Now I understand your position. Glad it makes sense now!
Greg Hewgill