On Mon, Mar 16, 2009 at 9:28 PM, Sebastian Nowicki <sebnow@gmail.com> wrote:
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.
Yeah, that's the git concept that confuses lots of people at first. Don't worry about other people's trees (unless they're your base), only worry about the tree you want to get merged to. The one managing THAT tree should concern themselves with the merges (though, they may simply say: "can you fix this up so it merges cleanly after these changes?"). For project foobar, let's assume there are 3 people developing (bob, alice, and bruce) all with their own trees, along with one master tree we'll just call "foobar". One person should probably have "push" rights to foobar. That person will be the one managing which patches are pulled from the other two developers and pushed to the master tree. This is the way pacman rolls. Dan is the only one with push permissions to the master tree, and he pulls/merges/cherry-picks patches from the ML and from other people's branches and pushes them there