On Thu, 2008-12-18 at 15:58 -0800, Linus Torvalds wrote: > > On Thu, 18 Dec 2008, Alan wrote: > > > > What am i doing wrong here? > > Reverting a merge is your problem. > > You can do it, but you seem to have done it without understanding what it > causes. Obviously. > A revert of a merge becomes a regular commit that just undoes everything > that the merge did in your branch. When you then do the next merge, you'll > do that merge with that in mind, so now git will essentially consider the > previous merge to be the base line, but your revert undid everything that > that one brought in, so the new merge will really only contain the new > stuff from the branch you are merging. So I will have to look for previous reverts (or "pre-verts") before merging again. > So if a merge causes problems, you generally should either undo it > _entirely_ (ie do a 'git reset --hard ORIG_HEAD'), not revert it. > > Of course, if you had already made the merged state public, or done > development on top of it, you can't really do that. In which case a revert > works, but if you want it back, you should revert the revert, not merge > the branch again - because what you merged last time you threw away, and > won't be applied again. On this code base, there were 30+ branches merged before the powers that be decided to have me pull that one. It was in the middle of the pile. I think I know how to fix it. I am just concerned about having it occur again if someone else makes the same mistake I did. Thanks. -- 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
