Re: git-p4 issue

[Vitor Antunes <vitor.hda@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.

> 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