On Fri, Nov 5, 2010 at 10:03, Fabio Maulo <[email protected]> wrote:

> I did ;)
> I have a full history updated, the fork in bitbukect came from my files
> uploaded in sky-drive.
> We are ready to make the move at any moment but that is not the real
> matter... as you said the matter is what will happen after make the move and
> I'm scared by big pull requests instead little patches, pull requests
> without follow some rules (related issue ticket, and not only superficial
> tests).
> I'm scared about the management and the future quality...
>
>
    I don't understand the fear that git or another DVCS would make managing
the contribution review/QA process more difficult. Switching to a git does
not mean anarchy. Pull requests are not inherently larger or smaller than
patches, nor are they more difficult to review. People could currently
submit large patches or patches that include code from other people, etc...
so I don't understand those points.

   Like you said, pull requests would benefit from rules or guidelines about
their size and scope (such as one feature, one issue ticket, etc.), but this
is no different then the rules you'd have for patches. Even if a pull
request is large, the fact that it usually contains a full history of
changes broken up into individual commits with information about the author
of that commit, makes a large pull request a lot easier to review than a
large patch.

   As Oren mentioned, if large pull requests are unacceptable, then you
simply make the submitter resubmit his changes as  a series of smaller pull
requests in the same way that you would make them re-submit a large patch
into a series of smaller, more focused patches.

  Git is a very flexible tool that supports many different types of
workflows. Each project can decide how they want to manage the process. You
could have virtually the same process that is used for SVN (even use git
format-patch and git apply to do things with patches (although this would
defeat much of the purpose/advantages of switching).

 I think most of the people who are now using git have had years experience
with subversion prior to switching to git. After switching to git, I don't
recall ever feeling like I wished I still had SVN because it could do X, Y,
or Z better for any particular task. Once over the learning curve, git
becomes an incredibly liberating tool, giving you complete control of your
project's history, branches, changes, and merges. This power is hard to
explain until you actually have used it in real-world situations. Needless
to say, going back to SVN would feel incredibly constraining, and there
would be a lot about git I would miss.


  I have never used HG, but I would assume a lot of this would also apply to
it.

Reply via email to