Time |
Nick |
Message |
00:46 |
|
Noclip[m] joined #minetest |
00:58 |
MTDiscord |
<Benrob0329> Ah yes, 0ver, the best example of what you might call "1.0 syndrome" or "software self consciousness" |
01:37 |
|
Platekoala[m] joined #minetest |
01:48 |
|
LW joined #minetest |
01:51 |
|
freshreplicant[m joined #minetest |
01:56 |
|
wsor4035 joined #minetest |
02:01 |
|
Hawk777 joined #minetest |
02:41 |
|
Taoki joined #minetest |
02:41 |
|
helix[m] joined #minetest |
02:47 |
|
ServerStatsDisco joined #minetest |
02:49 |
|
Taoki joined #minetest |
02:52 |
|
rocky_fuchsian_f joined #minetest |
03:28 |
|
Lone_Wolf joined #minetest |
03:46 |
|
olliy1or joined #minetest |
03:48 |
|
Sven_vB joined #minetest |
03:51 |
|
erlehmann joined #minetest |
03:56 |
|
olliy joined #minetest |
03:59 |
|
mrtamca joined #minetest |
04:03 |
|
Sven_vB joined #minetest |
05:01 |
|
riff-IRC joined #minetest |
05:10 |
|
Norkle joined #minetest |
05:51 |
|
independent56 joined #minetest |
05:57 |
|
independent56 joined #minetest |
06:02 |
|
YuGiOhJCJ joined #minetest |
06:02 |
|
independent56 joined #minetest |
06:09 |
|
CWz joined #minetest |
06:16 |
|
independent56 joined #minetest |
06:39 |
|
independent56 joined #minetest |
07:45 |
|
Talkless joined #minetest |
07:49 |
|
CWz_ joined #minetest |
07:54 |
|
independent56 joined #minetest |
08:12 |
|
ssieb joined #minetest |
08:14 |
MTDiscord |
<luatic> I plan to switch modlib to semver once I have removed the deprecated stuff |
08:36 |
|
entuland joined #minetest |
08:44 |
|
longerstaff13 joined #minetest |
09:22 |
|
calcul0n_ joined #minetest |
09:27 |
|
entuland joined #minetest |
10:37 |
|
specing_ joined #minetest |
10:45 |
|
Soni joined #minetest |
11:57 |
|
calcul0n__ joined #minetest |
12:07 |
|
shredder joined #minetest |
12:43 |
|
Verticen joined #minetest |
13:25 |
|
kamdard joined #minetest |
14:09 |
|
Fixer joined #minetest |
14:11 |
|
Elzington joined #minetest |
14:53 |
|
absurb joined #minetest |
15:17 |
|
Hawk777 joined #minetest |
15:24 |
|
Taoki joined #minetest |
15:42 |
|
cation joined #minetest |
15:53 |
|
Extex joined #minetest |
16:01 |
|
appguru joined #minetest |
16:23 |
|
garywhite joined #minetest |
16:23 |
|
garywhite joined #minetest |
16:43 |
|
Verticen joined #minetest |
16:47 |
|
Fixer joined #minetest |
17:40 |
|
independent56 joined #minetest |
17:40 |
|
independent56 joined #minetest |
17:43 |
MTDiscord |
<Benrob0329> At this point I'm probably going to switch to CalVer for my stuff since its all incrementally developed over time |
17:49 |
MTDiscord |
<Warr1024> I use a 2-segment CalVer variant for NodeCore: <minutes since the nodecore epoch>-<commit hash> |
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 |
<Benrob0329> 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 |
<Warr1024> commit hashes aren't comparable |
17:53 |
MTDiscord |
<Warr1024> only equatable |
17:54 |
MTDiscord |
<Benrob0329> But then I'd want to make each PR atomic via squashing too, so maybe not a great idea |
17:54 |
MTDiscord |
<Benrob0329> That's also true |
17:54 |
MTDiscord |
<Warr1024> 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 |
<Benrob0329> A date of when a given version is from immediately tells you how out-of-date it might be |
17:55 |
MTDiscord |
<Warr1024> 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 |
<Jonathon> 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 |
<Jonathon> *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 |
<Warr1024> 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 |
|
heavy_gale left #minetest |
17:55 |
MTDiscord |
<Warr1024> I can't squash for religious reasons anyway |
17:56 |
MTDiscord |
<Benrob0329> 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 |
<Warr1024> 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 |
<Benrob0329> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Benrob0329> Well yes, so yes. |
17:59 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Benrob0329> I get what your saying, and I agree. Full-squash is bad. |
18:00 |
|
reductum joined #minetest |
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 |
<Warr1024> 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 |
<Benrob0329> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Benrob0329> 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 |
|
ssieb joined #minetest |
18:04 |
erlehmann |
merge commits are very important |
18:04 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Benrob0329> 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 |
<Benrob0329> Mine are usually "File/Topic - Fixed X bug" |
18:07 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Benrob0329> 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 |
<Benrob0329> I don't mean an issue number, I mean an actual bug description, just a short one |
18:09 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> We still had access to the original dev, and of course, he didn't remember any of it eithre. |
18:11 |
MTDiscord |
<Benrob0329> 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 |
<Warr1024> Ironically my personal standards for source control are generally stricter than the standards I've seen in professional contexts... |
18:13 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 <HTTP Error 404: Not Found> |
18:14 |
ShadowBot |
erlehmann: Error: That URL raised <HTTP Error 404: Not Found> |
18:14 |
erlehmann |
good bot lol |
18:14 |
MTDiscord |
<Warr1024> yeah, the bot is a bit sensitive :-) |
18:14 |
MTDiscord |
<Warr1024> 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 |
<Warr1024> 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 |
<Warr1024> Yeah, that one. I see that one a lot. |
18:17 |
MTDiscord |
<Benrob0329> 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:26 |
|
independent56 joined #minetest |
18:39 |
|
DS_ joined #minetest |
18:40 |
MTDiscord |
<luatic> erlehmann: "Code cleanup" is not a useless commit message |
18:42 |
|
longerstaff13 joined #minetest |
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 |
<Warr1024> 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 |
<Warr1024> er --stat |
19:02 |
|
hecks joined #minetest |
19:02 |
|
hecks left #minetest |
19:18 |
|
delta23 joined #minetest |
19:48 |
|
MTDiscord joined #minetest |
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 |
<Warr1024> 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 |
<Warr1024> 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 |
|
Extex joined #minetest |
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 |
<Warr1024> 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 |
<GreenXenith> 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 |
<GreenXenith> Haha, yeah |
20:17 |
Pexin |
(table shifts) |
20:17 |
MTDiscord |
<GreenXenith> 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 |
<GreenXenith> bezels* |
20:18 |
MTDiscord |
<GreenXenith> 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 |
20:28 |
|
SwissalpS joined #minetest |
20:42 |
|
Extex joined #minetest |
20:45 |
|
x2048 joined #minetest |
20:46 |
|
x2048 left #minetest |
20:50 |
|
Teckla joined #minetest |
21:20 |
|
Verticen joined #minetest |
21:43 |
|
ssieb joined #minetest |
22:00 |
|
Sven_vB joined #minetest |
22:35 |
|
specing_ joined #minetest |
23:11 |
|
SwissalpS left #minetest |
23:18 |
|
hecks joined #minetest |
23:19 |
|
BuckarooBanzai4 joined #minetest |
23:20 |
|
Noisytoot_ joined #minetest |
23:21 |
|
Cork joined #minetest |
23:29 |
|
AliasAlreadyTake joined #minetest |