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. 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? Thanks, Mike On Tue, Apr 19, 2011 at 8:31 PM, Pete Wyckoff <pw@xxxxxxxx> wrote: > > michael.horowitz@xxxxxxxx wrote on Mon, 18 Apr 2011 23:57 -0400: > > OK, after some digging, I think I have figured out what is going on, > > but I am not sure how to fix it, at least not safely. > > > > There seem to be several different ways of detecting branches, and I > > am not exactly sure what they are all used for, or why there are so > > many, but the core of the issue I am having is that in importChanges > > when it calls splitFilesIntoBranches, it assumes "self.knownBranches" > > has all the branches, even though it already has the branches from > > "self.p4BranchesInGit". The exact reason I don't know, but the > > results is splitFilesIntoBranches returns an empty array, and so when > > the code loops over it, it silently does nothing. > > I too am confused by the branch handling in git-p4, and have never > used it. I'd love to rip it all out, along with the confusion, > but know that some people use it with success. > > At least it all could use some overhaul and documentation so we > can see what's going on. > > > The first fix that would be helpful is to at least report an error if > > it can't find the branches, rather than silently doing nothing. I am > > not exactly sure why it needs to look in "self.knownBranches", so I > > don't know what the error should report, maybe the error should be > > reported earlier? > > > > The other issue is how "self.knownBranches" seems to be populated. It > > looks like form my code path, which decides to "Import from/to > > multiple branches", it tries to detect branches by using "p4 > > branches". Again, this is odd, since I can see it already has the > > names of the branches from "self.p4BranchesInGit". I am not familiar > > enough with the code (and figuring out Python as I go along) to know > > why. The problem with using "p4 branches" is those aren't really > > branches, they are aliases to a merge command (integrate in p4 lingo) > > which stores the from and to branch. The branch in Perforce is really > > just a directory. Interestingly enough, it seems this logic also > > attempts to detect new branches and automatically import them, but > > ironically this doesn't actually work for me. > > This is my understanding of "p4 branch" as well. At our site, > the list of p4 branches does not at all correspond to what we > think of as code development branches in git. Again, maybe > others use it differently? > > We do maintain p4 view lists, but that is kept out-of-band, not > in any p4 mechanism. These map friendlier short names to a list > of directories in p4 and how to assemble those into a workspace. > > > So, the crux of the problem is that "p4 branches" are not necessary to > > have at all. The reason this suddenly stopped working for me is that > > someone had created one of these branch definitions and I didn't know, > > so it was accidentally working all this time, but only for 2 of the > > branches. Then the person removed the definition, and it stopped > > working. Now the workaround is to go and create these things for > > every branch, but considering these are unnecessary and cumbersome to > > create, and the code seems to be able to find the branches already > > from the "self.p4BranchesInGit" anyway, I would like to remove the > > dependency on that logic. > > > > Now, I could go ahead and hack something that does things differently, > > but since I don't really know the intention of these structures or how > > it might impact elsewhere in the code, I could use some guidance from > > someone who knows this code well. > > Vitor uses branches, and his patch that he recommends might be > the work-around you are looking for. > > I thought all this branch code was opt-in, so if you fail to say > "--detect-branches", it won't try to auto-detect anything. > > But there is maybe another use case in here, which is to > import multiple directories of the depot into _different_ > refs/remotes/p4/<branch>. (I've only ever done one at a > time, and into the default p4/master.) And now that you > have multiple git-p4 branches, you're stuck with them due to the > login in p4BranchesInGit(). That feature should be handled > independently of the "p4 branch" auto-detection one. > > The branch handling needs rework. You might help by describing > how you want it to work and we can see if this is the same as how > Vitor uses branches. > > -- Pete -- 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