On Mar 21, 2012, at 9:03 PM, Sanne Grinovero wrote: > On 21 March 2012 16:42, Galder Zamarreño <[email protected]> wrote: >> >> On Mar 21, 2012, at 11:11 AM, Sanne Grinovero wrote: >> >>> I'm not sure how you could have missed all the times I mention this >>> script from Emmanuel ;-) >>> >>> https://gist.github.com/789588 >> >> I've seen it and the script several times and no matter how many times I >> look at it, I still don't see how it fits my use case. > > It could help giving it a try rather than looking at it :D
Well, I can read what it does and if I find it not to be useful, I wont waste my time trying it :D > >> >> I've always understood that Emmanuel's script works with committed changes >> and clones a repo and that's not what I want for a couple of reasons: >> >> 1. Just want to uncommitted test changes. > > I guess that's the main point on which our opinions diverge. This > means the pull requests you send are not what you have tested, as you > might have an index in different state. > We consider it a big value to test only what's committed. Although I think it's a valid point, the sync_with_upstream patch we have will stash changes, synch up and then reapply. And I use that script frequent enough that I haven't had any issues that you suggest. > > This makes me think you blindly "add all" to avoid mistakes: likely > again matter of taste, but I think that approach is not encouraging > better looking patches. "add all" to avoid which mistakes? what do you mean by "add all"? Indeed, I think this is more a divergence in taste/habit, which Emmanuel clarifies further in the next email. However, all this is good to find out about different approaches. > >> 2. I don't want the copy to be clone in order to avoid committing things in >> the wrong place. > > You could export rather than clone, but I don't feel your need as this > clone is going to happen to a path which your nor your IDE nor your > terminal are pointing to. Well, I do run it from ~/Go/test/infinispan.git, so that I can see the failures and have quicker access to the folder if I need to…etc, so my terminal is pointing to it. I could do it the other way too. > > >> Feel free to correct me…. >> >>> And this one is from myself, also useful imho: >>> >>> https://gist.github.com/1086445 >> >> Hmmm, how far does it go opening JIRAs? I mean, if I integrate ISPN-9999, I >> don't want all past JIRAs to open, just ISPN-9999. > > Why would it open all previous issues? > It only looks at the history of commits between HEAD and master, > usually no more than a dozen of commits, and extracts identifiers > which look like JIRA issue codes. > Granted it works only for branches "targeting" master, don't use it > when reviewing [for example] a commit backported to 5.1.x. I'm not saying that it will open all previous issues, I was more wondering about how it does it to avoid opening all previous issues.. > >> >> I use Chrome btw. > > sorry to hear Chrome can't open JIRA .. :) > >> >>> Both have been promoted as global alias in my shells since a while. >>> >>> Sanne >>> >>> On 21 March 2012 09:50, Galder Zamarreño <[email protected]> wrote: >>>> Hi all, >>>> >>>> Just wanted to share a tip that's helped me in the last few months get >>>> more productive >>>> >>>> You might have seen that once you run the testsuite in the infinispan >>>> source code, IntelliJ kinda goes a bit mad re-indexing and the IDE becomes >>>> unusable. >>>> >>>> Eventually I got fed up of this and what I do instead is rsync to a >>>> separate folder with: >>>> >>>> rsync -av --exclude '.git' --exclude '*.class' --exclude 'target' --delete >>>> ~/Go/code/infinispan.git/ . >>>> >>>> I do this from say: ~/Go/test/infinispan.git which crucially is not a git >>>> clone which avoids accidental commits from that folder. >>>> >>>> Then, I always run the testsuite from that test folder after rsyncing. >>>> That way, I can carry on doing stuff in the IDE while the testsuite runs >>>> in the background. >>>> >>>> Having SSD and 8gb ram help of course too :) >>>> >>>> Cheers, >>>> >>>> p.s. If you have any other tips that have helped you, please share. >>>> -- > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
