https://linen.dev logo
Join Slack
Powered by
This message was deleted.
# feature-requests
s
This message was deleted.
a
Does 
gt upstack onto
work for you?
Or are you suggesting that you want to specify what commit you want to rebase on top of?
j
ah, I’ve never tried that but it doesn’t quite look like what i’m looking for, based on the docs. Assuming that the trunk branch is 
dev
, i’d want to run the equivalent of:
Copy code
git rebase --onto dev HEAD~1
(HEAD~1 is an example, it could be whatever) and have that propagate through the stack. not sure if it would actually be possible to auto-propagate this without conflicts… but that would be the ideal
running this type of rebase usually avoids conflicts that occur for us when we start working on a branch and changes occur on the trunk branch (not always, but many types of conflicts are avoided by doing this)
a
I see -- this is not a workflow I'm super familiar with so I will defer to @Jacob Gold.
👍 1
j
we'll be changing the behavior of 
track
to better address this case in the coming months
👀 1
git rebase --onto parent child~ child && gt track child --parent parent
should work for now though
you could alias that into something nice
j
ohhh interesting, I’ll try that out next time i run into this! If I’m understanding correctly, wouldn’t i have to rebase the branches in the stack all the way up still? which is what I’d love to automate, the tracking actually works ok
I think what usually happens is something like this:
Copy code
dev
 - branchA (needs restack)
    - branchB
       - ...
if there are conflicts, that I know can be resolved using the 
--onto
trick, I’ll do sometihng like:
Copy code
# start at branchA
git rebase --onto dev HEAD~...

# At this point, i think branch B is not tracked correctly, but branch A is tracked
git co branchB

git rebase --onto branchA HEAD~...
# at this point, branch B is tracked correctly, same with A

# repeat for all remaining branches
Ahhh I think I see, if i use your suggestion, it would track the parent branch so I can use 
gt bu
instead of 
git checkout <branch>
? That saves some time and mental overhead for sure! ideally the rebasing could be propagated automatically (i’m not sure if that’s actually possible though)
j
i should probably write a blog post on the details here for curious people, but essentially we track two pieces of data for each branch — its parent branch, and the exclusive start in its history. so for a single-commit branch B that points to 
commit-B
when 
git log
roughly looks like
Copy code
commit-B <- B
commit-A <- A
main
would have 
{parentBranch: 'A', parentBranchRevision: 'commit-A'}
this allows us to do 
git rebase --onto A commit-A B
to restack 
B
when 
A
changes underneath it we maintain the invariant that 
git merge-base --is-ancestor <parentBranchRevision> branch
holds, and if that ever breaks we throw our hands up and require you to retrack the branch 
gt track
only allows you to track branches when the commit of the parent is currently an ancestor of the commit of the branch, so rebasing gets it to that point
👍 1
j
whew ok, i have a hard time understanding this fully, but I think i’m following for the most part!! 🥴
2 Views
Open in Slack
PreviousNext
Powered by