git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git-p4 issue

From
PWPete Wyckoff <pw@padd.com>
Date
Apr 20, 2011, 00:31 UTC
Message-ID
<20110420003100.GC28768@arf.padd.com>
In-Reply-To
<BANLkTinJecAsXt+5JzscFYEx_ez2q9DioQ@mail.gmail.com>
michael.horowitz@ieee.org wrote on Mon, 18 Apr 2011 23:57 -0400:
Show 11 quoted lines
> 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.

Show 18 quoted lines
> 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.

Show 15 quoted lines
> 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
Previous: Vitor AntunesNext: Michael Horowitz
Message 8 of 13 in “git-p4 issue”
  1. Michael HorowitzApr 15, 2011
  2. Tor Arvid LundApr 15, 2011
  3. Michael HorowitzApr 15, 2011
  4. Pete WyckoffApr 16, 2011
  5. Vitor AntunesApr 18, 2011
  6. Michael HorowitzApr 19, 2011
  7. Vitor AntunesApr 19, 2011
  8. Pete WyckoffApr 20, 2011
  9. Michael HorowitzApr 20, 2011
  10. Vitor AntunesApr 20, 2011
  11. Michael HorowitzMay 6, 2011
  12. Vitor AntunesMay 13, 2011
  13. Michael HorowitzDec 17, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.