Perl 6 - the future is here, just unevenly distributed

IRC log for #opentreeoflife, 2014-03-10

| Channels | #opentreeoflife index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
06:33 saybel joined #opentreeoflife
14:26 towodo joined #opentreeoflife
14:56 jimallman joined #opentreeoflife
15:04 snacktavish joined #opentreeoflife
16:07 mtholder joined #opentreeoflife
16:21 snacktavish Hello!
16:21 mtholder howdy. jimallman and snacktavish. Is the merge to master bandaid to the API not working?
16:21 snacktavish https://github.com/OpenTreeOfLife/api.opentreeoflife.org/commit/cdcf9a0e94b0568e55920d1ced38f43fefea1e96#commitcomment-5601372
16:21 snacktavish @jimallman posted this comment on GH
16:21 mtholder we talked about this a bit on the call.
16:22 jimallman no, but just because of the current repo situation. there are sweeping "upstream" changes to NexSON that cause conflicts everywhere.
16:22 mtholder So if you delete all your WIPs on the dev server is it happy after that?
16:22 mtholder or is it recurring?
16:23 mtholder recurring with new WIPs?
16:23 jimallman studies load properly, but trying to save locks up the API's git repo. i've been ssh'ing to the API server and running 'git reset --hard' to reset things, but it'll fail again on each save.
16:23 jimallman oh, my bad. yes, removing WIP branches would clear this up.
16:23 * jimallman recalls we talked about this last week.
16:23 mtholder that may not do it, but I hope that it will...
16:23 jimallman s/would/should
16:25 jimallman this should work, since it's the difference between NexSON (in the WIP branch) and the latest that causes the conflicts. but yeah, it suggests we could see similar situations if we ever have standing WIP branches when some other tool touches the studies.
16:25 snacktavish Ah, so it seems like it is prexisiting conflicts between the local repo and the github copy, rather than misplaced pulls?
16:26 mtholder I think so. I was thinking about the bandaid from the perspective of a clean, branchless repo.
16:26 jimallman snacktavish: yes, that's a good way of putting it. or more properly, conflicts between the master branch (even on local repo) and the WIP branches.
16:26 snacktavish And merge conflicts can/will be a problem in future if multiple curators have WIP branches for the same study at the same time.
16:27 jimallman we've talked about a smart-merge tool to resolve situations like these.. don't know if that's just a wish at the moment, or if someone's starting working on it
16:27 snacktavish I'm confused about local conflicts between master and WIP. This is due to other WIP's haveing been merged back into master since the WIP branch was created?
16:29 snacktavish @mtholder and I have been talking about how deal with merge conflicts. I think current plan is to just to try to return a readable diff back to the curator app, and have curators figure it out?
16:33 jimallman re: local conflicts -- in this case, we've had long-standing WIP branches with pending edits in them. meanwhile, the "public" master branch was updated with newer NexSON format, so when we finally tried to merge them, conflict!
16:34 jimallman re: curator sorts out readable diffs, that's an interesting thought, but in most cases the diffs are so trivial (or plain weird) that it might be hard to do this well. but this is probably due to the big changes in NexSON -- it's definitely an edge case.
16:35 snacktavish re: local conflicts Ah. Makes sense.
16:38 mtholder I think that we can tweak peyotl/struct_diff.py to return the diffs between the  current tip of master and the most recent common ancestor fo the curator's WIP and the master.
16:38 snacktavish re: curator sorts out readable diffs. I guess I am thinking that in future I would expect conflicts to be created mostly by different curators edits- in which case they would be sensical and require knowledgable intervention, but a smart merge for other formatting related conflicts would perhaps be useful.
16:41 jimallman gotcha. perhaps a smart-merge tool would distinguish trivial (or overly literal) diffs and resolve them automatically, while preparing "meaningful" NexSON differences and presenting them to the curator(s). Another option would be to keep one (arbitrarily) and stash the proposed alternative in an annotation..? This would appear in the curation tool and allow a decision.
16:41 jimallman or we can be mean and just link to the "raw" git conflict...
16:42 snacktavish That's what I said, but @mtholder is nicer than me!
16:42 snacktavish Currently is it possible for you to merge the local master into your WIP branches?
16:43 snacktavish Maybe I should look at those diffs, because I'm curious as to what kind of issues there are.
16:43 jimallman not without resolving all (many) conflicts, but that's because of the stale WIP branches. new ones should work fine (i believe i've tested this, will try again now)
16:44 jimallman just a sec, i'll create the pile-up on dev...
16:45 snacktavish Ah right, as you said above. Were those branches just for testing? Can they just be blown away?
16:49 jimallman https://gist.github.com/jimallman/b332240fdbbc7eb3b257
16:50 jimallman there's the full "conflicted" version of study 10... but again, an edge case. and yes the current WIP branches are disposable.
16:51 jimallman and i'll dispose of them now. we can resurrect them later, if we want to stress-test a smart-merge tool in a "worst-case scenario".
16:52 snacktavish Ha, sounds fun! OK- I'm off to a seminar but will check back in later.
16:52 snacktavish left #opentreeoflife
17:03 lcoghill joined #opentreeoflife
17:08 jimallman_ joined #opentreeoflife
18:44 snacktavish joined #opentreeoflife
20:12 tezarus joined #opentreeoflife
22:26 jimallman joined #opentreeoflife
23:00 mtholder joined #opentreeoflife

| Channels | #opentreeoflife index | Today | | Search | Google Search | Plain-Text | summary