I've been looking at fixing the --detect-labels flag in git-p4. I'm now
thinking that the current way it's done is just all wrong.
The current code has a few annoying bugs which I mostly have fixes for:
- it only works when there is no more than one label per changelist;
- if the count of files in the p4 label doesn't match the count of files
in the p4 changelist then the label gets dropped (by design);
- git-p4 rebase ignores --detect-labels
- it imports all the label/file mappings each time (I haven't fixed this
yet)
However, the thing that's more annoying is that it only imports labels
when importing the changelist they are pointing at.
So, for example, if you do something like this:
p4 edit; p4 submit
p4 tag TAG1
git-p4 rebase
p4 tag TAG2
git-p4 rebase
then TAG1 will be detected, but TAG2 won't.
This is a particular nuisance for me, as I just have git-p4 running all
the time eating commits, so there's no scope for a human to delay the
git-p4 and pickup the label.
I think what's needed is to do something completely different.
This is speculation at the moment, and I'd welcome comments before I
start hacking.
There will be a new _command_, import-labels. This command will find all
the labels that git knows about, and the labels that p4 knows about, and
then do the obvious diff. It will then create tags as needed directly
(i.e. not using fast-import).
It will unfortunately need to hunt through the revision history looking
for the git hash <h> that matches p4 changelist <c>. This could get
quite slow, although no worse than O(n).
Something like:
p4 edit; p4 submit
p4 tag TAG1
git-p4 rebase
git-p4 import-labels
p4 tag TAG2
git-p4 import-labels
I'm going to try to work up a patch with some test cases but in the
meantime if anyone thinks I've missed something, please let me know.
Thanks
Luke
--
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