All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pete Wyckoff <pw@padd.com>
To: Luke Diamand <luke@diamand.org>
Cc: Vitor Antunes <vitor.hda@gmail.com>, git@vger.kernel.org
Subject: Re: [PATCHv2 0/4] git-p4: small fixes to branches and labels; tests
Date: Wed, 30 Nov 2011 17:58:13 -0500	[thread overview]
Message-ID: <20111130225813.GA11544@arf.padd.com> (raw)
In-Reply-To: <4ED6809A.9020703@diamand.org>

luke@diamand.org wrote on Wed, 30 Nov 2011 19:14 +0000:
> On 30/11/11 14:55, Vitor Antunes wrote:
> >Luke Diamand<luke<at>  diamand.org>  writes:
> >
> >>In adding the test case for labels I also found and fixed a few other
> >>small bugs in the label handling:
> >>
> >>  - labels missing a description or "EOT" in their text cause problems;
> >>  - labels without an owner cause problems.
> >>
> >>I also noticed, but did not fix, that you can't have more than one label
> >>per commit (the others are silently dropped) and the documentation for
> >>branch import could be improved. I've added a (failing) test case for
> >>the multiple label problem.

I was hanging onto your v1, and made a comment on the v1's 3/4
that perhaps you missed.  Also acked the entire thing.  I can
resend if my mailer ate it.

Don't expect Junio to pick it up until after 1.7.8 goes out.

> >Hi Luke,
> >
> >Seeing that you have some experience using labels, could I kindly ask you to
> >include some description of it in git-p4.txt?
> 
> OK, if you can help me understand what's going on...
> 
> The label-detection bug that I've described, on further
> investigation, looks to be a fundamental limitation.
> 
> With perforce, I can check out the head revision, and then tag just
> a single file. If I then check out on that tag, I get just that one
> file.
> 
> I think I can't do that with git; certainly fast-import can't do it.

This is another fundamental disconnect between p4 and git.
Reading

http://www.perforce.com/perforce/doc.current/manuals/p4guide/07_labels.html

it is clear that labels are supposed to be used exactly where
tags cannot:  to specify a collection of files as they existed
at _different_ points in the commit history.

Thus I think supporting labels is kind of pointless.  But in the
restricted use case that perforce docs tell us not to do, namely
using labels to identify change numbers, git can reflect that
with tags.

> So the code in git-p4 that is checking the file vs label counts
> (git-p4 around line 1496) is actually trying to say "this label
> can't be imported into git".
> 
> If my understanding is correct, I can then fix my test and update
> the docs and the code to explain this.

Yeah.  It's just a big restriction on how labels get imported.
A better error message and some docs would be useful.

> As an aside, git-p4.txt currently has quite good information on the
> config variables, but nothing on the command line variables.
> Possibly that should be fixed.

Recently, I wrote an asciidoc-style document for git-p4, and
tried to find all the options on all the commands.  There's a lot
more than I ever knew about.  :)  I'll take another pass
through it then send it out for review.  Maybe we can get rid
of the old git-p4.txt then and work on improving a more
structured document.

		-- Pete

  parent reply	other threads:[~2011-11-30 22:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-30  9:03 [PATCHv2 0/4] git-p4: small fixes to branches and labels; tests Luke Diamand
2011-11-30  9:03 ` [PATCHv2 1/4] git-p4: handle p4 branches and labels containing shell chars Luke Diamand
2011-11-30  9:03 ` [PATCHv2 2/4] git-p4: cope with labels with empty descriptions Luke Diamand
2011-11-30  9:03 ` [PATCHv2 3/4] git-p4: importing labels should cope with missing owner Luke Diamand
2011-11-30  9:03 ` [PATCHv2 4/4] git-p4: add test for p4 labels Luke Diamand
2011-11-30 14:55 ` [PATCHv2 0/4] git-p4: small fixes to branches and labels; tests Vitor Antunes
2011-11-30 19:14   ` Luke Diamand
2011-11-30 19:44     ` Vitor Antunes
2011-11-30 22:58     ` Pete Wyckoff [this message]
2011-11-30 23:00       ` Pete Wyckoff
2011-12-01  0:37         ` Vitor Antunes
2011-12-04 16:07           ` Pete Wyckoff
2011-12-01  8:31         ` Luke Diamand
2011-12-01  0:33       ` Vitor Antunes
2011-12-01  4:02         ` Pete Wyckoff
     [not found]           ` <CAOpHH-UMdLpCPx1+D2dtQJs+=t1+0U2srKfTwBi-TEF4F7EDyw@mail.gmail.com>
2011-12-01 21:59             ` Vitor Antunes
2011-12-02  8:49               ` 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=20111130225813.GA11544@arf.padd.com \
    --to=pw@padd.com \
    --cc=git@vger.kernel.org \
    --cc=luke@diamand.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.