April 18th, 2022 | notes | kipras melnikovas

{{[[TODO]]}} (hidden) ey6qPUxA4 #read
- (hidden) JAvemNGEZ
(hidden) eZQ-nhxQr
(hidden) mlbL5z-nV
{{[[DONE]]}} (hidden) VyuhaZSqf #read
- (hidden) 5kK0EPHKe
  - {{[[TODO]]}} (hidden) JB0l3Y9eB [[github]] #read [[git]]
    - (hidden) RgWdAyS8C
  - {{[[TODO]]}} (hidden) RzekZApO4 [[(hidden) y2O8Yavfw]] #read [[git]]
    - (hidden) 6-qVK3jSI
  - {{[[TODO]]}} (hidden) FdF7G_eAQ #read
    - (hidden) dkv4H1Yoh
      - {{[[TODO]]}} (hidden) 95RERjkyp
      - {{[[TODO]]}} (hidden) ss7lV2Uee
      - {{[[TODO]]}} check if has any impact for [[git-stacked-rebase]]
        
        "git rebase $base $non_branch_commit", when $base is an ancestor or
        
        the $non_branch_commit, modified the current branch, which has been
        
        corrected.
      - {{[[TODO]]}} (hidden) qYtpLck-r
        
        (hidden) eqq19A_Ib
        
        (hidden) dca_p6MXz
        
        (hidden) Avnz63IGI
      - (hidden) diWmfSJz4
