Erick, I found this tutorial really helped me to get my head around git:
http://pcottle.github.io/learnGitBranching/ You get to play making commits directly via that web UI, which shows you how commits happen, merges, etc. Upayavira On Sun, Jan 10, 2016, at 06:15 PM, Erick Erickson wrote: > So Karl, are you really the one who gave Monroe this idea? > https://xkcd.com/1597/ > > don't forget hover the mouse for the pop-up.... ;) > > On Sun, Jan 10, 2016 at 1:52 AM, Karl Wright <daddy...@gmail.com> wrote: > > Hi Dawid, > > > > The problem I've had with Git is not that the basic model is hard to > > understand -- it's that the basic model seems inadequate for many things, so > > there's been a huge proliferation of mysterious switches that are poorly > > documented and also very very powerful. svn has a few of these, but nowhere > > near the number or the opacity. Do you have a decent online resource that > > explains how these are meant to be used? > > > > Karl > > > > > > On Sun, Jan 10, 2016 at 4:25 AM, Dawid Weiss <dawid.we...@gmail.com> wrote: > >> > >> A few unrelated answers: > >> > >> 1) I would remove everything from SVN, add a commit informing about > >> the move to git, then import all this up-to-date history into git (I > >> volunteer to do this) and revert the last commit (in git). This way > >> the history is complete, including SVN->git move. > >> > >> Note this would require a few hours of stop-the-world on commits. > >> > >> 2. Contrary to Mark I use git command line only. And gitk (--all) to > >> visualize the history. git is really simple conceptually, I strongly > >> recommend reading this: > >> > >> http://eagain.net/articles/git-for-computer-scientists/ > >> > >> or this, which is slightly more verbose: > >> http://nyuccl.org/pages/gittutorial/ > >> > >> Once you get the idea that everything is in git is basically a set of > >> "states" of blobs (files, file sets, commit info history) everything > >> becomes much simpler. For example a cherry pick of commit X to branch > >> Y is basically applying X's diff from its parent commit to the current > >> state of Y. It's not a merge. It's svn's equivalent of svn diff > > >> patch, svn switch Y, svn apply patch. A merge is applying patches from > >> two separate lines of development that consolidate them. If there's a > >> conflict you add a third patch to resolve this conflict. > >> > >> We can definitely put up some beginner-level workflows, but the > >> understanding of what git is simplifies life greatly. > >> > >> In any case, Mark -- let me know (directly or on the list) when you > >> need me to perform the final git conversion. Once the infra has set up > >> a git repo it's all about one push from github to it (--mirror) and > >> we're set. > >> > >> Dawid > >> > >> > >> > >> On Sun, Jan 10, 2016 at 2:16 AM, Steve Davids <sdav...@gmail.com> wrote: > >> > @Prasanna you can follow along with the SVN -> GIT history migration in > >> > https://issues.apache.org/jira/browse/LUCENE-6933 > >> > > >> > @Erick for some basics you can checkout these interactive git guides, > >> > either > >> > https://www.codecademy.com/learn/learn-git or > >> > http://gitreal.codeschool.com/ > >> > though as Mark said if you find a decent UI you rarely need to use the > >> > command line. I’ve been fond of IntelliJ’s git support, but I have found > >> > Eclipse’s to be absolutely terrible (egit). > >> > > >> > -Steve > >> > > >> > On Jan 9, 2016, at 8:02 PM, Prasanna Dangalla > >> > <prasannadanga...@gmail.com> > >> > wrote: > >> > > >> > > >> > > >> > On Sunday, 10 January 2016, Prasanna Dangalla > >> > <prasannadanga...@gmail.com> > >> > wrote: > >> >> > >> >> Hi All, > >> >> I'm a new member to this project. I was reading the mails previously. > >> >> Thiught leeHere if we migrate > >> >> > >> >> mails previously. Thought of giving an input. Here if we migrate > >> > > >> > Sorry for the typo... > >> >> > >> >> > >> >> from svn its better to migrate the history as well. I meant the commit > >> >> history. How do we migrate the SVN commit log from svn to git ? > >> >> > >> >> On Sunday, 10 January 2016, Mark Miller <markrmil...@gmail.com> wrote: > >> >>> > >> >>> I think we will update much of the doc as we go, but I'm sure there > >> >>> are > >> >>> plenty of people that can help on the list with any questions. We can > >> >>> probably get some basics up relatively painlessly. I'd guess the > >> >>> number of > >> >>> committers that have not worked with Git yet is very small. > >> >>> > >> >>> As a start, my recommendation would be to Google Git for SVN users and > >> >>> look at some of those resources though. It's probably better than what > >> >>> we > >> >>> will subset. > >> >>> > >> >>> Personally, I like to just use SmartGit and mostly ignore command line > >> >>> Git :) > >> >>> > >> >>> How have you been able to ignore GitHub for so long :) > >> >>> > >> >>> Mark > >> >>> On Sat, Jan 9, 2016 at 6:13 PM Erick Erickson > >> >>> <erickerick...@gmail.com> > >> >>> wrote: > >> >>>> > >> >>>> I'm a little confused. A while ago I asked about whether I had to > >> >>>> learn all about Git, and as I remember the reply was "this is just > >> >>>> about the build process". Perhaps I mis-interpreted or that was > >> >>>> referring only to the bits Dawid was working on at that instant > >> >>>> or.... > >> >>>> > >> >>>> Anyway, assuming the SVN repo becomes read-only, that implies that > >> >>>> all > >> >>>> our commits need to happen in Git, right? There are still some "git > >> >>>> challenged" curmudgeons out there (like me) who really haven't much > >> >>>> of > >> >>>> a clue. I'll figure it out, mind you but it'd be nice if there were a > >> >>>> clear signal that "Now you have to figure it out because you can't > >> >>>> commit to the SVN repo any more". > >> >>>> > >> >>>> And the "how to contribute" page is all about SVN: > >> >>>> https://wiki.apache.org/solr/HowToContribute, if my understanding is > >> >>>> at all close that page needs some significant editing. > >> >>>> > >> >>>> Personally, before I screw up my first commit under Git, it would be > >> >>>> super helpful if there were a step-by-step. No doubt that really > >> >>>> amounts to three commands or something, but before "just trying > >> >>>> stuff" > >> >>>> it would be nice to have the steps for committing (pushing?) to trunk > >> >>>> and then getting those changes into 5x (well, maybe 6.0 by then) > >> >>>> outlined... > >> >>>> > >> >>>> Or I'm off in the weeds here, always a possibility. > >> >>>> > >> >>>> FWIW, > >> >>>> Erick > >> >>>> > >> >>>> > >> >>>> > >> >>>> On Sat, Jan 9, 2016 at 2:52 PM, Uwe Schindler <u...@thetaphi.de> > >> >>>> wrote: > >> >>>> > Hi Mark, > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > thanks for starting this! Looking forward to the whole process. > >> >>>> > When > >> >>>> > Infra > >> >>>> > is about to “activate” the new GIT repo, I will take care of > >> >>>> > Policeman > >> >>>> > Jenkins and fix the remaining validation tasks. I don’t want to do > >> >>>> > this. I > >> >>>> > think your commit is fine. > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > We now need some workflows how to merge between master/trunk and > >> >>>> > the > >> >>>> > release > >> >>>> > branches. Projects do this in different ways (cherry-picking,…). I > >> >>>> > have no > >> >>>> > preference or idea, sorry! I only know how to merge feature > >> >>>> > branches > >> >>>> > into > >> >>>> > master J > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > You mentioned that we should make the old svn read only. Maybe do > >> >>>> > it > >> >>>> > similar > >> >>>> > like we did during LuSolr merge: Add a final commit removing > >> >>>> > everything from > >> >>>> > trunk/branch_5x and leaving a readme.txt file in trunk and > >> >>>> > branch_5x > >> >>>> > pointing to Git. All other branches stay alive. After that we could > >> >>>> > make it > >> >>>> > read only – but it is not really needed. What do others think? > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > Uwe > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > ----- > >> >>>> > > >> >>>> > Uwe Schindler > >> >>>> > > >> >>>> > H.-H.-Meier-Allee 63, D-28213 Bremen > >> >>>> > > >> >>>> > http://www.thetaphi.de > >> >>>> > > >> >>>> > eMail: u...@thetaphi.de > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > From: Mark Miller [mailto:markrmil...@gmail.com] > >> >>>> > Sent: Saturday, January 09, 2016 10:55 PM > >> >>>> > To: java-dev <java-...@lucene.apache.org> > >> >>>> > Subject: Moving Lucene / Solr from SVN to Git > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > We have done almost all of the work necessary for a move and I have > >> >>>> > filed an > >> >>>> > issue with INFRA. > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > LUCENE-6937: Migrate Lucene project from SVN to Git. > >> >>>> > > >> >>>> > https://issues.apache.org/jira/browse/LUCENE-6937 > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > INFRA-11056: Migrate Lucene project from SVN to Git. > >> >>>> > > >> >>>> > https://issues.apache.org/jira/browse/INFRA-11056 > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > Everyone knows about rebase and linear history right ;) > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > - Mark > >> >>>> > > >> >>>> > -- > >> >>>> > > >> >>>> > - Mark > >> >>>> > > >> >>>> > about.me/markrmiller > >> >>>> > >> >>>> --------------------------------------------------------------------- > >> >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> >>>> For additional commands, e-mail: dev-h...@lucene.apache.org > >> >>>> > >> >>> -- > >> >>> - Mark > >> >>> about.me/markrmiller > >> >> > >> >> > >> >> > >> >> -- > >> >> Prasanna Dangalla > >> >> Software Engineer, WSO2, Inc.; http://wso2.com/ > >> >> http://wso2.com/about/team/prasanna-dangalla > >> >> lean.enterprise.middleware > >> >> > >> >> cell: +94 777 55 80 30 | +94 718 11 27 51 > >> >> twitter: @prasa77 > >> >> > >> > > >> > > >> > -- > >> > Prasanna Dangalla > >> > Software Engineer, WSO2, Inc.; http://wso2.com/ > >> > http://wso2.com/about/team/prasanna-dangalla > >> > lean.enterprise.middleware > >> > > >> > cell: +94 777 55 80 30 | +94 718 11 27 51 > >> > twitter: @prasa77 > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
