uPortal IRC Logs-2011-10-27

Owned by Apereo Infrastructure
Last updated: Oct 27, 2011Version comment

[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 (tongue)

[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 (smile)

[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 (smile)

[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> (smile)

[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 (smile)

[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 (tongue)

[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> (smile)

[10:02:57 CDT(-0500)] <Arvids> yes (smile)

[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