Re: git-p4 issue

> Could you please search for the following set of patches in this mailing list?
>
> [PATCH v2 0/3] git-p4: Improve branch support
>
> I think I sent v2 twice somehow, so please make sure you pick the latest ;)
> In these patches I add the possibility to use a "git-p4.branchList"
> configuration to define the branches. The patch is still to be approved because
> most people in the mailing list do not use branch detection, but I use it daily
> and it is working in my side. Could you please test it?

> 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@padd.com> wrote:
>>
>> michael.horowitz@ieee.org 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
>