This got split out in to a separate tab eventually, and I think is generally in reasonable shape.

This hasn't caused any issues yet and we have no plans to show "stuff you're subscribed to".

Haha, okay. Let's just add a link to the transcript.

I deployed the sbuild and saux tiers after this, and they've been running in production for some time.

Ah, your underlying issue is difficulty understanding why pushes are rejected?

T6281 is an older task discussing a possible deadlock under concurrency conditions in custom field reindexing. I think the versioning / locking approach above is probably the cleanest approach to resolving that, as well.

This has been in production for quite a while.

I think the revised version of arc land is about as good as we're likely to get. The new documentation is more clear, and the land operation no longer touches any local branches until the last second (or ever, with --hold), behavior is generally better, we restore the starting state if we fail, and the new output is more clear about what arc land is doing.

Two aspects here, one or both of which may already be partially or fully implemented:

First: HeraldTestConsoleController is currently a big mess with a huge instanceof block.

This feature request doesn't have a use case, which we now require. See Contributing Feature Requests and Describing Root Problems.

I'm just going to close this out since I think it's mostly superseded by T5307, which discusses this and other actions which would be nice to take with query result sets.

Out pf curiosity, why not use the ... syntax instead of copy-pasting the full URL?

Yes, but I have some hesitance around adding "search for a string in another string" fields without building better infrastructure first. There's some discussion in D14411#161139.

We don't check that the path actually exists -- you might be searching for a deleted path that used to exist, or the repository might have a million branches and it only exists on one, and you might have a thousand different repositories too.

That result looks correct to me -- if a package includes "/", that means it includes everything under "/" too. So if you search for /x/y/z.cpp, any package that owns /, /x/, /x/y/ or /x/y/z.cpp will be returned, since any package owning a parent also owns the path itself.

At the moment there is no possibilty to watch a repo

Broadly, if you're using arc land --hold <feature> to preview changes, there are three ways to proceed:

I'm not open to reverting to the old behavior. The new behavior solves a large number of problems for many users, discussed in T9657.

Thanks for digging into this! That explanation makes SVN's behavior a lot more reasonable.

Sure. The best "Next Step" is to just run arc land <branch> again without --hold, although we can be explicit about that and fill in branch in case it was run as plain arc land originally.

The @local part is because I have cluster.instance configured locally, it's normal for it to not be present on regular installs.

There shouldn't be any caches.

• We can't give arc land the old behavior without breaking other (more common) use cases.
• You can push directly from the detached head, per above.
• arc help land is now more clear that merging takes place in a detached state and local branch references are not updated.
• arc cleanup (T3277) may eventually make it easier to clean up these branches.
• It sounds like the old workflow was still fairly labor intensive. Writing a script to help you manage submodules might simplify your workflow overall, as a possible workaround. This script could use slightly lower-level operations than arc land (like git operations and arc amend) to give you more control. arc land does not do anything magical, and is just intended as a convenience wrapper around merging in the most common cases.

Yes, 6 months is a huge amount of time in the scale of arc, although that version is probably new enough to have D9921 (although I don't know if July 26 is the changes it actually includes, or just the date someone might have published some earlier version, and have no idea what _2 means).

The change is merged into the destination branch, but the branch reference is not updated to point to it. The detached HEAD you end up with is the correct state of a merge between the origin branch and the changes you are landing. The documentation could perhaps be more explicit about this.

T5555 and D9921 are earlier similar interactions, where file content could be doubled with newly added directories.

Can you show me the output of arc version?

I can't reproduce that. Here's what I did:

Why are you using --hold if your next steps are the steps that arc land would take anyway?

What do you expect it to do?

This should be fixed in HEAD. Thanks for the exceptionally clear report, and let us know if you run into anything else.

The onscreen instructions for this adapter in the UI are also a bit out of date because the Google console has been updated since we wrote them. This is probably the next change to touch the provider, and should also look at modernizing the instructions.

The UI instructions about navigating the dashboard are also a little out of date since that UI has changed, although I was still mostly able to figure out what they meant. I'll leave a note on T5591 to update them when that gets fixed.

For completeness, T9953 / D14735 cleaned up an obscure rough edge on a narrow range of Git versions.

This is deployed and working properly.

I added some properties:

Yes, we can't help with this without better reproduction steps. In particular, I can't reproduce this. Here's what I did:

D14748 should fix the double feed stories.

The behavior of TITLE and VISIBILITY are also wrong: they emit the current body text, not the body text at the time the change was made.

I think this is happening because both the "Title" and "Body" transactions are emitting text:

This should be ready to go with the deployment tomorrow: