After supplying a patch (through my fork), that has become obsolete, and therefore will never be applied…..
….I think I have discovered that it is not a best practice to develop on an ‘official’ tracking branch (e.g. master that tracks origin/master), because I want to always be able to pull from the upstream repo, and have git perform an implicit fast-forward merge. Instead I should always develop on a different branch, and push that branch to my fork before sending a pull request. Is this how other contributors are doing? If anybody else can think of other reasons to always develop on a topic branch before pushing and sending a requests to pull the tip of that branch, please enlighten me? Also how do other contributors keep a local development (e.g.. topic) branch up to date after fetching work from the upstream repo (this branch would contain work not ready for the public eye). Do you guys use merge or rebase to bring in upstream work to the local development branch? Also what would the maintainer of the upstream repo prefer (the branch could very well be pushed to a fork in the future, and be the subject of a pull request)? Kind regards Maxild --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Fluent NHibernate" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/fluent-nhibernate?hl=en -~----------~----~----~----~------~----~------~--~---
