[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: Development - an outsider’s perspective
Re: AW: Development - an outsider’s perspective
Tue, 3 Jan 2023 19:17:12 +0000
thanks for your detailed answer!
> I converted the gnubg and gnubg-nn subdirectories in separate git repos.
> This seemed more natural to have gnubg at the root of its repo.
Yes, separate repositories might also make sense, I don't know what's better.
Having both in one repository (for now), would also allow to see a combined
And once everything is git, we can move/rename folders without losing that
But if those two modules are completely separate and we never want to share
code between, then two repositories are more suited.
> FWIW, what I did was :
> rsync -av rsync://cvs.savannah.gnu.org/sources/gnubg/ gnubg-full-cvs/
> cvsconvert -v -A authormap gnubg-full-cvs/gnubg
> Then, in the created gnubg-full-cvs-gnubg-nn-git directory :
> git gc --aggressive
> git checkout master
My commands for cvs2git:
rsync -av rsync://cvs.savannah.gnu.org/sources/gnubg .
cvs2git --blobfile=./git-blob.dat --dumpfile=./git-dump.dat --keep-cvsignore
--retain-conflicting-attic-files --encoding=ascii --encoding=utf8
--encoding=utf16 --fallback-encoding=utf8 ./gnubg
mdkir gnubg-cvs2git && cd gnubg-cvs2git && git init
cat ../git-blob.dat ../git-dump.dat | git fast-import
> > Another open question: As “author” git would always use the user
> > handle of the CVS committer. Do we want to have full name and email
> > address instead? That’s possible if those tools would be fed with a
> > file mapping those user handles (like “plm”) to full name / email
> > As with CVS committer and author often were different people this
> > might not be wanted though.
> As the command I gave earlier show, I think it would be preferable to
> have real names and adresses rather than savannah handles, but I don't
> understand your last sentence. I think most of the time the committer
> was the author of the change ; the latter may sometimes have been an
> occasionnal contributor who may or not have been credited in the
> comment, but using names and adresses would allow to do it more
> systematically in the future, wouldn't it ?
I'm not sure I understand you correctly. Once using git, we would use full name
/ email address anyway. This discussion is only about the commit history until
now, not the future git commits.
> What puzzles me most in your suggestions is this :
> > So my suggestion is to first move the repository to GitHub.
> Moving to gitub doesn't seem especially urgent to me. First task would
> be ensure that the conversion to a git repo is done right. Your report
> shows some uncertainties in this regard.
That was poor wording on my side. With "first" I meant this should be done
before my other suggestions are tackled, like refactoring of the code base.
Renaming of files is much better handled in git than in CVS, the history and
"git blame" can deal with that.
I completely agree with you that first we need a proper export to git and
should give it enough time until we are certain of it.
Another detail: when I took another look at the two exports I did, I noticed a
different number of commits (7285 vs 7532)
The reason is that sometimes one commit in cvs2git is two when using
cvs2git also omits the CVS comments like
* $Id: matchequity.c,v 1.106 2022/02/19 21:52:48 plm Exp $
We don't need them anymore, so that should be ok.
> Then I would find it natural to clone it to savannah (and, I suppose,
> have the cvs repository made unavailable or at least read-only). That
> would already allow anyone interested to easily clone the repository
> locally, to github, or elsewhere.
> Only then could it be envisaged to move the reference origin (and
> possibly everything else, bug reporting, binaries distribution, mailing
> list) elsewhere.
Personally I would skip the step via savannah. But yes, moving a git repository
from savannah to somewhere else is very simple, quick and wouldn't change
> I must be out of touch with the modern open source ecosystem but
> > Some developers care about their contribution statistics on GitHub
> came as a surprise to me.
> A significant enough contribution to have one's name in a documentation,
> readme, changelog? Great! Bug reports and occasionnal suggestions for
> something I use? Obviously! But going in priority where there are
> counters to inflate ???
I have only anecdotal data, but many people in HR hiring software engineers ask
for your GitHub handle.
Even when applicants are not asked, I have seen many of them giving the URL to
their account in their CV.
It's not only about numbers, it's also an easy way to check the quality of
And yes, some people also inflate those numbers and brag about it, just check
Maybe we should stop discussing contribution statistics here, but for gnubg you
would definitely win 2022 :)