Somehow first mail was not reached the list, resending it. > The "bind commit" experiments for subproject support is coming > along rather nicely. Near the tip of the "pu" branch, there > are: ... > > I think the first four are more-or-less well debugged. > > I am reasonably confident that I did not break rev-list for > repositories without "bind" commits, but I have no clue how > correct it is when dealing with commits with "bind" lines. This > is the last major remaining piece of the puzzle, and the rest is > just the matter of scripting. I'd be sending out a request for > help on the rev-list in a separate message. > > There still is no barebone Porcelainish work done using these > changes. The attached script demonstrates a superproject that > binds two subprojects with their own development histories. I tested this with your script. It works well. But I have found some downsides. subpro and main are separate projects and master is the join of them. If I want to modify subpro I have to checkout subpro branch, edit files. When I have to got to master and bind new version of subpro to it. Worse, if I will edit subpro's files bined to master branch changes will go to master branch instead of subpro's history. As a result all other project (imagine master-2) that use subpro will lose this change. 1. Can I bind some branch instead of tag (commit) ? 2. Is it possible to commit changes of subpro's file in master branch into subpro branch to make this changes visible to master-2 ? Thanks for attention. Alexander Litvinov. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Sat Jan 21 21:36:43 2006
This archive was generated by hypermail 2.1.8 : 2006-01-21 21:36:52 EST