A bit more than a week ago PRs in the local repo started to get frozen, even if only doing

gt sync

to get latest version of some PRs, not submitting anything. I cannot figure out what makes a local PR to freeze. Is this a bug or a changed behavior?

(If applicable) To help us repro, please send the following if you haven't already: - PR links, screenshots, and/or debug output if applicable - Repro steps - Does this happen consistently? Just to you or others on your team also? - Is this a regression? Is the problem new? - If you're having an issue with the CLI, please send us debug logs using

gt feedback --with-debug-context <any message>

yes, I do have 1.7.0. I don't get why my branches get frozen when I'm only doing

gt sync

with no local changes. it is kind of confusing.

interesting. Did you create the branches originally or were they fetched?

they were fetched

okay, then it is expected that branches you are not the author of would be frozen. Docs here for ref

but the problem is the following .... • I'm doing

gt checkout #PR

or

gt get #PR

• I'm not modifying anything • After a while I'm doing a

gt sync

to get updates to the #PR I have locally, potentially on top of a new main. • The local #PRs get frozen, main underneath does not update anymore • As i'm not editing that repo, only doing read-only stuff I'm not expecting the PRs I have locally to get any conflict or to go 'frozen'. We got bitten a few times by that, that we don't see the new changes on main because the #PRs got frozen.

ah, so the part that is causing issue is that it is not rebasing locally on gt sync. So to reproduce i can make a stack A, B, C from user 1 USer 2 checkout stack and has a,b, and c locally (frozen). User 1 merge A and B rebases to main. User 2 runs gt sync and B still points to A? Is that right?

This is an use case. A more common use case we encounter is: • User 1 has stack A + B • User 2 has stack C + D (unrelated to stack A + B) • User 3 checkouts C + D • User 1 merges A • User 3 syncs In this case, I think user 3 is not getting changes from just merged A, as C + D are frozen.

got it. I will try to reproduce.

Please note this use case may not be exact, as all times we had issues with frozen branches it took us by surprise.

sure, to be clear though, the purpose of frozen branches is to prevent accidental modification. I would expect the sync to work as documented, so if it doesnt its a bug which i will attempt to reproduce. Out of curiosity, what is the use case of knowing frozen branches with no intention of modifying them? ie what issue does this cause exactly.

we have projects distributed in multiple repositories with developers working in different projects. It is commons that features being developed in one use features being developed in others at the same time. Thus, a developer working in a PR project A may need a PR in project B before is being submitted. But the user of project B for this developer is pure read-only.

as a side note, i just checked

gt ls

actually does show which branches are frozen

That is true, but then you need to parse an output without an spec. For automations, an explicit command is much more reliable.

okay, i managed to reproduce this needing to unfreeze in order for the restack portion of

gt sync

to work properly. Will bring it up to the CLI team

Thank you for the quick follow up

Thank you for your fast answer!

Hey team, just went over this with a colleague and now i understand that this is expected. In re-reading the docs, it states

be kept up to date with remote changes when it is synced

 which in this case means, remote changes to the branch (not the repository). Since the author of the branches C+D did not restack and submit to remote, those branches themselves are not pointing to the latest main after branch A had been merged. So, the author of the branches needs to restack and submit for gt sync to update frozen branches, OR you can unfreeze when you see the

Did not restack branch .... because It 1s frozen

 warning. Hope this helps.

NOTE: we always do a

gt sync

before doing a

gt submit

(got bitten by not doing that in the past because sometimes would be the equivalent of a

git push --force

) What is happening to us is... • User U1 is working on repo R1 doing

gt sync

&

gt submit

, there may be multiple PRs on top of main or a single stack of PRs (it seems it does not matter). • User U2 is reading repo R1 doing

gt get

or

gt checkout

to get PRs and

gt sync

to sync PRs already in local. • U1 submits PRs to R1, when U2 does a

gt sync

some of the PRs, still not submitted get frozen. Brett, is this the expected behavior?

Thanks. This seems like a very different scenario than the initial one described. We are also perhaps conflating terms here. In this new scenario, you havent mentioned anything of merge. Here (i think) you are suggesting, that gt sync does not fetch new branches in a stack, which is expected.

let's assume I have a local copy of PR1 branch that is on top of main (which is at commit C1). somebody submitted C2, thus the new main is C2. when doing a sync of PR1 I would expect that PR1 is rebased on top of C2, that is what happened in with PR1 in graphite. and this was happening locally until not long ago. Now local PR1 gets frozen, even if no conflicts. Where there were conflicts we'd do a restack to resolve them. Now if no conflicts local PR1 gets frozen. I don't see the purpose of that, there is no conflict and main has moved, thus I have to rebase it anyway. the previous behavior not only was intuitive but what one ends up doing now. Am i getting it wrong?

I can understand if prior to 1.7.0 you didnt need to unfreeze which made life easier and apologize if this is not as smooth an experience as it was previously for your workflow, but i dont think there is anything buggy or unexpected happening here.

What is hard to understand, imho, is why the decision was so bold (let me use this expression). Wasn't it better just to let decide user wether they want to work in automatic freeze/unfreeze, or in "legacy" mode? Which is the point of forcing to work in automatic freeze mode if people feel comfortable with the old way? It is not a bug, as you say, but it is an undesired behavior for us and, I supect, for other users.

I will share this feedback with the team

I could understand this decission if freezing happens in the server side, as then you can somehow profit from this as a team. But, hapenning only in local, it seems just a question of personal tatse. Some users might be comfortable with this defensive freezing, bit others not.

@Brett Bedevian, any update on the possibility of disabling the freezing functionality? It is really getting into our way. We ended up writing some scripts to warn us, but it requires us to more work. To give you an idea, we have a tool that reports us the status of the repos the developer is working on indicating that one of them got frozen, but we need to run this script to know...

Hello, have you tried the

--unfrozen

option?

Oh! Nice. I didn't know this option exists. I will explore if this could be a working solution for us. Thank you!