Re: Offer of help with move to git
On 24 August 2015 at 09:40, Tom Tromey wrote: > Eric> In the mean time, I'm enclosing a contributor map that will need to be > Eric> filled in whoever does the conversion. The right sides should become > Eric> full names and preferred email addresses. > > It's probably worth starting with the map I used when converting gdb. > There is a lot of overlap between the sets of contributors. > > See the file "Total-merged-user-map" here: > > https://github.com/tromey/gdb-git-migration The process used by that conversion was overly simplistic. It resulted in git attributions like: commit 90e2fa9c54de04a52fd5980238a1087b9291750f Author: Andrew Cagney Date: Mon May 11 21:21:47 2009 + 2009-05-11 Andrew Cagney * MAINTAINERS: Orphan ppc. commit 8e70166dc52cf82a61e0a414f364f3ff7c45dfa7 Author: Andrew Cagney Date: Tue Aug 9 16:35:45 2005 + 2005-08-09 Andrew Cagney * linux-nat.h (linux_proc_xfer_memory): Change type of "myaddr" a "gdb_byte" pointer. which are bordering on offensive (You'll note I have a personal assignment on file). Using @gcc; or, as ESR suggested, a linear map would certainly be better (but even then there's no guarantee that developers weren't deliberately using two addresses. For instance, one to identify paid, and one to identify voluntary work). Andrew
Re: Repository for the conversion machinery
On 28 August 2015 at 13:24, Jeff Law wrote: > cagney = Andrew Cagney cag...@gnu.org?
Re: Repository for the conversion machinery
On 15 September 2015 at 21:36, Frank Ch. Eigler wrote: > >>> cagney = Andrew Cagney >> cag...@gnu.org? > > Good point. The email identities of people change over time; forcing > a single arbitrary one to label all contributions is at best imprecise > and at worse a miscrediting. (This is one way in which the impersonal > use...@gcc.gnu.org aliases work better.) It strikes me as the least bad and quickest option. It also best reflects how CVS and SVN deal with identities. (Would it go hand-in-hand with a git commit hook ensuring that future commits preserve this convention? Just asking) Two other options come to mind: - preserve history That is create a repo that gives the appearance that we had git all along. It would be high quality, useful, and most git-like; and also one hell of a lot of work :-/ For instance, it might include commits by: Andrew Cagney Andrew Cagney Andrew Cagney Andrew Cagney While they are all the same individual, they reflect different points in time. If we'd had git all along then this, I believe, is what the repository would have contained. There would certainly be no expectation that 20 year old addresses were still valid, or that they need "fixing". - rewrite history - use some totally arbitrary, and quickly outdated, internet identity To me this makes the least sense. If I change my name/contact do I have the repo rewritten with that new information? Am I forever required to use an arbitrarily assigned identity? Hardly.
