git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Michael Horowitz <michael.horowitz@ieee.org>
To: Pete Wyckoff <pw@padd.com>
Cc: Tor Arvid Lund <torarvid@gmail.com>, git@vger.kernel.org
Subject: Re: git-p4 issue
Date: Tue, 19 Apr 2011 22:40:40 -0400	[thread overview]
Message-ID: <BANLkTikYDR+bzJQGip9BFo-BSgsBqEcQjQ@mail.gmail.com> (raw)
In-Reply-To: <20110420003100.GC28768@arf.padd.com>

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

  reply	other threads:[~2011-04-20  2:40 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-15  3:00 git-p4 issue Michael Horowitz
2011-04-15 20:22 ` Tor Arvid Lund
2011-04-15 20:39   ` Michael Horowitz
2011-04-16 16:01     ` Pete Wyckoff
2011-04-18 12:59       ` Vitor Antunes
2011-04-19  3:57     ` Michael Horowitz
2011-04-19  9:59       ` Vitor Antunes
2011-04-20  0:31       ` Pete Wyckoff
2011-04-20  2:40         ` Michael Horowitz [this message]
2011-04-20 10:51           ` Vitor Antunes
2011-05-06 20:16           ` Michael Horowitz
2011-05-13 14:31             ` Vitor Antunes
2011-12-17  5:52               ` Michael Horowitz
  -- strict thread matches above, loose matches on Subject: below --
2023-03-16 17:28 Brent
     [not found] <AANLkTikXHJqmzZDv6NhujHqjUFva-uCRB3td306vi=WX@mail.gmail.com>
     [not found] ` <AANLkTi=b60kqd6fRXzf39BBepLOeA3ts6EN3AuY0iAp4@mail.gmail.com>
2011-02-24 21:12   ` Michael Horowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BANLkTikYDR+bzJQGip9BFo-BSgsBqEcQjQ@mail.gmail.com \
    --to=michael.horowitz@ieee.org \
    --cc=git@vger.kernel.org \
    --cc=pw@padd.com \
    --cc=torarvid@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).