Newest at the top
| 2025-07-13 13:26:30 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-13 13:23:50 +0200 | gmg | (~user@user/gehmehgeh) gehmehgeh |
| 2025-07-13 13:23:25 +0200 | tromp | (~textual@2001:1c00:3487:1b00:89d3:7d92:7b20:925) |
| 2025-07-13 13:23:00 +0200 | califax | (~califax@user/califx) califx |
| 2025-07-13 13:21:42 +0200 | patri_ | (~patri@user/patri) (Ping timeout: 276 seconds) |
| 2025-07-13 13:21:24 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-13 13:19:24 +0200 | <tomsmeding> | you can't auto-merge mathematical arguments |
| 2025-07-13 13:19:16 +0200 | <tomsmeding> | "manually" as in, using formatting/reflowing/regex tools, but otherwise manually eyeballing |
| 2025-07-13 13:18:59 +0200 | <tomsmeding> | [exa]: for the TeX hypothetical you described, what I'd do is open the two side-to-side in vimdiff and manually manipulate both documents until they are at some point equal |
| 2025-07-13 13:18:00 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 272 seconds) |
| 2025-07-13 13:17:17 +0200 | <tomsmeding> | and that there's a domain expert thoroughly checking the output of your merging process :p |
| 2025-07-13 13:16:45 +0200 | <tomsmeding> | [exa]: hope you're being paid for this |
| 2025-07-13 13:14:04 +0200 | califax | (~califax@user/califx) (Ping timeout: 244 seconds) |
| 2025-07-13 13:12:55 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-13 13:11:57 +0200 | Unicorn_Princess | (~Unicorn_P@user/Unicorn-Princess/x-3540542) Unicorn_Princess |
| 2025-07-13 13:08:40 +0200 | tromp | (~textual@2001:1c00:3487:1b00:89d3:7d92:7b20:925) (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 2025-07-13 13:06:18 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |
| 2025-07-13 13:03:28 +0200 | dtman34 | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-13 13:02:09 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 248 seconds) |
| 2025-07-13 13:01:46 +0200 | sprotte24 | (~sprotte24@p200300d16f118b009de684e40fbf0935.dip0.t-ipconnect.de) (Read error: Connection reset by peer) |
| 2025-07-13 13:01:10 +0200 | jespada | (~jespada@r167-61-141-199.dialup.adsl.anteldata.net.uy) jespada |
| 2025-07-13 13:00:53 +0200 | lambdap23717 | (~lambdap@static.167.190.119.168.clients.your-server.de) |
| 2025-07-13 13:00:38 +0200 | lambdap2371 | (~lambdap@static.167.190.119.168.clients.your-server.de) (Remote host closed the connection) |
| 2025-07-13 12:57:04 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-13 12:53:08 +0200 | <[exa]> | nvm it's almost done :D |
| 2025-07-13 12:52:43 +0200 | <[exa]> | hm for the closest picture imagine merging changes in a TeX paper where 2 mathematicians very zealous about tex macros have each spent a month working independently, one of them force-justifying stuff to 80chars and other one to 120chars |
| 2025-07-13 12:51:18 +0200 | <[exa]> | if these wouldn't be the problem I'd just forceformat everything |
| 2025-07-13 12:50:53 +0200 | <[exa]> | tomsmeding: nah the plaintext changes are the main issue |
| 2025-07-13 12:50:10 +0200 | humasect | (~humasect@dyn-192-249-132-90.nexicom.net) humasect |
| 2025-07-13 12:48:31 +0200 | lxsameer | (~lxsameer@Serene/lxsameer) lxsameer |
| 2025-07-13 12:47:39 +0200 | califax | (~califax@user/califx) califx |
| 2025-07-13 12:47:11 +0200 | dtman34 | (~dtman34@c-73-242-68-179.hsd1.mn.comcast.net) dtman34 |
| 2025-07-13 12:46:39 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) (Ping timeout: 260 seconds) |
| 2025-07-13 12:45:24 +0200 | califax | (~califax@user/califx) (Remote host closed the connection) |
| 2025-07-13 12:45:21 +0200 | <tomsmeding> | which would be something that's not too hard to build but not done by existing merge tools |
| 2025-07-13 12:44:53 +0200 | <tomsmeding> | where possibly, if comments changed differently in both versions, it's fine to just keep both? |
| 2025-07-13 12:44:37 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) (Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in) |
| 2025-07-13 12:44:33 +0200 | <tomsmeding> | ah I see |
| 2025-07-13 12:43:48 +0200 | <[exa]> | tomsmeding: biocuration outputs, there's plenty of freetext there ("comments") which have to be merged sensibly as well |
| 2025-07-13 12:41:19 +0200 | merijn | (~merijn@host-vr.cgnat-g.v4.dfn.nl) merijn |
| 2025-07-13 12:40:59 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) wootehfoot |
| 2025-07-13 12:40:43 +0200 | rembo10 | (~rembo10@main.remulis.com) rembo10 |
| 2025-07-13 12:39:45 +0200 | wootehfoot | (~wootehfoo@user/wootehfoot) (Ping timeout: 248 seconds) |
| 2025-07-13 12:39:40 +0200 | <[exa]> | ah they depend on tree-sitter and tree matching, okay that's a fair shot |
| 2025-07-13 12:39:13 +0200 | rembo10 | (~rembo10@main.remulis.com) (Quit: ZNC 1.9.1 - https://znc.in) |
| 2025-07-13 12:38:51 +0200 | <tomsmeding> | I'm curious what conflicts you have that are not solvable using a code formatter and manual conflict resolution, but for which writing your own merge tool is feasible |
| 2025-07-13 12:37:35 +0200 | <[exa]> | no like, the amount of code there ain't small |
| 2025-07-13 12:37:09 +0200 | <tomsmeding> | [exa]: how is an off-the-shelf tool overkill but writing your own merge tool not |
| 2025-07-13 12:36:29 +0200 | <[exa]> | maralorn: that looks like quite a bit of overkill |
| 2025-07-13 12:36:25 +0200 | dtman34 | (~dtman34@2601:447:d182:6512:c2f9:c3a:b83d:6490) dtman34 |