Hi Mike, Michael Horowitz <michael.horowitz <at> ieee.org> writes: > I don't have a problem with the branch detection if other people use > it in ways I don't, but it would be nice to have more options and > documentation around it. Yes, documentation is a bit scarce. And looking again at my patch the description text also does not seem quite good enough. > The best I can do to describe what I want is for it to use what is > returned by "git-p4 branches", at minimum. If there is some optional > additional "new branch detection" logic, I don't have a problem with > that, but that should only be in addition to the branches it already > knows about from "git-p4 branches". So, when I do a "git-p4 sync" or > "git-p4 rebase", and it is importing changes from/to multiple > branches, then it should get that list of branches using the same > method "git-p4 branches" uses. Does that make sense? I think I understand your point and it may make sense. Currently, "self.knownBranches" is the list used during import from P4. The idea behind making this list different from "self.p4BranchesInGit" might have been to allow stop following a given branch by removing its definition from P4. Of course, if you already imported it earlier and there is a commit into it I think it makes sense to import the new commit instead of ignoring it as it is being done now. With that said, I think it would be a good idea to somehow merge the two lists together. But, as Pete already pointed out, the branch code is too complex as it is now and it needs a deep review. So it might make sense to include this feature as part of that review. The patch I directed you to ([1]) allows you to create a list of branch-origin to branch-destination pairs independent of "p4 branches" output. So you should be able to use this as a workaround for now. > Thanks, > > Mike Regards, Vitor [1] http://article.gmane.org/gmane.comp.version-control.git/168001 -- 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