Time Nick Message 00:58 MTDiscord Ah yes, 0ver, the best example of what you might call "1.0 syndrome" or "software self consciousness" 08:14 MTDiscord I plan to switch modlib to semver once I have removed the deprecated stuff 17:43 MTDiscord At this point I'm probably going to switch to CalVer for my stuff since its all incrementally developed over time 17:49 MTDiscord I use a 2-segment CalVer variant for NodeCore: - 17:53 erlehmann mineclonia is at 0.71.0-142-g45cdad728 right now 17:53 erlehmann maybe we should, dunno, make a release or something 17:53 MTDiscord I mean, just using commit hashes also seems reasonable to me, and then maintaining a semi well tested master branch where things get merged when their ready. 17:53 MTDiscord commit hashes aren't comparable 17:53 MTDiscord only equatable 17:54 MTDiscord But then I'd want to make each PR atomic via squashing too, so maybe not a great idea 17:54 MTDiscord That's also true 17:54 MTDiscord calver isn't great either, necessarily, since if you have more than 1 release within your calendar granularity, you can run into a situation where you rely on the commit hashes to disambiguate 17:54 MTDiscord A date of when a given version is from immediately tells you how out-of-date it might be 17:55 MTDiscord that's only happened like a few times ever out of like 2500 though, so... 17:55 erlehmann > make each PR atomic via squashing 17:55 MTDiscord i would be nice to use git hashes for versions, but you cant access the game dir cause mod security, mods, you can 17:55 erlehmann that is about the worst idea i have seen 17:55 MTDiscord *it 17:55 erlehmann in practice 17:55 erlehmann it makes it very hard to use git bisect 17:55 erlehmann because you get this huge squash commit 17:55 MTDiscord I'd have used yyyymmddHHMM but that just seemed like an awful lot of digits ... but I could probably switch to it if I really wanted to 17:55 MTDiscord I can't squash for religious reasons anyway 17:56 MTDiscord I mean, generally PRs are from one person, but yeah big PRs do then get a bit unmanageable 17:56 erlehmann it's not about if they are from one person, it is about the granularity of changes 17:56 erlehmann what if you want to revert only a part of a big change? maybe the buggy part 17:57 erlehmann also porting changes is harder then 17:57 erlehmann i have had this problem while fixing stuff from mcl2 that we inherited in mineclonia 17:57 MTDiscord Commits being too fine-grained are rarely a problem, you can treat multiple commits as a unit, fast-forward/rewind across them, or post-hoc squash them, if needed. Commits being to coarse-grained are irrevocable though. 17:57 erlehmann and mineclonia had the issue itself (bisecting arrives at a large rewrite that was squashed or never separate commits to begin with) 17:57 MTDiscord The solution, of course, is properly atomic PRs rather than smashing several things together, but at that point you can also just commit atomically too. 17:57 erlehmann what Warr1024 says 17:57 MTDiscord I have never regretted too many commits, but have often regretted too few. 17:58 erlehmann Benrob0329 a PR can be a logical change that entails many physical changes 17:58 MTDiscord For PR atomicity, you can just use --no-ff to ensure that you have a clean record of the fact that a merge was done at this point. I do that sometimes, though in other cases I just let the FF occur. 17:58 MTDiscord Well yes, so yes. 17:59 MTDiscord I usually merge multi-commit topic branches (when I create them) with --no-ff, but I usually merge from dev to master using --ff-only. 17:59 erlehmann for example, i have an open WIP PR on mineclonia regarding “mobs in minecart”. it exposed a bunch of bugs, for example, that weird things happen if the driver of a minecart manages to die. 18:00 erlehmann this stuff was always a bug, but it was very hard to trigger without mobs in minecarts 18:00 erlehmann a player would have to die in a minecart and then respawn while the minecart is in an active block 18:00 MTDiscord The rule is usually "X early and X often" for any X that you're supposed to do in the first place :-) 18:00 erlehmann now, when i killed a mob in a minecart … 18:00 MTDiscord I get what your saying, and I agree. Full-squash is bad. 18:01 erlehmann i do ofc squash and reorder and separate commits with “git rebase -i” to get a nice history for my PR 18:01 erlehmann one where you can see each feature being built up 18:01 MTDiscord I always prefer to keep the history as it unfolded, in as much detail and accuracy as possible. Any kind of "cleanup" you want to do to make it look pretty can just be done post-hoc anyway, but destructive changes can't be undone. 18:01 erlehmann Warr1024 the cleanup in my case is a refactoring 18:01 MTDiscord I'm just saying that I'd be tempted to if maintaining a stable master branch, but I'm tempted to to many things so its just a footnote. 18:02 erlehmann for example, a friend starts a PR and abandons it. i take it, add some changes to it that she mentioned, build on top of that. 18:02 erlehmann but ofc if she only mentioned and never implemented the changes i have to amend her PR 18:02 erlehmann i mean amend her commit 18:02 erlehmann and make a new PR 18:02 erlehmann sorry 18:03 MTDiscord Not modifying history for me includes no commit reordering. A + B might be the same as B + A in the end, but A and then B takes a different route than B and then A, and that basically means that the intermediate commit is a lie, describing a state that the code was never actually in, and your ability to infer anything from code history is going to be limited if it contains lies. 18:03 erlehmann oh 18:03 erlehmann i want each commit to be buildable 18:04 erlehmann if i make an A + B change and realize that with A, but without B stuff is broken, i will reorder, if with B, but without A, it is not. 18:04 MTDiscord If you reorder a "fix minecart behavior" commit that was originally after "add mobs to minecarts", then you now lose the understanding of the fact that "add mobs to minecarts" was what led you to discover the need for the fix in the first place. 18:04 erlehmann no i write that in the commit messages 18:04 MTDiscord The one thing I do is avoid merge commits, because when you purposefully go through PRs for everything having a lot of small changes with 2 commits each is stupid. 18:04 erlehmann lol 18:04 erlehmann merge commits are very important 18:04 MTDiscord I prefer all my commits be buildable/working, but it's more important to make a commit when one is needed than it is to have only pretty commits. If I need to make a known-broken commit because I've got too much pending work burning a hole in my disk, I'll make a "checkpoint" commit, which I usually mark as such in the commit message. 18:05 erlehmann maybe you underestimate my commit messages 18:05 MTDiscord I end up with a lot of merge commits, especially when my push/pull discipline slips and I end up working on the same project on multiple machines and they diverge and need to reconverge. 18:05 erlehmann i quote one 18:05 erlehmann > Do not rotate a boat while it is attached 18:05 MTDiscord It's one of the reasons why I run into a lot of "only happens on a larger dev team" kinds of situations on solo projects. 18:06 erlehmann > Rotating a boat while it is attached to another object does not work as expected: While the boat does not visually rotate, the head of the driver rotates as if the boat did actually rotate. That looks wrong, therefore no rotation must happen if the boat is attached to an object, e.g. a minecart. 18:06 erlehmann it is immediately obvious that a) the bug was always there b) no one attached a boat to anything before 18:06 MTDiscord Heh, your commit messages look like mine 18:06 erlehmann c) i have to fix this for the boat to work properly in a minecart 18:06 MTDiscord I'm not nearly that disciplined with commit messages 18:07 erlehmann maybe you should be 18:07 erlehmann if i had these kinds of commit messages from others, i would be way faster at bugfixing 18:07 MTDiscord Mine are usually "File/Topic - Fixed X bug" 18:07 MTDiscord Commit message discipline is important to me. The "product" that I release isn't just the finished compiled code, or the source, or source and documentation, it's the entire repo, including metadata. 18:08 MTDiscord I actually hate commit messages that are like "Fixed bug 47" because that requires me to look up a bug in some bug database that may not even exist anymore... 18:08 MTDiscord Sometimes I'll say a given commit leaves the code in a broken state if I'm working from a dev branch and need to push 18:09 MTDiscord I don't mean an issue number, I mean an actual bug description, just a short one 18:09 MTDiscord My convention for broken state is the "Checkpoint: " prefix in the message subject. Not my idea, I inherited that from someone at a past job. 18:09 erlehmann example: the commit “Slightly tweak minecarts to be more MC-like” broke minecarts in mineclone2. the commit that reverts most of that contains a list of both all the bugs that caused and a list of all the stuff that had been tested to work after the revert. just so no one asks questions. 18:10 MTDiscord I really relish being able to succinctly describe the whole change in the 50-char subject line, but I feel like I rarely get away with that. Even if I can say WHAT in that space, it often takes a lot to say WHY. 18:11 MTDiscord I once had to fix a problem that was apparently fixed by reverting a 6-month-old commit where the only commit message was "this is giving me a headache." We had no idea why the change was made in the first place, nor what kind of implications of reverting it we would need to watch for. Good commit messages matter. 18:11 MTDiscord We still had access to the original dev, and of course, he didn't remember any of it eithre. 18:11 MTDiscord To be fair, I've never programmed in a professional context so I'm learning good practices as I go, my commit style and discipline has changed over time as I've learned or seen things that seem better than what I'm currently doing. 18:12 MTDiscord Ironically my personal standards for source control are generally stricter than the standards I've seen in professional contexts... 18:13 MTDiscord Like, it took a lot of work to get close to the official conventional standard for git commit messages, and often the 50 char subject line is a struggle. 18:13 erlehmann in comparison, commit messages “Do some calculating”, “Fix #1204”, “Fix #1192”, “Fix #1200”, “Fix #1188”, “Implement #1099”, “Cleanup”, “Refactor some stuff in mcl_explosions” are entirely useless 18:13 ShadowBot https://github.com/minetest/minetest/issues/1204 -- Use narrow_to_wide in gettext instead of os dependent conversion fct by sapier 18:13 ShadowBot https://github.com/minetest/minetest/issues/1192 -- Fix lost change password button by sapier 18:13 ShadowBot https://github.com/minetest/minetest/issues/1200 -- Add support for exiting formspecs by doubleclicking outside by sapier 18:13 ShadowBot https://github.com/minetest/minetest/issues/1188 -- getTime refactoring by selat 18:13 ShadowBot https://github.com/minetest/minetest/issues/1099 -- Texture packs with "[" in the name causes the Texture Packs menu to not draw. 18:13 MTDiscord OOF, even the bot is triggered by that. 18:13 erlehmann lol 18:13 erlehmann those are not even the issues that i mentioned 18:13 erlehmann because it was mcl2 commit messages 18:14 erlehmann hey bot, #0 #-1 #9999999 18:14 ShadowBot erlehmann: Error: That URL raised 18:14 ShadowBot erlehmann: Error: That URL raised 18:14 erlehmann good bot lol 18:14 MTDiscord yeah, the bot is a bit sensitive :-) 18:14 MTDiscord I see a lot of bot-triggering whenever someone says something like "the number one issue is..." but use the # instead of "number"... 18:15 MTDiscord I think issue #1 in MT itself is actually something kinda silly (especially today) so it's extra non-sequitur. 18:15 ShadowBot https://github.com/minetest/minetest/issues/1 -- GlowStone code by anonymousAwesome 18:15 MTDiscord Yeah, that one. I see that one a lot. 18:17 MTDiscord At the end of the day none of it matters if I forget to check my Github for months at a time anyways, so I'm in the clear /s 18:18 erlehmann what 18:18 erlehmann exactly when you forget to check it matters 18:18 erlehmann if your commit messages were good in the first place 18:19 erlehmann can anyone point me what changed about wieldview between 5.4 and 5.5? 18:20 erlehmann do we have a new dupe by now? 18:20 erlehmann i really need to mess up the catlandia economics! xD 18:40 MTDiscord erlehmann: "Code cleanup" is not a useless commit message 18:47 rubenwardy It could be more specific 18:47 rubenwardy Both on code area and what cleanup was done 18:48 rubenwardy But it's fine if it's all the code and all the cleanup ™ 18:54 MTDiscord If the only effect is stuff that's internal to the code, then I don't describe area if it can be inferred from a git log --state 18:54 MTDiscord er --stat 19:48 rubenwardy git messages are for easy reference. You could make all git messages random text, and "infer" the change from the content. But that's not very useful 19:50 MTDiscord I believe you mean HAAAAANDS 19:50 Krock relevant: https://xkcd.com/1296/ 19:51 rubenwardy there may or may not be a commit by me with HAAAAANDS as a message in a project at work 19:51 rubenwardy in the master branch, shipped to the client 19:51 rubenwardy I made it in a PR, they didn't click squash when merging 19:52 Krock except that the client might not have any commit history 19:52 rubenwardy the client has the full git history 19:52 MTDiscord Actually the thing that bugs me the most about that xkcd is that the commit graph is upside-down 19:52 rubenwardy but I doubt they'll be checking the git log that much 19:52 Krock needs more HAAAAAAAAANDS in this case 19:53 Krock yes, that's kinda confusing indeed 19:53 Krock but kinda required to set up this "joke" 19:54 DS_ `$ xrandr --output eDP --rotate inverted` might help you 19:55 DS_ (swap inverted with normal to change back) 19:57 MTDiscord I once had a desk with a shelf above it and wanted to mount my monitor upside down hanging from the shelf so I had room underneath to shove my keyboard back. I considered changing the rotation settings but then figured "hey, I could just learn how to use it like this, it'd take me a few days at most". Well, that much worked ... but it was really jarring when I had to help a colleague out on their machine... 20:04 Pexin fifteen internets to whoever can find the 2005-ish "crt monitor suspended above bed for playing vidya while being The Most Lazy" pic 20:05 Pexin I mean there may be multiple such pics, but I've got one buried on a backup disk in a box somewhere 20:08 MTDiscord maybe not what youre thinking of but similar https://i.imgur.com/SMRTviZ.jpg 20:16 Pexin @GreenXenith yeah found that one 20:16 Pexin it makes me nervous 20:17 MTDiscord Haha, yeah 20:17 Pexin (table shifts) 20:17 MTDiscord I'd have never dared mounting my old CRT like that, the bevels werent even flat so it would have been even less sturdy 20:18 MTDiscord bezels* 20:18 MTDiscord beveled bezels 20:27 Pexin https://i0.wp.com/theverybesttop10.com/wp-content/uploads/2016/09/Top-10-Amazing-Ways-to-Repurpose-Your-Old-PC-Monitors-and-TVs-6.jpg