05:29 <LarstiQ> antocuni: no, still don't get the named branch

07:18 <cfbolz> LarstiQ: the real difference is that every commit knows the name of the branch it was made to in hg

07:44 <fijal> ronan: what's iterative?

07:44 <fijal> I really refuse to google a name like that

08:01 <LarstiQ> cfbolz: right, but there wasn't enough context for me to understand why that would matter. This might be something I'll never understand, or then if I sit next to antocuni while he demonstrates the lightbulb finally goes on

08:21 <cfbolz> LarstiQ: 1) blame a file 2) look at one of the involved commits 3) see which branch that commit was from 4) look at all the commits of that branch and understand the context of the work much better

11:11 <ronan> fijal: yeah, it's hard to google. It's https://iterative.ai/ - I'm working on https://dvc.org/

11:20 <fijal> I think startups run a competition who can have the least googleable name

11:20 <fijal> ronan: cool!

12:36 <LarstiQ> cfbolz: I now realize that might make quite a difference in projects where they do fast forward merges and you don't have merge commits delineating what the branch is, is that the secret ingredient? Or is it just that "filter on branch name" is faster than "look at all commits between branch-off and merge"?

12:40 <antocuni> LarstiQ: I think that being able to "filter on branch name" is a massive plus. For example, in pypy we had several branches which were developed for months, regularly merging from default

12:41 <antocuni> so "all the commits between branch-off and merge" doesn't work in that case

12:48 <Dejan> cool indeed

12:50 <LarstiQ> antocuni: aha, so long lived branches syncing. Yeah ok, that's not something I ever do (these days), so that explains why I'd not encounter the need

13:23 <antocuni> a hint that this is a desired feature is that if you look at commit history on github, it displays the PR which each commit belong to. Assuming one-PR-per-branch this is roughly equivalent to mercurial named branches

13:24 <antocuni> but this is *github* metadata, not git

13:24 <LarstiQ> right, afaik that uses the merge point information to construct that

13:25 <LarstiQ> (having the commit be part of multiple PRs also works I can confirm ;)

15:22 <phlebas> unpack_sequence in the pyperformance suite seems to slow down over time on pypy (and then pyperformance complains it cannot calibrate number of warmups, because over 300 warmup iterations, it goes up from 200ns to 700ns). i haven't investigated, yet, do you think it's worth it (the benchmark seems pretty micro)?

17:05 <cfbolz> phlebas: yeah, sounds like somebody should take a look

19:40 <phlebas> cfbolz: ok, I'll see if i can find something to fix :)