Andrew Straw <straw...@astraw.com> writes: > Anyhow, now that I've pushed up a more recent master, assuming you want > to apply your work onto that, you could either rebase your commits onto > the master -- thus ignoring the true historical state you developed them > against -- or merge the master branch -- causing the history to be more > complicated, as it's no longer linear.
I opted for the merge, since all the git documentation I have read seems to frown on rebasing anything that has been published. Besides, dealing with non-linear history in this relatively simple case is probably good practice for us git newbies. By the way, would it have been possible for me to use git-svn on my own repository, update it from the official svn and then have everything work out right once you updated your repository? I suppose that should be possible if git-svn guarantees that every one of its users gets the exact same trees for every svn commit, but perhaps even then it would not show up as a proper merge in git. -- Jouni K. Seppänen http://www.iki.fi/jks ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
