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.gospodne...@gmail.com>: > Hi, > > On Fri, Jan 3, 2014 at 2:42 PM, Michael Della Bitta > <michael.della.bi...@appinions.com> wrote: > > On Fri, Jan 3, 2014 at 2:03 PM, Erick Erickson <erickerick...@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 >
