lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl <jan....@cominvent.com>
Subject Re: The Old Git Discussion
Date Sat, 04 Jan 2014 16:23:16 GMT
It took some getting used to GIT for me too (and I've been around since the rcs days :)
But now I constantly prefer git over svn, and switching to git is a clear trend among our
customers too.

> * PRs are a *Github* thing, not a Git thing, right?

Yea, GitHub makes it really easy and visual. But the important thing here is the P (pull).
Say someone fixes a bug through the GitHub mirror and makes a pull-request. Or simply pastes
the URL to his feature branch into JIRA. Then a committer can easily do the Pull from that
remote repo. Since each clone is a full copy of the entire repo, pulling and merging from
any other copy will Just Work™

Another beauty of PRs (at least at GitHub) is that the contributor can continue improving
the fix in his branch through small incremental commits, and this will be included in the
pull without the need for another PR.

> * 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?


Of course you can and will get conflicts. But somehow Git is smarter at merging and less prone
to conflicts. At least that's my experience and what most people emphasize as a git advantage
too. I wonder if part of the reason for this is that people commit more frequently and in
smaller chunks to their local branch, so when the time comes for the HUGE merge, Git will
actually do a bunch of small merges instead of trying to merge in a monolithic patch file.
I think a Git commit keeps more metadata about the context of the changes to help getting
a clean merge.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

4. jan. 2014 kl. 04:32 skrev Otis Gospodnetic <otis.gospodnetic@gmail.com>:

> Hi,
> 
> On Fri, Jan 3, 2014 at 2:42 PM, Michael Della Bitta <michael.della.bitta@appinions.com>
wrote:
> 
> On Fri, Jan 3, 2014 at 2:03 PM, Erick Erickson <erickerickson@gmail.com> 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+: plus.google.com/appinions
> w: appinions.com
> 


Mime
View raw message