On Fri, 2 Jun 2006 15:09:45 +0200
"Alex Riesen" <raa.lkml@xxxxxxxxx> wrote:
> BTW, can I suggest to import the _currently_ synced state?
>
> The reason is that because of the way how Perforce is done
> its working directories (views, aka clients) are often a
> horrible mix of occasionally synced files to some random
> versions. No one actually uses "p4 sync" for whole project here
> where I work, because it is absolutely useless at this level
> (updated files have abolutely no relevance at head revision,
> which is what you get by syncing without strictly specifying
> a revision). So a working state is stitched together from
> a lot of "mappings": perforce path to local path -> revision.
> That state can be actually worked on (up until you have
> to commit something, that is not possible except on head).
Hey Alex,
I'd happily change the script to accommodate your needs if it's at all
reasonable. As you've no doubt gathered, the script is currently very
branch centric. It needs a mapping view from each p4 branch into the
local git directory. Then it does a sync //p4/mapping@{revision} for
each revision along each mapped branch and commits it into git.
Note that it never syncs specifically to head, it explicitly asks for
each revision along the branch and tt doesn't know anything about your
working state, it can only import commits.
Are you looking for the ability to create a single git branch which has
the history of the combined view of your stitched together client mappings
rather than the independent branches held by the server?
Sean
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html