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

Re: git-p4 issue

From
Vitor Antunes <vitor.hda@gmail.com>
Date
Apr 20, 2011, 10:51 UTC
Message-ID
<loom.20110420T121500-4@post.gmane.org>
In-Reply-To
<BANLkTikYDR+bzJQGip9BFo-BSgsBqEcQjQ@mail.gmail.com>
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.

Show 8 quoted lines
> 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
Previous: Michael HorowitzNext: Michael Horowitz
Message 10 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.