--pull | notes | kipras melnikovas

--pull

words:	3 + 1578 = 1581
last update:

#public
parent:: [[git-stacked-rebase]]

Linked Mentions (5 in 1 page)

April 18th, 2022 (5)

{{[[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?
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
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
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
{{[[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