On Tue, Dec 20, 2011 at 1:47 AM, Pete Wyckoff <pw@xxxxxxxx> wrote: > But adding a new command to go back and look for _new_ labels > makes sense too. Finding the new ones isn't so bad, given that > p4 can just print them directly, and we keep them as tags in git. Now that you say that, it is now very difficult to detect branches on an already imported repository. Maybe the new command could also do that? In this case I would call it "git-p4 resync". > [...] > But isn't there a step in label detection that looks an awful lot > like branch point detection? You've got a label, which is a > bunch of files, not a p4 change number. Now you have to figure > out the change number so you can go hunt that down in the git > history. Vitor's take on this was to use git diff machinery to > find it, not trawling through the p4 change/filelog/describe > history, mainly because it's likely much faster to do it locally > in git. In labels this is easier and fast: p4 changes -m 1 @label_name Then we could diff the label against the changelist. If equal simply tag the commit, if different then we need to create a temporary branch to commit the changes and tag that instead. -- Vitor Antunes -- To unsubscribe from this list: 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