< wumpus>
is it possible to do git conflict resolution as a series of commits instead of in the merge commit?
< wumpus>
e.g. what is the best way to document the conflict resolution step by step and make it reviewable
< wumpus>
why is fixing this macos background image giving so much trouble?
< jonatack>
A look in GH help didn't turn up anything wrt disabling the GH editing interface. Agree it would be helpful to be able to.
< wumpus>
jonatack: couldn't find it either :(
< wumpus>
nosss2: please fix your link, you've been reconnecting constantly over the last few days
< wumpus>
jonatack: the main issue there is that the github editor pretends to be a user friendly git frontend, but then doesn't provide the tools (such as squashing) to make high-quality PRs
< wumpus>
I don't think the idea behind it is wrong, it's just, a typical user trap, and we end up having to explain how to use git to people
< wumpus>
nosss2: please fix your connection or I'll have to ban your for now, these constant ping timeouts generate too much noise
< wumpus>
is there any way to add a comment to a ban here? or make it temporary?
< aj>
wumpus: think chanserv should be able to make temporary bans, not sure about comments
< wumpus>
aj: thanks, will check the chanserv docs
< aj>
looks like chanserv akick will accept a reason but isn't temporary?
< wumpus>
looks like it can do both, !T <time> and reason (always the last part) can both be specified
< jb55>
wumpus: don't most people filter those? that would drive me insane.
< arapaho>
I agree, ignoring joins/parts/quits could help.
< wumpus>
I don't know what most people do tbh
< wumpus>
I definitely know how to filter them, if you mean that, but I prefer not to for channels I'm op in, as those messages can be used for spamming and such
< jb55>
just not sure about banning someone for protocol noise xD
< jb55>
unless it's was purposeful spamming of course ...
< wumpus>
sigh... do you really want an argument about htat
< jb55>
not really
< wumpus>
it's not like I do that daily, this was just getting annoying
< instagibbs>
wonder if there's written down policy for this. I recently revived the explicit feerate PR from someone who disappeared, i actually forgot to give myself any credit in the commits... probably only showed up in the merge commit message
< instagibbs>
which again would be enough to do some detective work
< wumpus>
no, there's no policy for that, in general, just give credit where credit is due and don't be a dick about it
< wumpus>
but also not really sure what ryanofsky's point is here, I mean it's definitely possible to give even more credit than mentioning someone's name in the commit metadata and the commit itself, but what then, I think what count here is that adamjonas did his best to credit
< wumpus>
should we be angry at him for not crediting enough?
< luke-jr>
instagibbs: git does record the committer independently from the author
< ryanofsky>
i'm just saying it is possible to give more credit and explanation than was given, and i usually try to do that by writing comments that give credit
< ryanofsky>
i have no opinion on "enough". enough credit for me is usually 0, for other people it may be more
< wumpus>
I mean it's never enough
< ryanofsky>
wumpus, doubt that is true unless the person is imbalanced or something
< wumpus>
yes, but your point is basically 'you can always do more'
< wumpus>
sure
< ryanofsky>
no, my point is in that specific case, more could have been done
< wumpus>
yes, it could
< luke-jr>
I suspect Diapolo left over credit issues
< provoostenator>
The merge commit could add Reviewed-by or Acked-by tags?
< MarcoFalke>
promag: We should be using more emojis
< MarcoFalke>
I will adjust my script to do that. emojis will be signed and timestamped, of course
< luke-jr>
replace ACKs/NACKs with emoji codes?
< MarcoFalke>
?
< luke-jr>
(on a serious note, I would find that rather annoying)
< aj>
MarcoFalke: bech32 but with an alphabet of emojis?
< wumpus>
riot.im e2e uses something like that to cross-verify keys (the idea is that a list of emoji+their names is easier to communicate than say, a hex string)
< bitcoin-git>
[bitcoin] laanwj reopened pull request #17385: refactor: Use our own integer parsing/formatting everywhere (master...2019_11_integer_parsing) https://github.com/bitcoin/bitcoin/pull/17385
< bitcoin-git>
bitcoin/master 646b593 John Newbery: [tests] Speed up rpc_fundrawtransaction.py
< bitcoin-git>
bitcoin/master 9a85052 John Newbery: [tests] Use -whitelist in rpc_fundrawtransaction.py
< bitcoin-git>
bitcoin/master af7bae7 John Newbery: [tests] Don't stop-start unnecessarily in rpc_fundrawtransaction.py
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #17340: Tests: speed up fundrawtransaction test (master...2019-11-speed-up-fundrawtransaction-test) https://github.com/bitcoin/bitcoin/pull/17340
< wumpus>
oh nice, there's a env_windows.cpp in the new upstream leveldb, we might be able to stop maintaining our own env_win https://github.com/bitcoin-core/leveldb/pull/26 this handles the file functions and such, it will be a lot of work to test/investigate the differences though
< sipa>
nice, and it's not a crazy boost based thing like the old windows branch of leveldb had
< wumpus>
yup, no boost at all! it's entirely native
< wumpus>
ARM crc32c will be nice too
< sipa>
wumpus: so... can we just drop our own fork?
< sipa>
(for consistency reasons we may not want to actually do that, but equivalently we can just undo all our local modifications?)
< sipa>
since we have our own build system overriding leveldb's, the forced-no-snappy thing can be dealt with there
< wumpus>
there's some changes that I'd like to keep: the GetName on files, used for diagnostics, the "Do not crash if filesystem can't fsync" patch (handle EINVAL on directory sync), but yes, I'm thinking instead of merging, might as well restart with a small patch stack on upstream
< sipa>
right.
< sipa>
don't we have some local changes to observe memory usage or so?
< sipa>
or was that just something i experimented with
< jnewbery>
has there ever been an effort to upstream those small patches?
< wumpus>
(also possibly the 1000 to 4096 patch, though if we can use the test interface, it seems we don't need that anymore)
< sipa>
jnewbery: i don't think so; leveldb used to be very slow in accepting patches, i think maybe that has improved over the past two years
< wumpus>
I've never tried at least
< wumpus>
another reason to make a patch stack instead
< wumpus>
sipa: I don't remember seeing any memory-related changes, let me see
< wumpus>
LOL this is a change we have:
< wumpus>
-// where enough posix functionality is available.
< wumpus>
+// where enough Posix functionality is available.
< wumpus>
yes, the no_snappy thing we can deal with in your build system
< wumpus>
HAVE_SNAPPY Define to 1 if you have Google Snappy. -> should be hardwired to 0 for us, obviously
< sipa>
i'll be very happy if we can actually stop relying on our own weird windows port
< wumpus>
no, there's no memory related changes
< sipa>
ok.
< wumpus>
and same :)
< sipa>
seems they even have tests for the windows port!
< wumpus>
I could add channels to the bot, if you'd rather not host your own
< wumpus>
is it possible to do a git merge and simply ignore all your own files to replace them with upstream?
< wumpus>
so logically it's a merge but it retains nothing of the original code
< gwillen>
wumpus: it looks like you can do "git merge -X theirs":https://stackoverflow.com/questions/173919/is-there-a-theirs-version-of-git-merge-s-ours
< gwillen>
wit some caveats
< sipa>
wumpus: yeah, a merge commit is just a commit that has 2 parents
< sipa>
it can effectively do anything
< wumpus>
(this is just to make the subtree merge easier, I don't think it'll be happy with a rebase in between)
< wumpus>
sipa: gwillen thanks!
< sipa>
including replacing everything with a completely unrelated tree
< gwillen>
np!
< sipa>
wumpus: fwiw, git subtree works fine with undoing commits
< sipa>
in the subtree
< sipa>
i think we could reasonable create a new branch in bitcoin-core/leveldb which is equal to the google/leveldb one + a few patches
< sipa>
and then use git subtree to switch our directory to that
< wumpus>
ok, will ook at that, for now I managed to change the PR to revert all our changes then re-apply the three that still matter
< sipa>
subtree will in this case just produce a squash commit that has message "Delete commit X; Delete commit Y; Add commit Z; ..."
< sipa>
the old and the new tree must have a common ancestor, though
< wumpus>
it automatically figures that out? that sounds pretty good