Quoth Paul Lalonde <paul.a.lalo...@gmail.com>: > Ah, yes, my dev history involves git in very large repos with too many > committers. The probability that you won't have to rebase to catch up to > main was approximately zero, so that just becomes part of the workflow. If > you're the only person working in a section of the tree then it's trivial > and just runs automatically.
Yes -- the other thing is that, unlike torvalds git, our git will try to merge upstream changes against uncommitted local changes, which makes it a lot easier to have some local divergences. Improving local divergences is interesting to me, and I'd be happy to take patches which improve that further. 'jj' looks like it may be a source of inspiration, though I haven't played enough with it to know. > > You may well have fixed it. I realized that I hadn't done an update after > installing this cpu/disk server, so did that. I'll report if I run into > the grief again. > > Also, is there a reason why git/rebase -i doesn't have a "drop" option? I > use it frequently when I find myself with a duplicate change from messing > up my github fork synchronizations No, other than nobody implementing it -- but it's yours to change; feel free to mention things that would improve your experiences. I'll happily take patches, or at least discuss. > > Paul > > On Sun, Jan 12, 2025 at 4:37 PM <o...@eigenstate.org> wrote: > > > Quoth Paul Lalonde <paul.a.lalo...@gmail.com>: > > > My next question is how to pull new changes from remote while putting my > > > new work on top. > > > Linus' git does a decent job of that with pull, but my experience with > > git9 > > > is rather less pleasant. > > > > > > Looking at it, it seems like a work for git/rebase. Here I'm trying to > > > take the work from > > > > > > fluxcpu% git/branch > > > > > > heads/some_feature > > > > > > fluxcpu% git/rebase remotes/origin/regen > > > refs/heads/_rebase.working: 7664f5db108af0debf257470be6ac3126ee0206b > > > pick 44574500459e507d51e6a359ebe6fd2a1c3df1da Save these files for later. > > > diff: cannot open b/386/bin/ape//null: file does not exist: > > > 'b/386/bin/ape//null' > > > diff: cannot open b/386/bin/auth//null: file does not exist: > > > 'b/386/bin/auth//null' > > > diff: cannot open b/386/bin/aux//null: file does not exist: > > > 'b/386/bin/aux//null' > > > ... > > > > > > Rebase appears to be both expensive, and perhaps buggy? I'm not sure > > > what's up with the very long scroll of the same error, applied to > > different > > > files. > > > > I think most people on 9front git tend to not rebase all that often, > > so it could probablly use a bit of love. That said, I'm pretty sure > > that I fixed this a while go. > > > > Do you have a way for me to repro this issue? > > > > > This is also too slow to be usable, at least for a tree as large as NIX. > > > We'll get NIX pruned down into small changes to bind over 9front, but I > > > don't see how to update my working branch to track upstream. > > > > if you have heads/mybranch and remotes/upstream/mybranch, then mybranch > > will track upstream. > > > > again, if you can give a repro, I can look at measuring why it's slow. > > > > My typical workflow is that I'll work on a commit until it's ready, and > > then either push it directly or cherry pick it onto front, and push it; > > patches tend to be either an email of webpaste based workflow. > > > > git/import /mail/fs/mbox/$MSGID > > > > is killer for pulling in a patch. > > > > I've got a TODO list item to work on some nice patch queue tools based > > on this, gerrit style, but it's not been a priority so far. > > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-M6f636d9af5f5ad46b85b0368 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
