25.02.2012, 22:18, "Jason McKesson" <korv...@gmail.com>: > If that is the case, if you're not going to accept any pull requests, > then it might be a good idea to deactivate public forking altogether. > The whole point of the public forking system on Bitbucket is to make it > easy for someone to get the repo, make some local changes, have them > back up on Bitbucket, and then hand those changes back to you for > evaluation.
I don't agree. Forking could be used just to simplify workflow, e.g. you can create your feature branches, work on them, using BitBucket server for synchronization. > Rather than "patches", which are unversioned > single-revisions I'm pretty sure that hg has something like "git format-patch" > which, once incorporated into the repo, would conflict > with the changes that the person just made Presence of conflict does not depend on the way of patch transfer. If path is not up-to-date with target branch, it should be rebased, either by author or by maintainer. >, pull requests preserve > version history, changesets, and so forth. Thus there is a complete > paper-trail of the fix, who created it, where it came from, how many > iterations it took to make it work, how it was merged with the mainline, > etc. This info is not that useful. Useful is end result, i.e. "1 patch (commit)" == "1 ready to use feature". When using git, I use "git rebase -i" to squash commits before contributing my work somewhere - one patch is usually much easier to review. -- Regards, Konstantin ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Premake-users mailing list Premake-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/premake-users
