March 9th, 2022 | notes | kipras melnikovas

{{[[DONE]]}} (hidden) 978RHbd8z #read
- (hidden) 8wMgO1BrI
(hidden) 7lE8xgCb_
(hidden) qPG8dt2sF
(hidden) glfpOMMpd
{{[[TODO]]}} (hidden) 6LojZjO4R [[(hidden) WnqazAnvf]]
{{[[DONE]]}} (hidden) ij76IHuG1 [[(hidden) BC3_6P1lo]] [[(hidden) ZU9Qyb3ve]] [[(hidden) Nyyl2XbvQ]]
{{[[TODO]]}} (hidden) 0g7HeNL-J [[(hidden) W7BaKt1hA]] #[[(hidden) fzClo9lBQ]]
{{[[TODO]]}} (hidden) f6jVe6s5z [[(hidden) bQLvY7Uwo]] [[(hidden) kgu_3b2ya]]
(hidden) __m93mqI8
(hidden) cyNLCdxVu #[[(hidden) OnaA1cbnM]]
- (hidden) rdBFo53NK [[(hidden) ntOf1A2w_]]
  - {{[[TODO]]}} (hidden) eJ7bMMu_p
  - {{[[TODO]]}} (hidden) mJTganzOW
  - {{[[TODO]]}} (hidden) o-wnq5UH0
- {{[[TODO]]}} (hidden) qIY4ziiuG
  - (hidden) 09l6Ntto_
  - (hidden) ywqghAmj0
- {{[[TODO]]}} (hidden) PZYfWss5n
- {{[[TODO]]}} (hidden) ZpYl6300b
- {{[[TODO]]}} (hidden) V8K6L0rQb
- {{[[TODO]]}} (hidden) t_DLOwm71
(hidden) IwV8lAIRg
{{[[TODO]]}} (hidden) bads6p3Li [[(hidden) ntOf1A2w_]] #[[(hidden) QIpFrgazj]]
(hidden) CbEhh7lOr
{{[[DONE]]}} (hidden) Ba8ZUwbEP [[(hidden) LmYDA4A8X]] [[python]]
- (hidden) D2t-yTPP2
(hidden) IkcvZo-TM
(hidden) h-fQOpdOR
(hidden) LFKMGm80y
[[git-stacked-rebase]]
- {{[[TODO]]}} the [post-rewrite hook](((tZEqsgDAB))) + the new `reducePath` where we go from `{ "a": "b", "b": "c", "c": "d" }` into `{ "a": "d" }` seems to make a lot of sense!
  - {{[[TODO]]}} interesting new thing i noticed while playing w/ the test/.tmp repo experimenting with this -- if you break, and then create additional commits, and if the commit you break on is where a partial branch points, we gotta handle extra logic to remap the branch to a new proper location
    - there could be 2 scenarios (where commits get rewritten and thus the `post-rewrite` hook gets called, thus we append to our own rewritten-list):
      - a) you're doing it w/ git-stacked-rebase.
        
        here, you could be intentional about where you'd want the commits to end up -- you could place the `break` after a commit, but before the `branch-end`, or you could place the `break` after the commit and `branch-end`.
        
        but i don't know if this intentional separation would be obvious.
      - b) you're doing it with regular git-rebase.
        
        here, you don't have the `branch-end`s, so you don't even have the explicit option.
        
        so the default would make sense that if you break after a commit where a branch points to, git throws you there, and you're still in that branch, thus the new commits should end up inside that branch, i.e. the partial branch / boundary should be moved to the latest commit you added, or rather, for easier implementation (because we don't know if you create commits / how many, etc) -- the branch boundary would end up before the next commit that existed after the one you breaked on! i.e. A->B->C->D->E, partial branch points at C, you break at C, create new commits C1, C2, C3. the next commit of C was D, so now you move the partial branch to the latest commit before D, i.e. C3.
        
        not sure if this improved strategy could backfire / are there any cases where it'd break. need to think more about it. regardless, if the user was always using git-stacked-rebase's `--continue`, we could handle it, but we can never rely on this.
(hidden) qBn_NT_57
(hidden) hZvjbA4JS
(hidden) o8aHl_7hz

words:	462 + 0 = 462
last update: