lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Woodward <>
Subject Re: Source Control
Date Sun, 28 Oct 2012 15:09:47 GMT
We have an official git mirror for the project, though -  So if
people want to use git to collaborate, they can clone that repository and create branches

I much prefer git to svn - I use staged adds, rebases and stashes all the time - but anyone
can currently use that by setting up a git-svn bridge.  I'm not sure we gain anything except
headaches by migrating the entire repo.

On 28 Oct 2012, at 12:38, Erick Erickson wrote:

> I don't have stropng feelings either way. If it would allow better collaboration
> branch merging, etc., then sure.
> I'm assuming we'd be able to do pre/post move diffs, right?.
> What about reformatting at that point? It'd be one of the few times when
> we would, I think, have all the code in the repository at once. Not insisting
> on this, I've actually grown used to avoiding re-formatting too much. But it'd
> be one of the least painful moments to reformat. Not painless, mind, but....
> Erick
> On Sun, Oct 28, 2012 at 8:04 AM, Shai Erera <> wrote:
>> What I wish we could do is to truly collaborate on these branches. For
>> instance, when we create a feature branch today (following an issue), then
>> people are free to commit changes to the branch, without worrying about
>> breaking the main branch or nightly builds. When it's time, the changes will
>> be merged to the main branch. But what we lack today is true collaboration
>> -- allow all those involved to commit changes to the branch, thereby
>> creating a healthier collaboration atmosphere. When the main people involved
>> are committers, this is not so felt, but if the main people involved are
>> non-committers, it's not so fun (to them mostly).
>> Yet, I don't think that it can work otherwise, from the legal side. When
>> people post patches in JIRA, there's a little checkbox that they need to
>> tick, granting the ASF rights for this code. There's no checkbox to tick
>> when changes are committed (well, since committers sign an agreement with
>> the ASF about code rights, there's like a virtual tiny checkbox that they
>> tick at commit time).
>> So, and without me being a lawyer or anything (!), how would that work if we
>> move to GIT? If we don't allow other people to commit to "feature branches",
>> because there might be code licensing issues, what will be the advantage of
>> moving to GIT?
>> I'm asking because IMO if we cannot do that (let non-committers commit to
>> feature branches), there's no strong reason to move away from SVN. We all
>> know it, feel comfortable with it, and what's most important -- it does the
>> job that we need.
>> Shai
>> But throughout the development of a feature, it'd be great if we can let all
>> those involved to commit freely to the branch, without going through
>> patches. Is that possible with our current SVN setup (or can we modify it)?
>> Is that
>> On Sun, Oct 28, 2012 at 1:24 PM, Michael Wechner <>
>> wrote:
>>> Am 28.10.12 10:57, schrieb Robert Muir:
>>>> On Sun, Oct 28, 2012 at 2:59 AM, Michael Wechner
>>>> <>  wrote:
>>>>> I also had/have quite some trouble to get used to the git commandline,
>>>>> although or maybe because I used SVN commandline for many years, but
>>>>> am
>>>>> very glad now to be using git on other projects, because in particular
>>>>> the
>>>>> process in being able to do feature based branches with git helps so
>>>>> much,
>>>>> that I think it's definitely worth the price.
>>>> There's no one on this planet that can convince me git is technically
>>>> better.
>>> I am not talking about "technically better" (or maybe I misunderstand this
>>> term), but
>>> I am talking about "process". With git I can do the following:
>>> - Basically for every change (even in case it might just be a typo inside
>>> documentation) I am creating a branch (which I can a "feature" branch)
>>> - I can share these branches easily with other people even if they don't
>>> have commit/push access to the master branch and hence collaborate
>>> - I can merge branches easily and in particular merge the master branch
>>> into my feature branches, and hence keep my feature branches in sync, which
>>> greatly simplies merging later on into the master branch
>>> - I can commit stuff without having to be online, which is great when
>>> doing several steps on the code, e.g.
>>>     - Commit one: Formatting changes
>>>     - Commit two: Functional changes
>>> - Because of the above I can use a RTC (ReviewThenCommit) process, because
>>> "others" can commit to feature branches, where I can review the code changes
>>> and after successful review commit/push to the master branch.
>>> With SVN I couldn't do this that easily and because it wasn't easy, I
>>> didn't do it. But git allowed me/us to change the process and for me
>>> personally that is great.
>>> I think the question is what process do you want and what tool does make
>>> this process simple?
>>> Maybe before argueing SVN versus git you should specify how you want to
>>> collaborate and also specify requirements (as for example you point ou below
>>> about speed). Once you have a clear picture about this, then consider the
>>> various tools which exist.
>>> HTH
>>> Michael
>>>> I've used git on projects before. Its not that i have trouble getting
>>>> used to it, its command line is genuinely horrible.
>>>> And svn is absurdly fast for me:
>>>> rmuir@beast:~/workspace$ time svn co
>>>> real    0m23.454s
>>>> user    0m5.712s
>>>> sys     0m3.232s
>>>> The speed of my internet connection makes git obselete.
>>>> But if other people really like it, i won't stand in the way.
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message