lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shai Erera <>
Subject Re: The Old Git Discussion
Date Sat, 04 Jan 2014 06:15:17 GMT
> Also: if you fork today, you can
> have this workflow, I think.

This is how I worked on several Lucene issues in parallel, so it works ..
sort of. The problem is that while your github changes are public, none of
this appears in the Apache SVN after I committed the changes to Lucene
source. In fact, in order to commit I had to generate a patch from github,
apply to the SVN checkout and commit. SVN history had no records of
whatever interim commits I made on github.

I understand Michael's scenario and agree with Robert - if Apache allowed
write to a special directory under SVN, say[jira/sandbox] or something we
could have contributors creating their own sub-directories and committing
their changes. Then a committer would only need to "svn merge" that branch
with trunk.

In addition, I don't think Pull Requests contain any magic. They get stale
over time, nothing magically updates them to the latest trunk. The only
advantage a PR has over patch, from my experience, is that a PR means you
have things committed already, so you can use "git merge" to bring your
changes up to latest trunk. While with SVN, you can only use "svn up",
which doesn't do a good job at merging (as "svn merge" does).

I actually don't think GIT makes this usecase any easier to handle then say
if e.g. Michael had his own SVN repository somewhere (public) where he
committed his stuff and opened a JIRA issue (aka a Pull Request) and a
committer would issue an "svn merge" from his repo to Apache's. At least
from the little reading I've done on SVN, it's totally possible.

So I wonder if GIT really makes life easier, or is it maybe the github
infra that makes people think that if they used GIT(-hub), it would make
their life easier, since there's no equivalent free Subversion hosting site
(at least, I couldn't find one quickly on Google)?


On Sat, Jan 4, 2014 at 5:32 AM, Otis Gospodnetic <
> wrote:

> Hi,
> On Fri, Jan 3, 2014 at 2:42 PM, Michael Della Bitta <
>> wrote:
>> On Fri, Jan 3, 2014 at 2:03 PM, Erick Erickson <>wrote:
>>> If someone could outline, in concrete terms, the workflow that would
>>> make Git help make my life easier, or outline why staying with SVN is going
>>> to slow people down or turn people off, it would be a great help
>> I guess speaking as someone who wouldn't mind contributing here or there,
>> the current situation is pretty awkward. I'd have to post a patch to JIRA
>> and hope it got some attention and rolled in in time before trunk moved
>> along and the patch didn't work right anymore. And if that happens, there's
>> really no system for tracking what had happened; I'd have to start over
>> with a new patch.
>> That's a *lot* less compelling to me than the ability of creating my own
>> branch in a public arena, possibly collaborating with another person on a
>> change, and then issuing a pull request. Plus, there's a public record of
>> the work, and it's easy for another user to take up my changes without
>> having to find the patch in JIRA and run it themselves.
> 2 Qs from a Git noob:
> * PRs are a *Github* thing, not a Git thing, right?
> * Don't PRs suffer from the same problem as patches in JIRA - if nobody
> acts on them for a while they get stale?  Or is this where some Git magic
> comes in and a developer can very quickly and easily bring the patch in the
> PR up to date?
> Thanks,
> Otis
>> I'm not saying that Solr or Lucene's source control infrastructure has to
>> cater necessarily to someone like me or doom will happen, but I did want to
>> put forth this point of view.
>> Michael Della Bitta
>> Applications Developer
>> o: +1 646 532 3062  | c: +1 917 477 7906
>> appinions inc.
>> “The Science of Influence Marketing”
>> 18 East 41st Street
>> New York, NY 10017
>> t: @appinions <> | g+:
>> w: <>

View raw message