Perl 6 - the future is here, just unevenly distributed

IRC log for #metacpan, 2014-06-06

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

All times shown according to UTC.

Time Nick Message
01:32 FROGGS_ joined #metacpan
01:36 klapperl joined #metacpan
02:16 mutant left #metacpan
02:27 heytitle joined #metacpan
03:16 lifeofguenter joined #metacpan
05:52 castaway joined #metacpan
06:11 jwang joined #metacpan
06:32 oiami joined #metacpan
06:41 jnbek joined #metacpan
06:43 priodev joined #metacpan
06:51 FROGGS_ joined #metacpan
07:56 neilb joined #metacpan
07:59 Lee joined #metacpan
08:16 dpetrov_ joined #metacpan
08:27 neilb joined #metacpan
08:34 neilb joined #metacpan
08:52 jnbek joined #metacpan
08:55 sivoais joined #metacpan
09:08 oiami left #metacpan
10:47 alnewkirk joined #metacpan
11:09 oiami joined #metacpan
12:52 andrefs joined #metacpan
12:54 andrefs joined #metacpan
14:15 FROGGS joined #metacpan
14:17 rashi joined #metacpan
15:20 jnbek^dt joined #metacpan
16:13 sivoais joined #metacpan
16:13 jnbek joined #metacpan
16:46 neilb joined #metacpan
17:13 oiami left #metacpan
17:52 jnbek joined #metacpan
18:02 jnbek^dt joined #metacpan
18:10 sivoais joined #metacpan
18:30 mst huh
18:31 mst when you added the 'diff with version' feature, where did 'jump to version' get moved to?
18:31 mst you've removed a commonly used feature and replaced it with a rarely used one and now I can't find the important one anymore :(
18:31 rafl the dist name at the top doubles as a drop down of versions
18:31 mst oooh, there's a tiny down pointing arrow
18:32 mst that's impressively well hidden
18:32 rafl thanks
18:40 mst oalders: suggest switching back to having a 'goto version' box and then having 'diff with version' underneath - the latter's a useful feature but the current UX change makes it basically impossible to find the 'goto version' part
18:40 jnbek^dt joined #metacpan
18:40 mst rafl++ # compensating for the lack of discoverability
18:47 trs mst: the diff version box has been there a while, just underneath the goto version box before it moved
18:47 trs but it ain't a new feature :)
18:49 sivoais joined #metacpan
18:49 mst trs: right. my point is that the goto version box should move back so people can actually find it
18:50 mst I'd been using the 'diff with version' box and then making a second click for weeks because it looked like you'd simple removed the goto version box
18:50 mst but if you try and diff perl 5.8.1 and perl 5.20.0 the diff code goes "aaaargh"
18:50 mst and gives up, so I had to figure out where the actual feature had been hidden this time
18:50 trs sure, just noting the diff has been there.
18:50 mst well, no, 'move back' is wrong. having the drop-down at the top is really neat
18:51 trs there's no reason I see why we can't have both version dropdowns.
18:51 mst heh, right
18:51 trs :)
18:55 mst but visually the one at the top is really hard to spot
18:55 mst so, yeah, "both"
18:59 ether I had a coworker ask me just yesterday how to get to a specific version
19:00 ether so that's another data point for "it isn't obvious"
19:02 alh I couldn't find it either
19:02 alh b/ 19
19:02 oalders mst: if you want to open an issue for that, we can see about assigning it.  i think we've had enough time to live with it and it's still confusing
19:02 alh I also can't type though, so maybe my opinion is invalid.
19:02 oalders :)
19:04 mst oalders: issue against which repo? CPAN-API/metacpan/ ?
19:04 oalders mst: https://github.com/CPAN-API/metacpan-web/issues
19:04 dipsy [ Issues · CPAN-API/metacpan-web · GitHub ]
19:04 haarg i think there may already be an issue
19:05 haarg https://github.com/CPAN-API/metacpan-web/issues/1079
19:05 dipsy [ dist version dropdown went AWOL · Issue #1079 · CPAN-API/metacpan-web · GitHub ]
19:06 mst filed #1214
19:06 haarg iirc mithaldu at one point was looking at implementing it, but i guess that never happened
19:06 Mithaldu haarg: i looked at how it was implemented and basically conluded "this shit's about as fucked as gitalist"
19:07 oalders so, is that a no?
19:07 haarg there is an unfortunate amount of logic in the templates
19:08 Mithaldu oalders: it means even though i would love to, when faced with your templates and code, i do not know HOW
19:08 Mithaldu and i was not able to confidently figure out how either
19:08 oalders there's too much going on in the templates
19:09 oalders we should probably put a stop to any more logic in the templates that could reside elsewhere
19:09 Mithaldu it doesn't help that the old menu was implemented in a decidedly different manner than the current one
19:09 mst there was a point at which the goto version and the diff with version were both present in the left hand bar
19:09 mst can we not just revert the removal?
19:10 Mithaldu it also doesn't help that the git history is amazingly confusing due to feature branches being merged without rebase as a rule
19:10 Mithaldu mst, due to ^, a revert is not easily done
19:11 oalders Mithaldu: actually rebase is the rule, except in the case of the bootstrap branch, which was a monster and quite long-lived
19:11 oalders we tried rebasing and it was a fool's errand
19:11 oalders specifically i tried it -- and life is too short
19:12 haarg and reverting likely wouldn't work well anyway since a bunch of the related template code has changes
19:13 Mithaldu oalders: i am talking about stuff like this: https://dl.dropboxusercontent.com/u/10190786/Screenshot%202014-06-06%2021.11.25.png
19:14 Mithaldu if you guys fixed that in the meanwhile, cheers :)
19:14 oalders Mithaldu: i can never read those graphs. what's the specific problem there?
19:14 oalders too many lines
19:15 Mithaldu that is the exact problem
19:15 oalders heh
19:15 Mithaldu if you rebase every feature branch
19:15 Mithaldu you end up with something that resembles a fork
19:15 Mithaldu one line, with a bunch of lines ending in tips at one end
19:17 oalders Mithaldu: are you saying that every single pull request requires a rebase before merge?  we get a lot of pull requests and if the merge looks clean, that's fine.
19:18 Mithaldu to quote the ghost busters: "Never cross the streams!"
19:18 jibsheet our large git repo rarely gets rebase before merge
19:18 Mithaldu (yes, i'm saying exactly that))
19:18 oalders Mithaldu: i appreciate the sentiment, but i can't ask every person with a 3 line commit to rebase because someone else's pull request got in before theirs
19:18 Mithaldu just do it yourself
19:19 oalders because i have nothing else to do?
19:19 Mithaldu if the PR is trivial, it's a few clicks or commands
19:19 jnbek_ joined #metacpan
19:19 sivoais joined #metacpan
19:19 oalders the beauty of the interface is that it makes things easy
19:19 oalders the github UI
19:20 Mithaldu i do not remember the exact quote, but there is a quote about arriving very quickly at the solution, regardless of whether it's wrong or not
19:20 Mithaldu the github ui is fine for handling toy projects
19:20 Mithaldu but as the current case demonstrates, it's not suitable for all of them
19:21 oalders i'm not sure that has been demonstrated
19:21 oalders but, if it prevents you from contributing, i understand your reasons
19:21 Mithaldu ok, more simply:
19:22 Mithaldu with a single line history, finding the commit that removed the dropdown would be as simple as running git bisect
19:22 Mithaldu with the history as it is currently doing that is almost impossible
19:24 alh Is 599b70682d21826d4928478f2c3f236e0e2c95af too obvious?
19:24 oalders alh++
19:25 Mithaldu alh: i honestly never found that
19:25 Mithaldu i remember looking at release-info.html
19:25 trs Mithaldu: pickaxe + blame is often very helpful in repos like this.
19:26 * trs doesn't like rebasing before merge because it means that unintended changes can sneak in after review happened if there were conflicts to resolve.
19:26 alh That's from 2013 though, and your ticket is from this year
19:26 alh So I'm not entirely sure that's the right one, but it's something
19:27 Mithaldu alh: maybe that one was merged in with the whole bootstrap stuff
19:27 alh Ahh, could be
19:27 oalders this is the problem of the long-lived branch
19:27 oalders that commit is old, but it came with the merge
19:28 oalders we could have squashed the whole merge into one commit, but that would have been a different mess
19:28 Mithaldu so can we just make a revert commit for that? B]
19:28 trs squashing--
19:29 Mithaldu oalders: just ask me next time there's something that should be rebased but you can't be arsed to
19:29 Mithaldu i've gotten exceedingly efficient at it
19:29 Mithaldu (yes, i'm serious)
19:29 trs Mithaldu: why is the overhead worth it?
19:29 Mithaldu trs: finds bug, makes the history not be a cthulhic nightmare
19:29 trs it is sometimes desireable, yes, but in general before every topic branch merge?
19:30 haarg reverting won't work in this case
19:30 trs finds bug?
19:30 haarg i'll have a pr in a minute
19:30 Mithaldu trs: bugs can come into existance from the merge of two singularly harmless commits
19:30 haarg Mithaldu: git log -p -SBackPAN found the correct commit immediately
19:31 trs Mithaldu: yes, just like bugs can come into existance from rebasing a singularly harmless commit onto another one.
19:31 Mithaldu trs: their reason becomes easy to spot and bisect then :)
19:31 Mithaldu haarg: let me look up with -S does
19:31 trs I guess I don't see why it's harder to spot them if you rebase everything.
19:31 Mithaldu *easier
19:31 trs ahhh, you don't know -S?  Learn to love it. :)
19:32 alh (Note: I realize "too obvious" may have sounded sarcastic. What I meant was "This commit seems to be the one, but it was easy (for me to find), so I suspect y'all have already discounted it.")
19:32 trs sorry, yes, s/harder/easier/ or s/rebase/don't rebase/
19:32 alh Perhaps I'm digging a hole here...
19:32 Mithaldu alh: ooooh
19:32 Mithaldu i thought you were earnest :)
19:32 trs also -G
19:33 oalders Mithaldu: ok, if there's a big rebase, i'll ping you :)
19:33 Mithaldu trs: cool beans, wouldn't have helped me though as i got a log viewer that easily greps, i just didn't think to look for backpan :)
19:33 alh Well good :)
19:33 Mithaldu oalders: cheers :D
19:33 trs -S and -G are not just --grep
19:34 Mithaldu i'm aware, i was using short words to describe big concepts
19:34 trs ok
19:35 Mithaldu trs: also, the difference between a merged and a rebased branch are that all the conflict corrections on a rebased one are spread out of the commits of the graph, while the conflict corrections on a merge are all smushed into a single commit
19:36 Mithaldu and even without conflicts, if a bug happens because of a combination of commits, in a merge you only know it's any of the commits before the merge, with a rebase you are pointed directly to the one, and only have to find the other
19:36 Mithaldu i hope this explanation is clear :x
19:36 haarg https://github.com/CPAN-API/metacpan-web/pull/1215
19:36 dipsy [ restore Jump to version dropdown by haarg · Pull Request #1215 · CPAN-API/metacpan-web · GitHub ]
19:36 Mithaldu haarg++ # <3
19:36 trs Mithaldu: yep. that's one of the factors that's useful for determining when you might want to rebase, but I don't see any conflict as meaning "must rebase".  it's a sliding scale.
19:37 trs short-lived topic branches (whatever that means for your project, could vary wildly) generally don't hit enough conflicts to warrant a rebase in my book.
19:37 Mithaldu trs: typically for instances where you would think you can skip it, doing it is so trivial it ends up being a nop :)
19:37 jibsheet ==trs - if a branch conflicts like crazy, I'll rebase, but for non-conflicting merges I rarely see the point
19:38 trs Mithaldu: sure, it is often trivial, but it's another step, rewrites published branch history, and there are few benefits I see. :)
19:40 oalders haarg: looks good. just waiting on travis
19:40 trs I've not run into problems finding a bug-introducing commit using my merge strategy, so I don't find it compelling. ;)
19:40 Mithaldu trs: honestly, i really don't want to start explaining the philosophy of defensive coding
19:40 Mithaldu so i'll just excuse myself from the conversation
19:40 Mithaldu i'm just really glad haarg managed to fix it :)
19:40 * trs only codes offensively, obviously.
19:41 oalders :)
19:56 haarg bleh.  prereqs fail to install on 5.20.
19:57 mst trs: generally I rebase immediately before merging and deleting the branch so I don't really regard it as rewriting public history
20:00 jnbek joined #metacpan
20:00 sivoais joined #metacpan
20:03 metacpan joined #metacpan
20:03 metacpan [metacpan-web] oalders pushed 2 new commits to master: http://git.io/b7csRg
20:03 metacpan metacpan-web/master 8f45109 Graham Knop: restore Jump to version dropdown...
20:03 metacpan metacpan-web/master 27a9386 Olaf Alders: Merge pull request #1215 from haarg/jump-to-version...
20:03 metacpan left #metacpan
20:03 dipsy [ Comparing a324ba86b81b...27a9386c1551 · CPAN-API/metacpan-web · GitHub ]
20:03 trs mst: if you have to fix conflicts in the rebase, then what you merged isn't what was published.
20:04 oalders mst: changes deployed
20:04 oalders haarg++
20:05 Mithaldu it actually works too :D
20:05 trs mst: the commit ids themselves are also different, so anyone who was looking at the public history won't find them by commit id.
20:05 mst trs: if you have to fix conflicts in a merge, then what eventually ends up in master ends up even less related to the branch
20:05 mst trs: I guess your point of view depends on how infrastructure-level the relevant software is - DBIx::Class rebases branches religiously, and then uses --no-ff to force a merge commit so you have a completely clean merge commit that shows that those commits came in as a block
20:06 mst trs: and I would consider anything else to be taking an unnecessary risk
20:08 trs how is what ends up in master less related to the branch by virtue of fixing conflicts in a merge?
20:09 trs with a merge, what changed with conflicts is published in a single place to see.
20:09 trs with a rebase without deleting/repushing, what changed with conflicts is much harder to see.
20:10 trs you need to find the original commit and then apply use git topic-diff to compare the two trees.
20:10 trs that's true even with deleting/repushing, but it's much more obvious that "something changed"
20:11 haarg most tools do a bad job at presenting changes made in merge commits
20:11 trs how so?  I think git diff does a pretty good job and so does tig.
20:11 mst trs: if there's enough of a conflict to matter you should be re-reviewing the branch anyway
20:11 haarg i've had multiple times where important changes just didn't show up
20:12 trs looking at changes made in a merge commit is easier, IMO, than comparing two trees with something like git topic-diff.
20:12 Mithaldu mst: tbh, i rereview every branch i rebase, just in case
20:12 trs although git topic-diff does do a pretty good job.
20:12 mst trs: fundamentally, you're imagining problems that don't actually exist in the process I've described, probably because you've not worked on a project where that process was followed - I can see how you might think that would be the case, but in practice it isn't true
20:13 Mithaldu also, trs, typically the conflict resolutions in a rebased branch simply are of higher quality, because one can address them one at a time, instead of all at once
20:14 Mithaldu plus, to make things even more fun, you can rebase gradually up another branch you want to end up at the top of
20:14 trs Mithaldu: I've done a lot of rebasing on branches with lots of conflicts, so I'm familiar with the benefits in cases where conflict is very high.
20:14 trs and working your way up to make it easier.
20:15 Mithaldu then it's unclear why you even care about rewriting non-master history :)
20:15 trs because I'd prefer not to rewrite history if it's easy to avoid.
20:15 haarg i don't think either way is universally better, but merge conflicts are certainly not always easy to look at
20:16 trs haarg: agreed.
20:16 haarg at some point i'll try out git-imerge. seems like a nice solution to some of these problems.
20:16 mst basically, if you do 'always rebase', history has a consistent shape that allows you to figure things out just fine
20:16 mst and having any conflict fixes inlined with the specific change that caused the conflict makes it a lot easier to see what was going on than a merge commit, at least for me
20:17 trs mst: what problems are you saying don't actually exist in practice?  it's true I've not worked on a large project where rebasing before every merge was the norm.
20:17 mst trs: I've never needed to do the 'comparing two trees with topic-diff'
20:18 trs it may sound like I'm advocating for "never rebase", but it's really "prefer merges to rebasing, until the scales tip"
20:18 mst trs: you're describing it from seeing the project through a lense of being used to merges
20:18 mst lens
20:18 mst most rebases are clean, and just make the final commit clearer
20:18 mst and those that aren't, you basically end up with a new version of the branch, written 'as if' it had come from latest master
20:19 trs so if the rebase isn't clean, you'd still basically delete/repush or force push the branch for re-review before merging?
20:19 mst so "what changed with conflicts is much harder to see" doesn't make any sense, because the whole point is to get to a stage where it's as-if the conflicts never happened, and therefore when people are looking back they don't need to pay attention to that at all
20:20 mst i.e. you don't need to be able to see it at all
20:20 trs I thinkI see your point: if the merge isn't bad, the rebase isn't bad either.
20:20 mst so the fact it's harder to see it becomes irrelevant
20:20 mst and, yes, I usually make people rebase to current master *before* review
20:20 trs but with the rebase, you rewrite history necessarily and merge you don't.
20:21 Mithaldu trs: the history only matters if other people work off it, and it's generally a tremendously bad idea to start working off someone's feature branch
20:21 trs ah, the point I mean with "what changed with conflicts" is exactly "this branch I'm about to merge is no longer what was reviewed"
20:21 mst right, you rewrite history such that future maintainers don't need to even care there was a conflict, thereby simplifying future maintainance
20:21 mst whereas a merge pushes the additional overhead of needing to care about that into the future, every time somebody looks at the code
20:21 mst rather than doing it once in advance
20:21 trs nod.
20:22 trs Mithaldu: or if things, like your review discussion, refer to shas.
20:22 mst trs: right, but again, you're talking about things that happen in a merge-based workflow and that you *don't do* in the workflow we're describing
20:23 Mithaldu i've honestly never been in a situation where that mattered
20:23 mst right
20:23 Mithaldu and i think at this point i've been gitting over 5 years
20:23 mst again, you're mapping the merge-based process onto the rebase-based process and then worrying that things that are normal in a merge-based process won't work ... well, no, it's a different process, you don't do that :)
20:25 trs mst: so if someone rebases their branch, submits to you for review, and then before it's merged someone else merges another branch, the thing needs another rebase and review?
20:26 Mithaldu or you do it yourself
20:26 trs I'm just trying to understand the process here and why it doesn't fuck up things refering to history that are external to git.
20:26 Mithaldu i've often had my feature branches cherry-picked in by the maintainer
20:26 trs Mithaldu: do you only work with github's review features?
20:26 trs Mithaldu: or are you working in more ad-hoc systems too?
20:26 Mithaldu plus, to make you happier: cherry-picking leaves the original commits and even notes their shas
20:26 Mithaldu trs: i've worked with almost everything
20:26 trs Mithaldu: refering to shas is very common for me in my experience.
20:27 Mithaldu give me an example pull request?
20:27 mst trs: I don't generally use the github shit, I do it the old fasgioned way
20:27 trs mst: same.
20:27 Mithaldu like, i used github to leave notes to people on their commits
20:27 Mithaldu and after they did their changes the notes were not necessary anymore
20:27 mst trs: and, yes, *if* there are conflicts, you'd re-review the commits that included conflicts being handled
20:27 Mithaldu so the fact that history changed was irrelevant
20:28 mst trs: that's the equivalent of reviewing the conflict parts of a merge comment
20:28 mst s/comment/commit/
20:29 Mithaldu trs: also, if a reference to history is necessary, you can throw a keeper-tag or branch tip on that branch, and then rebase
20:29 trs Mithaldu: I don't have an example PR because I don't use github for review, generally.
20:30 Mithaldu well any example of a sha reference that is important to keep around would be nice :)
20:30 trs Mithaldu: but shas go into my commits regularly, for example. and if you rebased a branch where I referred to a previous commit, it'd be wrong.
20:30 Mithaldu right, i'd like to see that
20:30 trs most of the time they refer to commits earlier than the merge-base, but not always.
20:30 haarg if you use github PRs a lot, it makes more sense to stick closer to their encouraged workflow
20:31 trs haarg: yes, I've noticed that.
20:31 Mithaldu trs: equal parts because i think worry about that can be dispelled, and because i'm curious due to never having seen that :)
20:31 haarg i don't see a big problem with merges that have no conflicts (and no excessive merges into the branch)
20:31 trs Mithaldu: you'd like to see an example of where I shot myself in the foot because I referred to a commit and didn't rewrite the message when I rebased a branch?
20:32 Mithaldu sure
20:32 haarg generally i'd kick a PR back to the submitter to rebase if there were conflicts though
20:32 trs Mithaldu: it'd be annoying to find, but I know they exist in rt.git, for example.
20:33 Mithaldu so you're saying those cases are quite rare? :)
20:33 trs _because_ of the merge over rebase process. :)
20:33 jibsheet they're rare because we don't rebase RT branches that often
20:33 trs they're only possibly introduced if you rebase.
20:33 trs by definition.
20:33 Mithaldu ok, now i lost the read thread
20:34 Mithaldu *red
20:34 Mithaldu trs: i'd be fine with *any* commit where you referred to a sha
20:34 Mithaldu or any reference whatsoever
20:34 trs Mithaldu: hold please.
20:34 Mithaldu whee
20:34 jnbek joined #metacpan
20:35 haarg if you rebase, then the old sha will either refer to something nonexistent or not useful
20:36 trs Mithaldu: stupid example, but written yesterday: https://github.com/bioperl/bioperl-live/commit/5893bb4
20:36 dipsy [ Tell Storable to freeze and thaw CODE refs · 5893bb4 · bioperl/bioperl-live · GitHub ]
20:36 Mithaldu oh god bioperl
20:36 Mithaldu i didn't ask for this ;_;
20:36 trs yes, it's true.
20:36 trs ;)
20:36 * trs only has 4-5 commits in bioperl
20:36 trs for things I ran into
20:36 Mithaldu my sympathies
20:36 jnbek^dt joined #metacpan
20:37 trs Mithaldu: also https://github.com/jonas/tig/commit/a2887de
20:37 dipsy [ Allow overwriting of a previously set "argv" option · a2887de · jonas/tig · GitHub ]
20:37 * Mithaldu realizes clicking "network" on bioperl is a bit futile
20:37 trs https://github.com/jonas/tig/commit/c622b9e
20:37 dipsy [ Don't clear the status/report line when finishing a piped update · c622b9e · jonas/tig · GitHub ]
20:38 trs I include shas often. they are not always on the current branch, of course.
20:38 trs (and so not always susceptible to rewriting by a rebase-driven process)
20:40 Mithaldu trs: ok, it's honestly as i expected
20:40 Mithaldu so here's the situation
20:40 Mithaldu you're referring to historical commits
20:40 Mithaldu stuff that's way in the past of published history and long-deployed and released
20:41 Mithaldu now the thing is, you're never in any risk of having those rebased away from under you
20:41 Mithaldu because we're talking about rebasing feature branches, not master
20:41 Mithaldu and if, by chance
20:41 mst trs: it sounds like you're saying "I make commits referring to an unreviewed, unmerged branch, and then it's somebody else's fault if the version of that branch that finally merges doesn't contain that commit" ? that doesn't seem logical to me, what am I missing?
20:41 Mithaldu you are referring to a recent feature branch
20:42 Mithaldu then you would be asked to rebase your branch because that one was rebased, realize that happened, and adjust your commit message
20:42 mst I wouldn't do that in a merge-based project because it's totally possible for a branch to be wiped, abandoned, and started again
20:43 Mithaldu mst puts it better than me
20:43 trs Mithaldu: if you read what I wrote, I admitted my examples were not an example of what you wanted, but what you asked for.
20:43 trs mst: commits on the same branch.
20:43 trs mst: not cross branches.
20:44 mst oh, well, in that case I'd be fixing it up with an amend as part of the rebase
20:44 trs which I guess you wouldn't do on a rebase-driven process because you'd be constantly fucked.
20:44 mst if you don't bother doing the rebase properly, then, yes, it's going to suck
20:44 trs so basically the rebase isn't easy then, because you have to audit the commit messages now too.
20:44 trs or automate it.
20:45 trs you either have to remember in which commits you referred to other commits, or you have to grep through them to find out.
20:45 mst well, generally I refer to commits in the same branch by commit message rather than sha
20:45 trs that's another tactic :)
20:47 mst like I say, I strongly feel like you're taking things that only make sense to do *because* you're using a merge-based workflow, then complaining that that specific approach doesn't work in a rebase-based workflow, rather than considering how you'd achieve the same *goal* in a rebase workflow
20:47 mst do you see what I mean?
20:49 trs yes.
20:51 mst There's More Than One Way To Do Git :)
20:51 Mithaldu trs: maybe you just need to contribute to Moo or Web::Simple for a while :)
20:51 trs heh
20:52 * trs has at least one commit in Web::Simple ;)
20:53 Mithaldu half the way there then!
20:53 mst trs: plus, we generally do a very fast review cycle
20:53 mst i.e. somebody will say "are you available to review X?"
20:53 mst I say "yes"
20:53 trs mst: that helps, no matter what process you use.
20:53 mst they rebase it then and there, force push it, I review it, it merges to master
20:54 mst if there's another branch to be reviewed, repeat at that point
20:54 mst so there's very rarely a need to go "ohshi-, master changed, have to redo everything"
20:54 Mithaldu i'll also continuously keep rebasing my branches while other development happens and while my own happens
20:54 mst except when a branch failed review the first time, in which case you needed a new review later anyway
20:54 trs in my experience, reviews are more back and forth and to save time as the reviewer, it's useful to see only what changed between rebases (hence git topic-diff)
20:54 Mithaldu one of my current clients adds 40 commits to master per day, so i need to keep up
20:55 Mithaldu my branch would be an utterly useless mess if i did that by merging master into mine
20:58 trs mst: previously when confronted with "doing X sucks if you rebase", people said "don't do that" instead of "yes, but I do Y instead to reach the same goal".  so, thanks.
20:59 trs Mithaldu: if there's lots of churn, sure, but you could also avoid most of those rebases and the merge might be just fine.
21:00 trs Mithaldu: obviously it depends on how stable master is, regardless of how many commit it see.s
21:00 Mithaldu i was mainly pointing out the difference between the methods of keeping up by merging in master, vs. rebase
21:00 Mithaldu i'm sure you've seen those branches with 3 commits that had master merged in 20 times :)
21:00 trs I _don't_ generally have to merge in master, because keeping up isn't necessary.
21:02 Mithaldu well, in my case the activity also serves as a canary
21:02 Mithaldu i really don't want to review 40 commits
21:02 trs I have seen those and they can suck, but there are also tools for dealing with them (--first-parenT)
21:03 trs the branches with 3 commits and 20 merges to master.
21:03 trs s/to/from/
21:03 Mithaldu so it's easier to just rebase and see if anything complains, or my tests start failing, or some of my commits look significantly different
21:03 Mithaldu i'd rather just keep up good development practices and not have to get out the emergency tools
21:03 trs you can do the same by merging to master and then backing it out :)
21:04 trs --first-parent isn't emergency tools.
21:04 trs it's basic git log usage.
21:04 Mithaldu also see: http://en.wikipedia.org/wiki/Broken_windows_theory
21:04 dipsy [ Broken windows theory - Wikipedia, the free encyclopedia ]
21:04 trs but maybe it's not basic usage if you never have to think about merges.
21:04 Mithaldu well merging to master and backing out doesn't result in less delta between me and master on the next day
21:05 trs who cares? there's git rerere
21:05 Mithaldu i generally don't :)
21:05 Mithaldu who casres about what?
21:05 trs the whole point is "don't rebase until the delta matters"
21:05 Mithaldu i find that silly
21:05 trs so who cares if there's more delta the next day?
21:05 Mithaldu rebase to keep the delta always at a trivial level
21:06 Mithaldu if the delta matters, something went wrong
21:07 trs the point with merging is that you can ignore the delta unless you really want to know.
21:07 trs I guess you're doing the same thing with rebasing, but you ignore it by constantly paying attentino to it in the form of rebasing. :)
21:07 Mithaldu i read that as: "you will ignore it, until it bites you in the ass"
21:08 Mithaldu that's what i meat with defensive coding ;)
21:08 trs except it doesn't, and if it is a problem, you notice and either merge in master or decide it's time to rebase.
21:08 Mithaldu adopt practives that protect myself from my own laziness
21:08 trs I know what defensive coding is ;)
21:08 Mithaldu uh, yes, it does bite me in the ass, it did in the past.
21:09 Mithaldu work on a feature branch while others work, and then end up spending 3 days to fiddle out the delta after it was "done"
21:12 trs so in that case it sounds like master was not a very stable target. rebasing makes sense. that arithmetic depends on the stability of master, like I said, which is not necessarily just how many commits it sees.
21:12 Mithaldu you're still not seeing the point:
21:13 Mithaldu in the bad case the practice protects me, in the normal case it costs me nothing
21:13 haarg Mithaldu: it's possible for people to understand you yet still disagree
21:14 trs Mithaldu: I think we're just disagreeing on the value weight of various terms in the equation.
21:14 Mithaldu possibly, in that case i'd just give up thought because i cannot grok how that person's mind works
21:15 Mithaldu -t
21:23 sivoais joined #metacpan
21:44 rashi joined #metacpan
22:13 grantm joined #metacpan
22:52 ether wow long git discussion.  fwiw I'm in Mithaldu/mst/haarg's camp: it's best to rebase before a merge. but there are levels of badness: least bad is not rebasing a merge of a branch that didn't have any conflicts. more bad is not rebasing a branch that did have some conflicts (so the merge commit ...
22:52 ether ... is not empty). but worst of all IMO is a project branch not rebasing away all the "merging master into my branch" commits. NO ONE else needs to see those, and it makes the mainline commit history incredibly horrible.
22:53 ether on github, you can add an entry in .git/config for the 'pulls' remote spec, and every PR gets its own branch in there, like pulls/1, pulls/2 etc, so you can rebase a PR on your own local box before merging it, rather than bugging the submitter
22:54 Mithaldu ether: cheers :)
22:54 haarg i wonder if github would consider adding a separate ref spec for open PRs
22:54 ether I also strongly prefer PRs that keep related changes in the same commit, so I'll often kick back (or fix up myself before merging) a PR that has lots of commits like "fixing typos from last commit", "fixing release tests from last commit" etc. those should all be squashed together.
22:56 Mithaldu yeah, i've had a few PRs that were more "oops" commits than actual changes
22:57 ether I've found that companies are a lot more lax about this (who wants to tell the lazy developer to do it right?) than open source projects :)
22:57 ether I learned all my useful git skills from open source - a lot of them from people in this channel :) - than from paid work
22:57 ether my first serious git work was working on moose actually
22:57 Mithaldu i suspect that's because many companies have at most one good developer, and he's too busy getting work done than to try and politely tell the rest of the company they're being shithead
22:57 Mithaldu s
22:58 ether and that's a big enough project that it forced me to learn all the big stuff like managing branches, interactive rebasing etc
22:58 ether heh
22:58 Mithaldu while all the good devs do open source in their free time or when they can justify it as work
22:58 ether +1 "when they can justify it as work"
22:59 ether I've got a few work projects earmarked as "this give me an excuse to get back to Module::Metadata hacking" etc :)
22:59 ether and I always cheer when a coworker reports a bug against something I maintain, because I can then spend some work hours on it
22:59 Mithaldu haha
23:00 Mithaldu THAT's why you get so much comaint
23:00 ether just after I started at this job, I noticed that my manager had a 2-year-old open bug on local::lib - I made sure to fix that one really quickly :D
23:00 ether it was marked critical even
23:01 haarg was that the taint stuff?
23:01 ether yeah
23:01 * trs has seen a lot of open source projects with some pretty terrible scm practices.
23:02 trs I'd be hard pressed to say proprietary projects are worse off than open source projects on a whole in that regard.
23:03 trs It depends a lot on where you've worked and what open source projects you contribute to. :)
23:03 * ether seems to have gravitated to the ones populated with other ornery and anal people o/
23:04 ether it's almost as if the type of project influences the type of people attracted to it :)
23:04 Mithaldu trs: typically products have worse devs than infrastructure tools
23:05 Mithaldu also, bio engineers write the worst perl :v
23:05 ether except leont!
23:05 Mithaldu leont is in bioeng?
23:05 ether I thought he was in molecular biology?
23:05 Mithaldu gonna have to poke him sometime
23:06 Mithaldu but ether, have you looked at BioPerl.pm?
23:06 ether not lately
23:06 haarg scientific code is often really bad
23:06 Mithaldu it makes me sad everytime i think about it
23:06 Mithaldu i once wrote a tool to find bad code
23:07 Mithaldu and i had to make it filter out bioperl to get anything else in the top 20
23:09 ether that's what happens when the program is seen as a means to an end, rather than the end in itself :)
23:09 ether me, oftentimes I care jack-shit about the actual application - I just want to write good code :)
23:09 ether which is why I'm in the corner rather than designing products
23:10 Mithaldu ether: bio engs aren't actually at fault
23:10 Mithaldu you can trace it back to the bioperl programming book
23:10 Mithaldu they learn from that
23:10 haarg in terms of "makes me sad everytime i think about it" my favorite is Class::MethodMaker
23:11 Mithaldu and it teaches them to write print <tr><td> in their fetchrow loop
23:12 haarg initial lib: 116K   blib after make: 22MB
23:15 Mithaldu what in the christ
23:15 Mithaldu how does that happen
23:15 trs "dzil" ?
23:16 trs Mithaldu: there's a lot of crappy code in lots of good languages in the bio world.
23:16 Mithaldu no dzil involved
23:16 haarg from what i can tell, it generates the code for every combination of options you can give it
23:16 haarg each as a separate sub
23:17 Mithaldu haarg: how very demoscene :D
23:17 trs it's written by people who, as ether pointed out, care about the end result and historically haven't been given good reasons to care about the quality of the software as long as it mostly works.
23:17 Mithaldu trs: tbh, it's not a lack of caring, in my experience it was just a lack of knowing
23:17 trs dzil was at haarg's comment.
23:18 ether Class::MakeEveryCombination::AndThenSome
23:18 trs sure, there's both though.
23:18 Mithaldu one project i was on the guys picked up good practices VERY quickly once i told them what they were
23:18 Mithaldu trs: yes, and i was answering that after looking at C::MM :)
23:18 haarg it depends on the person and the project
23:18 haarg a lot of scientific code is viewed as one off scripts
23:19 haarg so people see little reason to care about how readable or maintainable it is
23:19 mst trs: btw, if I didn't make it clear, I'm not saying your approach is -bad-, just that overall I believe the approach I've been describing is -better-
23:19 mst trs: the way you do it is the way a lot of our client projects work, and while it makes history significantly harder to work with, with reasonably disciplined developers it still works ok
23:20 trs mst: nod.
23:21 haarg it can also depend on the scale of the project.  if you are getting tons of PRs, always requiring they be rebased on master before merge can be a problem.
23:21 haarg of course, having them merge cleanly without conflicts is usually still better
23:21 mst yeah, although of course in terms of CPAN stuff if that starts to happen, you probably should've split it into multiple dists already
23:22 haarg yeah
23:22 neilb joined #metacpan
23:22 haarg things like rerere help managing merge conflicts, but it doesn't scale at all
23:23 trs rerere is useful for rebasing too :)
23:23 haarg yes
23:23 haarg but again, doesn't scale.  it's local only.
23:23 trs I've done a crazy thing where I rsynced my rerere stash into another repo.
23:23 trs it was crazy.
23:23 trs but it worked! ;P
23:24 haarg wc -l lib/Class/MethodMaker/hash.pm: 130717
23:24 haarg such an awful module
23:25 Mithaldu haarg: i love how there are whole blog posts in the comments
23:25 Mithaldu (at least as far as word coutn is concerned)
23:26 haarg it was probably the first module that made me pay attention to the code i was getting off cpan
23:27 Mithaldu https://metacpan.org/source/SCHWIGON/Class-MethodMaker-2.21/components/hash.m
23:27 dipsy [ components/hash.m - metacpan.org ]
23:27 Mithaldu a beauty
23:27 Mithaldu i guess working on windows has exposed me early to the seedy underbelly of cpan
23:28 haarg well, that was in 2002 or so
23:28 haarg in windows
23:28 haarg using mod_perl 1.99
23:28 haarg fun times
23:28 Mithaldu i got that to work once on windows
23:38 trs I don't pull it out often, but when I do, I ♥ Regexp::Debugger
23:39 trs it's even gotten better since last time I used it.
23:39 Mithaldu i get way too few excuses to play with it
23:40 trs in this case my problem was I forgot %+ is dynamically scoped, but :)
23:45 ether Class::MethodMaker sounds *almost* as long as Rose::DB::Object!
23:45 ether schwigon was at Lyon, too..
23:46 * ether was on the ->Paris flight with him and his girlfriend when we left

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