(hidden) 0_7TOyL7G
(hidden) bK7qVPJPF
{{[[TODO]]}} (hidden) H-WpvEbLN [[(hidden) sJRzxsUIN]] [[(hidden) z4HNnc9J8]] #read
- (hidden) ClBGBa4mN
(hidden) autEG3uuF
(hidden) 7MmJIRGOI
{{[[TODO]]}} (hidden) Ldkh77xDS [[(hidden) yZmfb-jOu]] #read
- (hidden) JTMdlX3T0
(hidden) OwAxO2b_W
(hidden) cLT7xSTQn
(hidden) QncngQytn
(hidden) P9c_JCqVU [[(hidden) LnQxW_Qdz]] [[(hidden) SeAJd9g0t]]
- (hidden) j0PFHVj0l
(hidden) 5eLgSw2tZ
(hidden) lzmrDRoIy
(hidden) XzGRDhvMV
[[git-stacked-rebase]]
- {{[[TODO]]}} i'd want to checkout the remote branches locally automatically, or rather - reset the local branches to the remote ones, if the local ones no longer point to a reachable commit from the latest stacked branch, and the remote one does.
  - but i don't know how to do this safely.
    - {{[[TODO]]}} perhaps going thru the visible remote branches, checking out their local counterparts (iff already checked out, just at a different, unreachable commit), and doing `git pull --rebase` - if it goes thru, then should be just fine
      - {{[[TODO]]}} if not already checked out, then i think it's the simpler case of just creating a new local branch -- there are no worries about losing some local progress. cc `--sync`
      - {{[[TODO]]}} but this whole thing feels not ready yet -- i don't want to be doing destructive actions when simply retrieving commits (in `getWantedCommitsWithBranchBoundariesOurCustomImpl`)
        
        in general it'd make things more complicated.
        
        esp. until `--apply` is on by default. but even then - if `--apply` wouldn't be used, then it's way more complexity i think (i don't even know how to solve this yet)
        
        how i tried to solve this w/ what we have already, is with `git-stacked-rebase origin/master -s -x "git reset --hard origin/\$(git sob)"` where `git sob` prints the currently checked out branch
        
        {{[[TODO]]}} but, this doesn't work because ofc we the branchSequencer doesn't go thru the remote branches, only locally checked out ones.
        
        hmmmm
        
        1. ofc branchSequencer only goes thru local branches and not remote ones.
        
        if it went thru remote ones, the `git push --force-with-lease --force-if-includes` would fail, because the only case where we would use the remote branch instead of the local one, is iff the local branch is out of sync and thus is not directly reachable from the latest stacked branch.
        
        2. so the push would always fail.
        
        a) now, let's say you're the only person working on this stack; just on different laptops.
        
        i) in this case, you yourself know __not to__ mess with the histories in 2 different laptops, before 1 is synced to another, i.e. you do changes in one, you push, and only then you pull in another and do changes there. you never do changes in both w/o pushing & pulling.
        
        kind of a manual safety lock
        
        sooo, in this case, it'd be completely fine to have some way to `git pull --rebase` the local branches whom are outdated from their remote counterparts
        
        especially if it was explicit by you, and not by the tool implicitly
        
        {{[[TODO]]}} is this how [[--pull]] starts!? pog
        
        i think yes!
        
        basically `-s -x "git pull --rebase"`, but we'll need to make it possible to go thru remote branches
        
        probably more complicated. need to work it out
        
        {{[[TODO]]}} e.g. will need to default to local branches - just like it always has
        
        {{[[TODO]]}} will need to somehow clearly separate & also very clearly explain on when to use change the default
        
        {{[[TODO]]}} also need to think if options should be "only local; only remote", or "only local; only remote, iff not included in local" (2nd i think?)
        
        {{[[TODO]]}} also how will we allow doing this thru the CLI as well? another option flag?
        
        {{[[TODO]]}} also ofc since we don't have the [[local --sync]] [1], if `git pull --rebase` would encounter any conflicts, then we'd need to completely abort. (that is, until we'd implement [[local --sync]])
        
        [1] see ((VjcV99GON))
        
        thinking about [[--pull]] more, i think it'd be a tool to "fix the chaos".
        
        e.g. the above idea to sync up the local branches to their updated remote counterparts is just one of the things it could fix
        
        maybe another would be the "detection of a newer latest stacked branch", tho ideally that'd be automatic.
        
        idk yet. again, one part of the philosophy of [[git-stacked-rebase]] is that i want it to be as little intrusive as possible. you should be able to do whatever the f that you're doing w/ your regular git commands, and they should work just fine w/ us, and vice-versa. the user shouldn't need to start using gsr for everything - committing, pulling, pushing, etc. -- the less of that, the better. ofc, w/o losing explicitness - if first we are working on a new command and we don't know the ideal scenario / workflow, then it's fine, but the goal should be to reduce friction while keeping the user totally in control & not doing anything unexpected, and also allowing the user to customise behavior if ever needed & reasonable.
        
        hmm. i think it's pretty safe to assume that the user would be doing their regular git pulls (in the latest stacked branch) with `--rebase`.
        
        in this case, does the [[(hidden) A6VTQ3_tb]] script get toggled?
        
        if yes - we could call our own "pull" handling there, w/o the end user having to do anything / ever know about our own [[--pull]] - would fit the philosophy well
        
        {{[[TODO]]}} !! but, if we're not trying to be explicit, then maybe the handling of the [above idea](((1yHdRqTQZ))) would actually make sense of where i thought it'd go in initially -- right when we're extending the commits w/ branch boundaries in `extendCommitsWithBranchEnds`, called from `getWantedCommitsWithBranchBoundariesOurCustomImpl`?
        
        in this case -- no need for yet another command!
        
        we'd make a prompt / print info, and would do the same as we're doing w/ the calling of regular rebase -- if succeeded, continue other things we need to do; if failed (because e.g. conflicts or whatever else) -- stop our own execution.
        
        hmmm. on another note, there are many things that could happen in the remote.
        
        the creation of new branches in between is just 1 of them
        
        wait no this is not the issue, the issue discussed above is if local branch is out of date from remote branch
        
        you could also move commits between some branch boundaries obv
        
        in this & other (?) cases it could get more complicated, such that the simple git pull --rebase might not be enough
        
        so basically i think we do want an __explicit__ [[--pull]] rather than an implicit one, esp if it'd do more
        
        {{[[TODO]]}} ! but, by introducing [[--pull]], we'd open a whole can of worms...
        
        {{[[TODO]]}} maybe for starters we should name it `--experimental-pull`, if we decide to introduce it in the first place?
        
        {{[[TODO]]}} having the additional logic/check/handling directly in the extendCommitsWithBranchBoundaries might be ok as well
        
        {{[[TODO]]}} but we really need a lot of tests before we start doing all this lol
        
        ii) you fail to ensure this safety lock (probable)
        
        too bad. i think it wouldn't be as bad, because you could solve the rebase's conflicts.
        
        but, now you probably have different commits yet again, and now your branch is still not part of the latest stacked branch -- now you gotta transplant the commits yourself.
        
        {{[[TODO]]}} (until [[local --sync]] is introduced, if ever, which would do exactly that)
        
        b) you're not the only person working on this stack
        
        well, even with a regular rebase -- should you be rebasing even 1 branch if there's >1 person working on it? no.
        
        so you should never end up here. if you did -- too bad (you all f'd up lmao)!!
(hidden) Pc2dxi3PV
(hidden) Y1hqR2kzl
(hidden) eahww3akz
(hidden) AOT0PcnVd
(hidden) 938UZvGw5
(hidden) TPtL9DHjU

words:	1331 + 0 = 1331
last update: