This is the mail archive of the 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


> 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

> 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

> 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.


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