On 08/09/2012 07:45 AM, Curtis Olson wrote: > It looks like every time you rebase you have to reapply the same set of > patches over top the target branch.
Not true in general. I've never had a problem like that. > So even if I figure out a way through > it once, I'll have to repeat the same conconction of craziness each time I > rebase. Ditto. > It complains about whitespace errors, then falls back to a 3-way merge, > then reports conflicts with all the files in the 2 old directories, If whitespace were the only problem, you could make the problem go away using --no-verify. Also, as others have suggested, when in doubt, doing "git status" is always a good idea. > I think I'm going to create a new branch, untar my changes on top, > lose all my history and forget about it. Creating new branches is cheap and often an excellent idea, especially if you are uncertain about something and want to experiment. > untar my changes on top, > lose all my history and forget about it. It's not possible to be sure exactly what the problem is without further information, but it seems likely that there is a simpler way to get a similar result without losing history, namely: git rebase -Xours or git rebase -s 'recursive -Xours' You can read the manpage and/or google for more information about what these options do. I believe these options require git version 1.7.3 or later. If you need to install a newer git, that's easy and well worthwhile. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
