> Merging all branches on the remote named "origin" is simply not an > intelligent thing to do. Nobody blindly merges everything available > from a remote, and nobody has ever asked for such a function before > in Git. I still think its nuts, but I don't know all details of > your situation so I'll just shut up now and hope you know what you > are really asking for. Ok, I'm not going to belabor the point, but for the most part, the requests in our particular domain are separate. A developer for the most part works only on files that other developers are not working on. There are exceptions to this, but for the most part this is true.. Hence, most of the time there will be no conflicts. Anyways, I'll try to improve on your script, but it looks like what I want to do. > This is going to be slow as you are running git-merge for each > and every branch available to you. You can do a lot better by > loading the branch DAG into memory in Perl/C/Python and doing a > graph coloring algorithm to see if a merge is necessary or not, > as if you are merging everything all of the time almost everything > is going to be always merged to everything else. Which as I said > earlier is nuts. hmm. Is there a simple method to get this graph? I'm assuming that you would have to get all the local commits and compare them to the remote commits, and only merge the branches that have commits not yet merged.. Ed > -- > Shawn. > - > 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 - 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
