Page MenuHomePhabricator

arc land doesn't return to local tracking branch if it has a different name from the remote branch it's tracking
Closed, ResolvedPublic


When testing out the awesome changes from T9657, I ran into a case that seems like it might be a bug, where Arcanist ends up on detached HEAD after landing instead of the local branch that was landed onto, if the local landing branch has a different name from the remote branch it's tracking:

  1. Create a new local tracking branch with a different name from its remote branch, e.g. git checkout -b slv --track origin/superlongversion
  2. Create a feature branch that tracks the local branch, e.g. arc feature somefeature slv
  3. Make changes on the feature branch, get them reviewed, and then run arc land

At this point, Arcanist successfully lands the changes into the local slv branch and pushes them to the superlongversion branch on origin, which is great. However, when it's done, it ends up on detached HEAD, because it can't find a local branch called superlongversion.

It would be nice if Arcanist checked out the local branch it landed onto in this case, rather than looking for a local branch with the same name as the remote branch that it ultimately pushed the changes to.

Event Timeline

edibiase updated the task description. (Show Details)
edibiase added a project: Arcanist.
edibiase added a subscriber: edibiase.

oh come on you're just making up new workflows at this point

oh come on you're just making up new workflows at this point

I apologize if these requests are coming off as spammy. I really appreciate all that you've done to make using our workflows easy, and my only goal in filing tasks like this one is to let you know when something I'm trying to do seems to end up in an unexpected place.

To provide a bit more detail on the motivation for this: it results from the fact that we have "namespaces" for branches in our repository, which can result in long branch names. For example, I might be working with some other folks on a branch on origin called experiments/extract-x-from-y, but, to keep things concise in my local repository, I'd call my local tracking branch just extract-x-from-y.

So, in that case, I'd create feature branches off of extract-x-from-y, post them for review, land them back into my local tracking branch, and then push that tracking branch to its counterpart in origin. Ultimately, if extracting x from y goes well, my team would then land experiments/extract-x-from-y back into master, safe in the knowledge that all of its changes had been reviewed along the way.

For what it's worth, having arc land drop me off on a detached HEAD instead of extract-x-from-y isn't a really big deal; it's easy to check out extract-x-from-y if I need to, and, arguably, I might want to check out some other branch anyway. So, from my perspective, this isn't a particularly high-priority item, and I'm sorry if I gave the impression that it was. I just wanted to file it since it's something I ran in to and I wanted to make you aware of it.

This is just a big mess to resolve in the general case because we need to identify a path from whatever was landed to the remote, then cascade changes down along it, because there may be an arbitrary number of local branches between the target and the remote.

After D14361, the new behavior is so complicated that I don't think I can briefly explain it, but very roughly:

  • After running arc land feature --onto master, try to find a path between local feature or local master which connects to the remote through tracking branches.
  • If we succeed, walk from the remote down the chain updating everything. Leave the user on whatever's at the end of the chain.

In the simple case, this degrades to the old behavior. In your case, it should do what you want. In more complex cases, it should do something reasonable/desirable, probably.

I think that will fix things, let me know if you run into more cases.

This works great now; thank you very much!

There was one more followup in T3855 to fix a couple of bugs, but if you updated this morning you probably picked that up.