On Tue, Jul 14, 2009 at 9:19 PM, <davidb@xxxxxxxxxxx> wrote: > On Tue, Jul 14, 2009 at 05:34:26PM -0700, Avery Pennarun wrote: >> How about having one person do the merge, then commit it (including >> conflict markers), then have other people just make a series of >> commits removing the conflict markers? > > I guess this helps in some sense, but the intermediate result > isn't going to build, and things like mergetool aren't going to > work. It's helpful for the individuals to have the full merge > conflict available, or at least the stages of the files in > question. It sounds like you're going in circles a bit here. You want the full merge conflict available - but you want it to be able to build. It sounds like the "git reset the unwanted subdirs" solution suggested earlier is the only option that will really work. You could simplify life for your co-workers by writing a script to automate the steps, I suppose. You probably want all the individuals to use merge --squash, so that you don't mark the history as merged until you're done. Then you combine all their work at the end and mark the commit as done using 'git merge -s ours'. Avery -- 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