On 2009-01-10, Peter Harris <git@xxxxxxxxxxxxxxxxxxx> wrote: > On Sat, Jan 10, 2009 at 6:11 AM, Junichi Uekawa wrote: >> I am thinking of recommending the users to create a branch > ... >> and throw away their branches when they are included upstream. > > Yes, with a patch based workflow, this is almost required; all of the > commits will at least have different committer information. > > There's nothing wrong with this approach. That is almost exactly what a rebase does. Each patch on your local "master" that eventually made it upstream gets discarded during the rebase (which is a pretty cool thing!), and what remains are commits that did not make it upstream -- their current "work in progress". The difference between "origin/master" and "master", after each rebase, is their "private branch". Except you don't have to confuse them by saying so ;-) >> Something tells me the problem is that I'm probably using a workflow >> that resembles SVN too much, and users aren't used to branches yet. >> Has anybody found this to be a problem, or better yet, is there a >> better workflow? > > If you need the commits to be identical, and you don't mind your email > consisting of a binary blob attachment, you can ask your contributors > to send you a bundle instead of a series of patches. "git help bundle" > for details. Excellent idea. But it only works for the first user who sends him a bundle. The next one that he gets, assuming that user also started from the same "upstream" commit as the starting point, will be a merge, and he has to resolve conflicts anyway. Essentially, two things have to happen to reduce conflict resolution overall. The users must rebase against the latest upstream before sending the patch, and the supervisor must process and push received patches asap. -- 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
