[08:35:59 CDT(-0500)] <Arvids> I assume https://issues.jasig.org/browse/UP-1435 should be closed (judging by change history), shouldn't it?
[08:50:52 CDT(-0500)] <Arvids> using tools like FindBugs might turn out depressing 
[08:51:19 CDT(-0500)] <Arvids> I'm looking at https://issues.jasig.org/browse/UP-2976 and ran my own tests... it reported 321 possible bug
[09:18:06 CDT(-0500)] <EricDalquist1> good morning
[09:20:09 CDT(-0500)] <Arvids> hi 
[09:20:48 CDT(-0500)] <Arvids> just finished looking through all the issues addressed to 4.0.2 version
[09:21:52 CDT(-0500)] <Arvids> Not sure what should I do about https://issues.jasig.org/browse/UP-2976
[09:22:56 CDT(-0500)] <Arvids> also I marked some duplicates
[09:23:01 CDT(-0500)] <EricDalquist1> heh … yeah I'm thinking about just closing that with a pointer to: https://developer.jasig.org/projects/uportal/4.0.2-SNAPSHOT/uportal-war/findbugs.html
[09:23:14 CDT(-0500)] <EricDalquist1> and a note saying that it is more of a standing issue
[09:23:24 CDT(-0500)] <EricDalquist1> a big part of it is more of the warnings are in old code
[09:23:29 CDT(-0500)] <EricDalquist1> that is slated for re-write
[09:24:02 CDT(-0500)] <EricDalquist1> thanks for all the help with that btw
[09:24:05 CDT(-0500)] <Arvids> sounds like a reasonable scenario
[09:26:08 CDT(-0500)] <Arvids> I'm going to implement https://issues.jasig.org/browse/UP-2879
[09:26:18 CDT(-0500)] <EricDalquist1> great
[09:26:27 CDT(-0500)] <Arvids> ... and saw this one patch: https://issues.jasig.org/browse/UP-3214
[09:26:48 CDT(-0500)] <EricDalquist1> oh yeah, that should be an easy one to fix
[09:26:50 CDT(-0500)] <Arvids> I could submit it as Pull Request via github
[09:26:57 CDT(-0500)] <EricDalquist1> that would be great
[09:27:10 CDT(-0500)] <EricDalquist1> I know bill said he'd work on figuring out github pull requests in the future as well
[09:28:36 CDT(-0500)] <Arvids> Tomorrow (in my timezone) I spent few hours figuring out how to avoid commiting commits like "git Merge remote-tracking branch 'upstream/master'"
[09:29:02 CDT(-0500)] <EricDalquist1> in what context?
[09:29:18 CDT(-0500)] <Arvids> I was doing fetches/merges and then pushes to my clone
[09:29:21 CDT(-0500)] <EricDalquist1> I think you get those if you merge master into your work branch and then merge the work branch into master
[09:29:57 CDT(-0500)] <Arvids> yes, it was the case
[09:30:20 CDT(-0500)] <Arvids> but eventually I figured out how to skip them and synchronize with upstream repo
[09:30:33 CDT(-0500)] <EricDalquist1> oh neat
[09:31:56 CDT(-0500)] <Arvids> it was a rude way: first pulling from upstream: git pull --rebase upstream master
[09:32:04 CDT(-0500)] <Arvids> and then pushing in forced mode
[09:32:25 CDT(-0500)] <EricDalquist1> ah
[09:32:27 CDT(-0500)] <EricDalquist1> yeah
[09:32:27 CDT(-0500)] <Arvids> ... of course, doing stashing before
[09:32:41 CDT(-0500)] <EricDalquist1> that works as long as no one has a clone of your branch
[09:32:59 CDT(-0500)] <EricDalquist1> I have a similar gripe about git rebase
[09:33:26 CDT(-0500)] <EricDalquist1> like the work I did on the cluster locking, I knew the work I did in parallel on portal events would cause the locking code to not compile
[09:33:59 CDT(-0500)] <EricDalquist1> so to keep the history simpler I wanted to do a git rebase, which essentially moves the start of the branch to the current head of the source branch
[09:34:14 CDT(-0500)] <EricDalquist1> the problem is if you rebase a branch that you've pushed out anywhere bad things can happen
[09:34:28 CDT(-0500)] <EricDalquist1> since people that just do a normal 'pull' of a rebased branch have problems
[09:34:50 CDT(-0500)] <EricDalquist1> all the advice I've seen is "don't push if you rebase" but that makes it hard for those of us that work from multiple computers
[09:35:02 CDT(-0500)] <Arvids> Which is the best way of avoiding those "merge" commits?
[09:35:15 CDT(-0500)] <EricDalquist1> well rebase avoids the merge commits
[09:35:37 CDT(-0500)] <EricDalquist1> and if you haven't pushed your working branch to anywhere yet it is very safe
[09:35:49 CDT(-0500)] <Arvids> yeah, but the suggested way of updating my origin is fetch -> merge -> push, isn't it?
[09:35:57 CDT(-0500)] <Arvids> ... and this scenario adds merge commit
[09:36:25 CDT(-0500)] <EricDalquist1> it essentially stashes all your commits on the branch, resets the branch start to the current head, then replays the commits
[09:37:03 CDT(-0500)] <EricDalquist1> can you link me to one of the merge commits you're talking about?
[09:37:36 CDT(-0500)] <Arvids> hmm.. I cleared them during rebase and pushing
[09:37:42 CDT(-0500)] <EricDalquist1>
[09:37:52 CDT(-0500)] <EricDalquist1> and these were in your fork?
[09:38:02 CDT(-0500)] <Arvids> yes
[09:39:05 CDT(-0500)] <Arvids> I'll try to reproduce it next time I update my fork
[09:39:17 CDT(-0500)] <EricDalquist1> I'm going to do that right now
[09:39:23 CDT(-0500)] <Arvids> I'm missing something... or doing something unnecessary
[09:40:19 CDT(-0500)] <EricDalquist1> https://gist.github.com/1319724
[09:40:39 CDT(-0500)] <EricDalquist1> https://github.com/edalquist/uPortal/commits/master
[09:40:48 CDT(-0500)] <EricDalquist1> looks like that worked without creating a merge commit
[09:42:17 CDT(-0500)] <Arvids> ok, it might be that I executed some commands improperly
[09:45:33 CDT(-0500)] <EricDalquist1> ah learning curves
[09:45:43 CDT(-0500)] <EricDalquist1> eventually I'm going to try the whole workflow via egit
[09:45:54 CDT(-0500)] <EricDalquist1> since it is all doable that way
[09:46:00 CDT(-0500)] <EricDalquist1> guess I just like cli
[09:46:27 CDT(-0500)] <Arvids> me too - somehow egit feels like ... inconvenient
[09:46:31 CDT(-0500)] <Arvids> not sure why
[09:46:47 CDT(-0500)] <EricDalquist1> yeah
[09:46:52 CDT(-0500)] <EricDalquist1> well git is so fast
[09:46:56 CDT(-0500)] <EricDalquist1> and egit is not
[09:47:01 CDT(-0500)] <EricDalquist1> where as svn was slow
[09:47:10 CDT(-0500)] <EricDalquist1> so svn via eclipse didn't add much overhead
[09:57:51 CDT(-0500)] <EricDalquist1> uhg that patch isn't thread-safe
[10:00:48 CDT(-0500)] <Arvids> hmm... indeed...
[10:01:13 CDT(-0500)] <Arvids> I believe I have an idea how to fix it
[10:01:26 CDT(-0500)] <EricDalquist1> easy way would be a ThreadLocal<List>
[10:01:55 CDT(-0500)] <EricDalquist1> with a little logic to call threadLocal.remove() when the recurssion unwinds
[10:02:14 CDT(-0500)] <EricDalquist1> another would be to modify the primGetAllContainingGroups API
[10:02:25 CDT(-0500)] <Arvids> no API changes are required
[10:02:33 CDT(-0500)] <EricDalquist1> and just pass the List as a parameter instead of using a TL
[10:02:43 CDT(-0500)] <Arvids> easier is to write another recursive method that's hidden and called inside the protected method
[10:02:52 CDT(-0500)] <EricDalquist1>
[10:02:57 CDT(-0500)] <Arvids> yes
[10:03:59 CDT(-0500)] <Arvids> ... hmmm... how can I revert changes in master branch?
[10:04:38 CDT(-0500)] <EricDalquist1> you can amend your last commit
[10:04:44 CDT(-0500)] <EricDalquist1> and then do a push --force
[10:05:29 CDT(-0500)] <Arvids> thanks for the tip
[12:18:06 CDT(-0500)] <EricDalquist1> athena: what time is the coop dev call tomorrow?
[12:18:28 CDT(-0500)] <athena> should be 8:30 am pacific
[12:18:54 CDT(-0500)] <EricDalquist1> cool, I'll be able to be there to talk about the events stuff
[12:19:28 CDT(-0500)] <athena> excellent