www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <santiago.g...@gmail.com>
Subject Re: Blog post on Gerrit (GIT review tool)
Date Tue, 15 Feb 2011 17:48:29 GMT
On Tue, Feb 15, 2011 at 4:47 PM, Steve Loughran <stevel@apache.org> wrote:

> On 10/02/11 20:42, Santiago Gala wrote:
>
>  My opinion is the gerrit is one of the best ways to get low entry barriers
>> and open collaboration, around a repository. I have had a number of
>> commits
>> into cyanogenmod, all via gerrit. I signed up a CLA via web, keep my own
>> repository and use "repo upload" for automatic push to gerrit.
>>
>
> I've not used gerrit; no experience.
>
>
>
>  OTOH I don't think git can be used "much the same" as svn. I would
>> recommend
>> any people that has not used git deeply to avoid comparing it with
>> subversion until they have used it deeply during, say, one year. By using
>> I
>> mean at least:
>> - one small standalone project, with several ongoing branches and changes
>> getting applied in subsets of those, during a significant time.
>> - one long lived branch of a small size collective project, where the main
>> developer takes some of our patches and we take patches from him and from
>> other developers, some of which can later be merged into the main line (
>> for
>> instance I am stariing to work like this with bottle.py again for this
>> year's course: https://github.com/sgala/bottle/network   )
>> - "casual" contributions to a big  project, such as my small patches and
>> translations for cyanogenmod ( see for example
>> http://review.cyanogenmod.com/#dashboard,225 )
>>
>
> I've been using it on some multi machine stuff, but even there, I'm still
> learning, and as we move to some team stuff at work it's going to be hard
> keeping a bunch of prima donna's under control "It's in MY repository" they
> will say when I corner them and ask why their code bears no resemblance to
> what pretends to be a normative specification.
>
> I imagine Hudson/Jenkins will need to be ruthless here and
>
>  -require everyone to push their changes, even personal ones, to a remote
> repository that is open to others for reading. Yes, that means no rebasing,
> but tough.
>

rebasing could be allowed if the "personal" branched are socially taken as a
showcase. The contract would be that when someone is interested in a commit
from a personal branch, she would ask the owner to push it to an integration
branch, rebasing if needed, and everybody takes ot from there.


>  -have hudson/jenkins set up to build and test the branches of these
> personal repos, as well as the shared ones.
>  -worry a lot about how to merge things. Let people push their branches up
> but have an Integration branch that people are expected to follow and merge
> with.
>
>
An interesting query, that I'm doing more and more as I try to learn what
goes where in the set of android repositories and branches, is something
like:

git log --stat -p ^local-branch remote-branch

i.e., a log of the commits from "remote-branch" that I don't have in my
local branch. Frequently there are also non-empty "git log --stat -p
^remote-branch local-branch", and zipping together both branches is what
integration is about.

quite often, even when comparing different branches of kernels from
different (android) devices, the logs of diverging history are quite small,
~10-20 commits.

The same kind of queries can give ideas such as:
what is there in a branch that is not in last release? what commits am I
missing from the stable branch?...


>  I'm not sure which are the current infrastructure requirements, but I
>> think
>> that no svn-like git workflow will be a significant advantage about plain
>> old svn.
>>
>
> I think it does some things that are good, some things that are danger
>
>  -good: everyone gets SCM. It doesn't have that "committer",
> "non-committer" split any more, as everyone is equal.
>
>
One side effect is that patches come with proper metadata: who, when, log
messages, ..., as they are commits from a remote repository.


>  -good: ease of switching branches and working offline encourages people to
> have a separate branch for every issue, and integration branches that merge
> things.
>
>
something I do frequently in git is: cherry pick a small number of commits
from my "dirty" wotking branch, sometimes splitting some, sometimes joining
them, into a coherent, purposeful set of patches. Issue a pull request or
merge directly this small set somewhere, and cleanup my work branch to
contain the rest of my work-queue.

The main difference I see re: svn or cvs is that commits are easy to do and
redo, so I'm not lazy when it comes to committing small sets of changes, or
to get things perfect at first try.


>  -danger: ease of diverging your code from the rest of the teams.
>
>
This danger exists, but is similar to the danger of keeing big modified
working copies in centralised SCM, be it because you are offline or because
you don't feel sure this is the right thing to do.


> I can't say what makes a good workflow here, I'm just starting out to lay
> one down. I know what doesn't work, but not what does.
>
>
Agreed.


> Now, in the Hadoop group there are some interesting issues coming up
>
>  -Y! want to merge their changes (on Github?) into hadoop-core,
> hadoop-hdfs, hadoop-mapred. Now, if the apache projects were also in git, I
> think this would be easier to do. But I worry about moving big projects to
> Git right now, not without more experience of using it in Apache.
>
>
I'd do a git-svn repository from the official tree and then try to rebase
their changes on top of it, and commit those to svn using git-svn once the
history looks right. A git repository can contain any number of roots, so
the same repository can hold the git-svn branches and Y! ones together,
making it relatively simple to do diffs or to cherry-pick commits.


> -some of the undermaintained contributions are going to be put in the
> attic, but some ought to go into incubation, such as MRUnit, a unit testing
> tool. It would be an interesting experiment to host that project's code in
> Git, to see how well it works, to see what the ASF+git collaboration
> processes should become.
>
> -steve
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message