06:04 <fijal> 8:03 AM <fijal> ok, git question

06:04 <fijal> 8:03 AM <fijal> so merge, browse the diff *then* commit?

06:04 <fijal> 8:03 AM <fijal> how do I see what's the diff between branches?

06:08 <LarstiQ> diffing between branches I usually do `git diff branch1..branch2` or `git diff branch1...branch2` depending on whether I want to see changes from the merge base

06:09 <LarstiQ> if you have locally done a `git merge` but not commmited that yet your working tree has additional changes, I don't often compare that to another branch but I'd guess that is `git diff branch`

06:10 <LarstiQ> (the reason for guessing is that there are 3 things to diff with, local working dir, local staged changes (index), and latest commit in the branch you've checked out, I always have to look up how to distinguish)

06:10 <LarstiQ> fijal: does that help?

06:10 <fijal> I don't know

06:10 <fijal> if I do git merge --no-commit

06:11 <fijal> and then do "git diff", it shows empty

06:11 <fijal> or do I need to do "git diff branch"?

06:11 <fijal> LarstiQ: ?

06:12 <LarstiQ> fijal: what do you want to compare it against, see what you're going to commit?

06:14 <LarstiQ> fijal: is `git diff --cached` non-empty?

06:14 <fijal> yeah

06:14 <fijal> --cached did the job, thank you

06:14 <fijal> LarstiQ: is there any logic behind it?

06:15 <LarstiQ> fijal: yeah, it's due to git's index, the area of staged changes

06:17 <LarstiQ> so if you incrementally `git add` stuff to be commited, your `git diff` will shrink and your `git diff --cached` will grow

06:18 <fijal> "ah"

06:18 <LarstiQ> not sure what the best writeup about that is, https://gitolite.com/uses-of-index.html is a random search hit

06:18 <fijal> thank you

06:20 <LarstiQ> I personally mostly use it similar to github's marking a file as viewed (but on the level of diff hunks), to keep track of what I already know is good vs what I still need to look at it

06:21 <LarstiQ> as well as a rebasing tool to split and reverse commits

06:21 <LarstiQ> fijal: np, glad to be of help

07:15 <mattip> tumbleweed: this is the first time I have seen an announcement like that

17:42 <Corbin> I miss polymorphic recursion. Is there a way to let a subclass vary in its return type? Like, to have polymorphic visitors? Or do I need to use a class-maker pattern, ala make_timsort_class(), for every new return type?

17:45 <Corbin> ...Oh, I can work around it for now. I still miss it, but that's just a feeling.

17:45 <krono> Corbin: in pypy or rpython?

17:46 <Corbin> krono: Oh, sorry, in RPython. In PyPy, we have standard duck-typing idioms and we can do e.g. tagless-final encodings or polymorphic visitors without any extra effort.

17:47 <krono> yeah, i wondered. i missed that, too

17:48 <krono> some things are painful, esp if you come from a smalltalk background xD

17:49 <Corbin> It's certainly a curious environment. First-order structures, but an unlimited amount of one-time codegen and metaprogramming too. I could analogize it to OCaml, Haskell, Java, C++, etc.