From: Luke Diamand <luke@diamand.org>
To: git@vger.kernel.org
Cc: Pete Wyckoff <pw@padd.com>, Vitor Antunes <vitor.hda@gmail.com>,
Luke Diamand <luked@diamand.org>
Subject: [RFC/PATCHv1] git-p4: label import: first draft
Date: Sat, 17 Mar 2012 10:44:40 +0000 [thread overview]
Message-ID: <1331981081-25598-1-git-send-email-luke@diamand.org> (raw)
From: Luke Diamand <luked@diamand.org>
The existing label import code (--detect-labels) looks at each
commit being imported, and then checks for labels at that commit.
This doesn't work in the real world though because labels applied
in changelists that have already been imported are ignored. e.g.:
% p4 submit -d 'a change'
% git-p4 rebase
% p4 tag -l TAG ...
% git-p4 sync --detect-labels
TAG will never be detected.
Additionally the existing label detection has some annoying shortcomings
* It gets the list of files at each label every time git-p4 is run,
which on a large repo with many labels is a problem. The new
scheme only pays this price the first time a label is seen.
* It only imports a label if the number of files in the label matches
the number of files in the repo at the highest revision found. This
is to cope with the way that git tags and p4 labels cannot be
directly mapped to each other. In practice this is not a useful rule,
for example if the p4 tag was applied across a wider area of the tree
than just the part being imported by git-p4, then the tag is ignored.
The new code just checks that there are no diffs between the label
and the p4 changelist to be used.
The new code gets the lists of git tags and p4 labels, and then creates
git tags for all the missing p4 labels. Any labels that could not be
imported are added to an ignore-list so that they are not repeatedly
queried. A regular expression can be specified to limit the p4 label
patterns that will be imported.
Limitations:
* The code currently doesn't know anything about branch-based setups, and
has 'p4/master' hardcoded as the branch to search for git revisions. I
haven't yet thought about the best way to handle this, which is why this
is only an RFC at this stage. I would welcome suggestions on the best way
to deal with this.
* The code uses "git log --grep" to get from a p4 changelist to a git
commit. This means it doesn't work on older versions of git, e.g.
git 1.7.0. Arguably it should use gitCommitByP4Change().
* The unit tests could be expanded.
Thanks,
Luke
Luke Diamand (1):
git-p4: improved import of labels from p4
Documentation/git-p4.txt | 15 +++-
contrib/fast-import/git-p4 | 152 +++++++++++++++++++++++++++++++---------
t/t9811-git-p4-label-import.sh | 116 ++++++++++++++++++++++++++++++
3 files changed, 248 insertions(+), 35 deletions(-)
create mode 100755 t/t9811-git-p4-label-import.sh
--
1.7.10.rc0.158.gd9e55
next reply other threads:[~2012-03-17 10:44 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-17 10:44 Luke Diamand [this message]
2012-03-17 10:44 ` [RFC/PATCHv1] git-p4: improved import of labels from p4 Luke Diamand
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1331981081-25598-1-git-send-email-luke@diamand.org \
--to=luke@diamand.org \
--cc=git@vger.kernel.org \
--cc=luked@diamand.org \
--cc=pw@padd.com \
--cc=vitor.hda@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.
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 NNTP newsgroup(s).