I do tend to commit often and rebase/amend if needed. It helps minimize context switching. The big plus for me is that I can work on the next thing while tests are running.
I never have my command line in the cloned repo so I can never commit to the wrong repo. Btw you can ask IntelliJ to exclude some directories from scanning but that's a manual setup I believe. On 21 mars 2012, at 21:03, Sanne Grinovero <[email protected]> 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 > >> >> 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. > > 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. > >> 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. > > >> 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 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 _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
