This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Issue Tracker Used? Git migration checklist.


> We're talking about a shared repository, and the defaults for git init
> --shared include receive.denyNonFastForwards.

--shared is what's known as an option, not the default.

> Please assume that
> overseers are perfectly competent at administering shared git
> repositories; we have various examples including glibc here.

I tend to assume nothing. Especially when CVS is in use and only a
minority seem to care.

>> Having a second staging repo is neither here nor there

Fixed.

> The thing I dislike most about git is how its advocates try to push
> particular processes on everyone (the tool itself works fine with many
> different processes).

You've mistaken me for a git advocate. Use mercurial for all I care.

>  A tool change shouldn't involve any process changes at all.

It's a process change (more robust, efficient, powerful) that I'm
interested in, the tool simply facilitates that.

>  If you want to be constructive, concentrate on actual development
> of patches (scripts, hooks, documentation etc.) for the steps I listed to
> allow everyone to work pretty much exactly as they currently do, but in a
> git environment.

I'll focus on writing patches for sure, once I can commit them to
git/hg/perforce/bazaar/darcs/etc

> The responsibility of people proposing a VCS transition is to show how to make existing process
> work with the proposed new VCS.

That would be you, in many list messages, no? I'm just stoking the
fire and proposing that the "movement" takes on some structure and
organisation.

> It's simply silly to propose changes to development processes without
> actually being an active developer of the affected projects.

I'm not so sure about that. Let me illustrate:

A while back I converted a community from SVN to git, combining their
old repositories histories into one, and left it at that. The result
was most satisfying, instantly a multitude of previously "I won't
touch that" contributors appeared and started engaging the core devs
and making progress together. It's liberating to a code base. Assuming
the people in charge of the code base are open to being liberal.
Binutils is a FSF project, right?

"great shame" is not constructive, nor the opposite, it's simply an
opinion based on a few decades experience. Treat it as such and ignore
it. Or not.

Fred.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]