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 <sanne(a)infinispan.org> wrote:
On 21 March 2012 16:42, Galder Zamarreño <galder(a)redhat.com>
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 <galder(a)redhat.com> 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
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev