Can you give us more details on your system so we can try to reproduce? OS / PHP / Webserver / SVN / etc

T5000 cover the "Let users play without arc".
T1508 is related: the git commits the make up a revision are not uploaded ATM. They can be reconstructed, which is what arc patch is doing. See also https://secure.phabricator.com/book/phabricator/article/harbormaster/#change-handoff for an advanced, git-only approach for this.

This is covered well enough in the description of T5000:

• This ticket basically boils down to "I/users don't like arc/phabricator", which is not a fun ticket to deal with. The actual need ("apply pending change locally") is already well-supported, in multiple ways, just not in the way you like.

I use git phab and am very happy with it, it uses arc in the background (at least for now).

I'm not dead-set against it (And it's not my call anyway). but:

• You didn't read Contributing Feature Requests. If you had, you'd provided a better task description.
• This ticket basically boils down to "I/users don't like arc/phabricator", which is not a fun ticket to deal with. The actual need ("apply pending change locally") is already well-supported, in multiple ways, just not in the way you like.
• "Don't like arc" is already covered by T5000.
• Phabricator is not limited to git. What about hg? what about svn? what if the author uses svn and the reviewer uses git?

To be able to know on what commit the patch was base and most importantly rebase it, you need to have the metadatas. What is your concern about adding that feature?

Specifically, if they are not willing to use arc, then it's probably not important for them to retain meta-data anyway.

Then try T5000.

In T9922#147464, @avivey wrote:

use arc patch for that.

use arc patch for that.

Hrrm, double header in the quick create menu is a little weird. Maybe I'll just drop the first header completely, I think it's fairly easy to figure out what the menu is doing.

It might make sense in JAVA world, where IDEs load the whole tree and still don't play nice with everything changing on them (Windows?); So you'd equate "branch" with "workdir" and "disk path", and don't bother the IDE about it.

Our goal is always to solve the core problem, and workarounds are not something we'd generally want to add to the product. If the core problem is poor integration / discoverability between other ticketing systems, that's the problem we'd want to solve. That's Doorkeeper right now or maybe even parts of Nuance. Overall it makes more sense to me to track and resolve external monograms as first class objects than to hack something into custom fields to do something less flexible/powerful.

Well, Doorkeeper looks like hard-integrations. Situation like searchable
zendesk links are IMO more suited for simple custom fields - for example we have
customers that use Kayako, Zendesk, osTicket, etc, and simply link to those
externals with cusstom fields. Partial searches for perticular ID would be great
for all those cases, using single field like "external ticket id".

Phabricator newbie here. This error message doesn't really make any sense without Phabricator experience.
Suggesting a way to fix it would be much better.

Notes for me / the curious:

I'm not a big fan of haunt mode and think it's near the top of the "dumbest features" pile, but it's easy to bring everywhere if you're more of a fan. And maybe we're stuck with doing that anyway one Differential folds into EditEngine.

I also noticed there isn't a haunt mode for Maniphest, not sure if that's something we want to expand everywhere.

Let me at least see if I can tweak the text a little bit, I think this rule can be made more clear than it is.

oh

The logic is "if they've seen them before".

Git 2.5 is less than 6 months old and we haven't seen other interest in this, so it will probably be a while before we get to it, but it's reasonable for us to try to accommodate this better.

I'm going to merge this into T5953, which discusses building a general bulk import workflow (from CSV, LDAP, an external system, etc).

In T9921#147407, @chad wrote:

Is this feature request only for Zendesk URLs?

Exactly what @johnny-bit said. But in my specific use case, it indeed only applies to Zendesk URL's.

Alright, I'll just replace "Add Projects" with "Change Projects".

External ticket system sync / coordination is Doorkeeper for us. If this task is just about making other ticket systems better integrated in Phabricator, it'd just get merged over there.

this could be used with any ticketing system - most ticketing systems have constant prefixes for urls.

Basically this works as well as we think it will work for everything. Once people understand it, they tend to not find it so confusing or mystical. T9759#144069 covers this a little better,

Is this feature request only for Zendesk URLs?

The logic is "if they've seen them before".

FWIW being able to change projects without going to the edit screen was what I was most looking forward to from stackable actions. "Set Projects" feels like the "obvious" choice because that is what I am already familiar with in the edit page.

I edited the answer to make it more clear.
If it works, you can upvote the answer and close the question as resolved.

Ok, it works, thanks!

You have to login using the one time loging token which you generate server side (command line) using /path/to/phabricator/bin/auth recover jpchristie.
Normally it pass all other auth. Then once loged in as administrator you can edit auth providers using auth administration.

Thanks for your fast reply, but it does'nt work. When I go to .../auth, I still get the LDAP login, so I can't enter the normal admin login/password