On Tue, 14 Jul 2009, davidb@xxxxxxxxxxx wrote: > On Tue, Jul 14, 2009 at 05:16:54PM -0700, Bryan Donlan wrote: > > > What do you mean by describing a merge? git is designed to have all > > the information needed for a merge inherent in the repository history. > > Yes, provided you can actually do the merge all at once. > > > Why are there so many conflicts to make this an issue? > > Because I have to work in the "real world". > > > If the commits are isolated to small changes, rebasing the developer > > topic branches instead of merging may help, by allowing you to take > > conflicts one commit at a time. For example, if your problems are > > primarily conflicts between developer branches and upstream: > > No real developer branches with conflicts (I make those be > fixed), but several upstreams. We have many developers busily > doing work, and one or more other companies is also working on > the same code. Meanwhile, the mainline kernel advances at it's > own astounding rate. > > Unfortunately, paying customers will always get priority of work, > even when that position is actually somewhat shortsighted and it > makes for a lot of merge effort later. > > The real issue is that there isn't any single individual who > understands all of the code that conflicts. It has to be divided > up somehow, I'm just trying to figure out a better way of doing > it. It sounds to me like you're maintaining an internal version that everybody merges their stuff into, and you periodically merge that with the mainline kernel (generating a lot of conflicts which have to be resolved at the same time). Instead of merging the branch that contains a lot of merges, it would probably be easier to merge into a clone of mainline each of the things that was merged before. That is, instead of merging less than all of two trees, you'd merge commits which are not the newest commit on the branch, choosing ones that individuals can resolve. This also has the advantage where, if two of the changes affect an API that's used in various different places, one person will get the responsibility of resolving each of those conflicts, despite them being in the middle of code they don't really understand, because they understand what happened with the API and therefore what has to be done in that little spot. Dividing the merge up by parts of the content would split this work among people who aren't looking at the conflict in the definition of the API. -Daniel *This .sig left intentionally blank* -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html