***sneek_ is now known as sneek
*nalaginrut is trying to use tekuti as his new blog <nalaginrut>although it works fine now, there's such warning <nalaginrut>sneek: later tell wingo Is this warning harmful? "fatal: Not a valid object name" <nalaginrut>sneek: later tell wingo I'm using tekuti for the blog ***sneek_ is now known as sneek
<davexunit>hey guilers. I have a question that isn't about guile as a language but rather the git workflow used. <davexunit>sometimes I have trouble with deciding between merging or rebasing and other such issues. <davexunit>the 2 branches in the guile repo that I'm familiar with are master and stable-2.0. <davexunit>master has new development like the coming changes for 2.2, and bug fixes and such are applied to stable-2.0. <davexunit>is stable-2.0 simply periodically merged into master? <davexunit>I found myself in a situation today where I rebased and did git push -f. I felt bad afterwards. <mark_weaver>at some point, I imagine we'll switch to a different model, maybe where patches are cherrypicked from some newer branch into stable-2.0. <mark_weaver>personally, I like rebasing, so that the git history ends up being fairly linear. <davexunit>mark_weaver: it's generally considered bad to force push like that. <mark_weaver>but there are certainly cases where merging is better. <davexunit>forces the push to succeed, overwriting what was there before. <mark_weaver>hmm, that does sound like something to avoid on a main branch. <davexunit>I had a branch on a remote repo that passed code review, but just after that a merge happened to the parent branch that caused merge conflicts. <davexunit>so I rebased my feature branch on top of the parent and resolved the conflicts when they came up, and then pushed to the remote using the -f flag. <davexunit>then I crossed my fingers and was happy to see that I didn't blow everything up. <mark_weaver>are you sure you needed the -f flag? did you try without? <mark_weaver>it sounds like you did exactly what I would have done, except I wouldn't have used -f, and I wouldn't have expected to need it. <mark_weaver>ultimately, after rebasing, you end up with something that should push cleanly. <davexunit>really? I wonder why I've been in situations where git push doesn't work. <davexunit>I thought it was because the SHAs are different so it's as if the branch has totally diverged. <mark_weaver>if you didn't need the -f, then I guess it has no effect and thus no harm. but if you did need it, I'd expect trouble for others that follow your repo. <mark_weaver>davexunit: if you needed -f, then the rebase wasn't done correctly. <mark_weaver>and you need to fix that, rather than force pushing something that's not quite right. <dsmith-work>Maybe if you ever pushed your feature branch and then rebased? <davexunit>dsmith-work: that's what it was. the feature branch was already on a remote. <mark_weaver>after rebasing, you could have a set of patches that linearly lead from the current mainline to your modified version. <mark_weaver>and a series of fresh new commits based on those patches, as if you had done the work just now on current mainline. <davexunit>I will keep that in mind the next time I encounter this situation. <mark_weaver>davexunit: thanks for the link. I still have much to learn about git. ***fangism-ctrl-Z is now known as fangism
<civodul>with open-pipe OPEN_BOTH, it's not possible to close just one end of the pipe, is it? <mark_weaver>civodul: there are a couple of patches floating around that fix it in a thread-unsafe way. <mark_weaver>but really, I think we should have a new API that returns two separate ports, instead of the merged port. <mark_weaver>I think it's a bad idea to return a merged port in the first place. <mark_weaver>the pipe into a subprocess is totally different than the pipe on the other end. they are not related to each other. <mark_weaver>they have no natural relationship to each other, in general, I mean. <civodul>mark_weaver: yes, i think you're right <civodul>i think scsh had nice APIs for pipelines and such that we could borrow <mark_weaver>However, I don't think the included patch is the right way to fix it (and also, it would have to be updated based on the new thread-safe popen) <mark_weaver>The relevant C code that Andy wrote returns two separate ports, so it would be quite easy to just add a new exported procedure to (ice-9 popen) that returns two. <mark_weaver>but I agree it would be better to design/borrow a better API. <mark_weaver>the current 'merged-port' implementation is also extremely inefficient at reading the output from the pipe. <civodul>mark_weaver: this patch looks good, as an incremental improvement <civodul>that is: apply this patch, and eventually come up with a better API <mark_weaver>we can't apply that patch as-is, because it's not thread safe. <mark_weaver>right now, stable-2.0 has a thread-safe (ice-9 popen), which tupi needs. <civodul>but yeah, we could conceptually apply it :-) <mark_weaver>I don't have time to investigate the scsh API right now though. <civodul>actually i ended up using filtered-port from (guix utils) for my urgent need, so no rush <civodul>but typically filtered-port is the kind of tool Guile should provide by default ***Fuuzetsu is now known as Guest24407
***Guest24407 is now known as Fuuzetsu`
***Fuuzetsu` is now known as Fuuzetsu