Re: RFD: fast-import is picky with author names (and maybe it should - but how much so?)
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- Nov 12, 2012, 22:47 UTC
- Message-ID
- <CAMP44s1gA1P-Lr1M=7RDRqFQmvQAtNnB+yAJfKC1gk3XUjbfCQ@mail.gmail.com>
- In-Reply-To
- <20121112214127.GA10531@sigill.intra.peff.net>
On Mon, Nov 12, 2012 at 10:41 PM, Jeff King <peff@peff.net> wrote:
Show 19 quoted lines
> On Sun, Nov 11, 2012 at 07:48:14PM +0100, Felipe Contreras wrote: > >> > 3. Exporters should not use it if they have any broken-down >> > representation at all. Even knowing that the first half is a human >> > name and the second half is something else would give it a better >> > shot at cleaning than fast-import would get. >> >> I'm not sure what you mean by this. If they have name and email, then >> sure, it's easy. > > But not as easy as just printing it. What if you have this: > > name="Peff <angle brackets> King" > email="<peff@peff.net>" > > Concatenating them does not produce a valid git author name. Sending the > concatenation through fast-import's cleanup function would lose > information (namely, the location of the boundary between name and > email).
Right. Unfortunately I'm not aware of any DSCM that does that.
> Similarly, one might have other structured data (e.g., CVS username) > where the structure is a useful hint, but some conversion to name+email > is still necessary.
CVS might be the only one that has such structured data. I think in subversion the username has no meaning. A 'felipec' subversion username is as bad as a mercurial 'felipec' username.
Cheers.
-- Felipe Contreras