We could maybe git ls-tree -r -d -- <tree> and then parse that. Still a lot of stuff, but somewhat less than the other approaches -- it only takes about 20ms to generate for phabricator/. If that output more than 5K paths or whatever we could give up and fall back to an unfolded list.

Looks like this will require either an uncomfortable number of calls to git ls-tree, or a call to git ls-files followed by a possibly very large filtering and groking of its output.

This comment was removed by the ghost of Christmas past.

rCOREf9b858d57460 gives web nodes sudo access to svnserve when they're proxying SSH connections.

Tried running 2.6.2 on the server side, and that indeed does fix the bundle2 issue, but creates more issues when trying to push from a 3.7.3 hg client.. :-(

If I host externally, I basically lose the access control and herald rules, right?

We host most of our Mercurial repositories externally - this is primarily the infrastructure we had prior to adopting Phabricator. We have a few repositories hosted by Diffusion, however our server runs 2.6.2 which does not utilize the bundle2 protocol.

T8407 holds a small piece of UI for this.

I believe D15612 introduced the bug, but unclear why newDialog isn't doing the right thing here overall. Easy to revert.

Some additional cases with this:

Thanks for suggestion guys. Will do the workaround.

As a workaround you can create credentials in Passphrase, then select the credential and click "Continue"

I dug everything up here.

Can this be closed now? I don't think there's enough in here to reproduce.

I've triggered similar problems running reparse on a repository where branches had been deleted that were tracked.

Hmm, odd. That definitely isn't the POST issue (although I suspect that may be an issue in some cases). The behavior will hopefully be more clear once master promotes, and definitely easier to debug. I'll dig into it a bit on my side in the meantime, I have a few ideas of things to try now. Thanks for your help!

Unfortunately, no dice. I removed the jar file, and added a jpeg. I have attached a trace of running GIT_TRACE=1 git lfs fetch origin.

Oh, I think I might know what's wrong. If you repeat the same process with a viewable file (like a JPEG or PNG) does that work?

Can confirm that navigating to the file in diffusion will let me download it, and it really does give me back the right file.

Hmm, I'm not immediately sure -- that all looks correct on your side to me. Let me add some kind of basic LFS administration page that shows Phabricator's view of LFS objects in the repository -- hopefully that will shed some light on where things are breaking down.

As an addendum, I can definitely find the zip file on the box...

I'm on latest stable (fea2389), and I just tried the following

$ git clone ssh://git@phabricator.example.com:222/diffusion/18/lfs-test.git                                                                     [10:54:36]
Cloning into 'lfs-test'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.                                                                                                                       
$ cd lfs-test/                                                                                                                                  [10:56:39]
$ git lfs install                                                                                                                               [10:56:42]
Updated pre-push hook.
Git LFS initialized.                                                                                                         
$ git lfs track "*.jar"                                                                                                                         [10:57:05]
Tracking *.jar                                                                                                  
$ cp ../some/path/antlr-3.2.jar .                                                                                                               [10:57:19]
$ ls                                                                                                                                            [10:57:52]
antlr-3.2.jar                                                                                                       
$ git add antlr-3.2.jar                                                                                                                         [10:57:54]
$ git commit -m "testing"                                                                                                                       [10:57:57]
[master (root-commit) 2690d02] testing
 1 file changed, 3 insertions(+)
 create mode 100644 antlr-3.2.jar
$ git push -u origin master                                                                                                                     [10:58:04]
Git LFS: (1 of 1 files) 1.84 MB / 1.84 MB                                                                                                                
Counting objects: 3, done.
Delta compression using up to 6 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 329 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To ssh://git@phabricator.example.com:222/diffusion/18/lfs-test.git
 * [new branch]      master -> master
Branch master set up to track remote branch master from origin.

so far so good. however...

$ cd ..                                                                                                                                         [10:58:18]
$ rm -rf lfs-test/                                                                                                                              [10:59:45]
$ git clone ssh://git@phabricator.example.com:222/diffusion/18/lfs-test.git                                                                     [10:59:50]
Cloning into 'lfs-test'...
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.
Checking connectivity... done.                                                                                                                     
$ cd lfs-test/                                                                                                                                  [11:00:15]
$ ls                                                                                                                                            [11:00:19]
antlr-3.2.jar
$ cat antlr-3.2.jar                                                                                                                             [11:00:45]
version https://git-lfs.github.com/spec/v1
oid sha256:4c8737014e7ca0d2c85171edf37f5a26b2d8d8237c283357b81a3269b6848d38
size 1928009                                                                                         
$ git lfs fetch origin                                                                                                                          [11:05:19]
Fetching master
Git LFS: (2 of 1 files) 0 B / 1.84 MB                                                                                                                    
Repository or object not found: http://phabricator.example.com/file/data/w5mihitt7ijile3b7n44/PHID-FILE-kbhl75cnfm6nwks7ojmf/dosd5iqevvn3rune/lfs-4c8737014e7ca0d2c85171edf37f5a26b2d8d8237c283357b81a3269b6848d38
Check that it exists and that you have proper access to it
Warning: errors occurred                 

I'm just going to merge this into T10337, which discusses providing modern endpoints. repository.create is a broken mess and we tend to replace it rather than fixing it (it can't reasonably be fixed without breaking the API, anyway, so we'd end up with a new endpoint in effect, regardless). The new diffusion.edit will fix this and the many other problems with repository.create.

(This is paused since we're waiting on feedback -- if you give it a shot, let us know how things go.)

I doint know if we can make it an array.

@20after4 and @epriestley may we can do

In this specific case (staging same as origin) we could just not push the base tag (it has no value in this case). We can probably even figure that out automatically without needing configuration. That would be a cleaner fix, I think?

When using a repo as its own staging, I kinda hoped that we won't be using refs/tags/ but refs/phabricator/ or something, so when cloning, the default would be "do not clone all staging things".

I'm thinking for my case, there's not really a lot of value in keeping the tags around after the diff has been closed. Maybe that's something to consider?

I probably wouldn't show them in the UI for now, although I don't think adding an "Other Refs" table underneath tags/branches on the main screen with, say, 5 entries and a "See All" button would necessarily be terrible if anyone can come up with a reason that users might ever care about it.

I've been using this functionality for some days to use the CircleCI integration. Mostly the user experience is fine. It's mostly possible to configure git log to ignore these tags, like:

Wikimedia is definitely interested in this one.

To actually do forking, the pathway is roughly:

We can do "private branches", but you can already do something like this:

Specifically, the issue here is that we fetch and import branch heads, but not other refs, including tags. We also aren't totally consistent about which refs we import across hosted/imported repositories.

We can't reproduce this and we haven't learned any new information in more than a month, so I'm going to close it.

This report does not include reproduction steps. Bug reports must include complete, self-contained reproduction steps to be accepted by the upstream. See Providing Reproduction Steps for help.

This would be really nice to see, as we do post-commit code review with Audit and we semi-frequently encounter commits that have near-100% changes due to white space as someone hits an auto-formatter or changes svn:eol-style to match convention and doesn't split this out into separate commits.

T7789 has some discussion, but there's now a clear pathway forward here which doesn't require anything too drastic. Specifically: