On 17/03/2009, at 9:22 AM, Jeff wrote:
The reason for this email, though, is that I subbed to this list to watch how things are done, learn protocol, etc. So I grabbed the git repo and started looking at how I was going to apply this patch since enough has changed to cause all but 1 hunk to fail. I am not familiar with git, preferring svn, but can read docs. Where I'm tripped up is realizing that head doesn't reflect what private branches might hold. One person (sorry, I forget who) mentioned having a branch with many makepkg changes in it which would cause me to have to hand apply these changes again.
The typical centralized workflow is that contributers check out the "official" tree, create their patches, and then request to pull changes (via git-pull, emailing patches or other means). The nature of multiple people contributing at once is that things will get updated while you're working on something. Unfortunately the only thing you can do is fix it up and re-submit. Don't worry about what other people are doing, you should really be focusing on changes in the official tree. If you read that someone is making huge changes to something related to what you're working on then you could start basing your patches off them (this is the distributed part), if you're certain they will go into the official tree. It's just common sense really. As far as I can tell that workflow applies to Pacman development. In general try to have small commits locally. When submitting you can squash them into a bigger one (though if it's really big it's better to split them up sometimes). This could make it easier to fix up those commits later, since it's only a part of your changes would conflict (i.e., a few commits rather than all of them). Oh, and remember to use branches!