a little phrustrated

Jan Stolarek jan.stolarek at p.lodz.pl
Thu Jul 17 07:35:19 UTC 2014

I've used Phabricator for the first time yesterday and have also experienced most of the problems 
mentioned by Richard. The most painful ones were:

1. Complaining about any untracked or uncommited changes in the source tree. This is mostly 
annoying. How can I tell arcanist to ignore such changes? Rant: I really don't like tools that 
try to be smarter than me and prohibit from doing what I want them to do.

2. Linters. I vote to disable the tab linter - we already have mechanisms to prevent introducing 
tabs in the source code. I'd also vote to disable whitespace linter unless we can tweak it to 
complain only about whitespaces introduced by commits in question.

I've also run into issues with updating my revision. `arc diff` did not seem to work. Sadly, I 
don't remember the details - I'll write them down if it happens again.


Dnia środa, 16 lipca 2014, Richard Eisenberg napisał:
> Hi all,
> I'm trying to use Phab for the first time this morning, and hitting a fair
> number of obstacles. I'm writing up my experiences here in order to figure
> out which of these are my fault, which can be fixed, and which are just
> things to live with; and also to help others who may go down the same path.
> If relevant, my diff is at https://phabricator.haskell.org/D73
> 1) I had some untracked files in a submodule repo. I couldn't find a way to
> get `arc diff` to ignore these, as they appeared to git to be a change in a
> tracked file (that is, a change to a submodule, which is considered
> tracked). `git stash` offered no help, so I had to delete the untracked
> files. This didn't cause real pain (the files were there in error), but it
> seems a weakness of the system if I can't make progress otherwise.
> 2) I develop and build in the same tree. This means that I often have a few
> untracked files in the outer, ghc.git repo that someone hasn't yet added to
> .gitignore. Thus, I need to say `--allow-untracked` to get `arc diff` to
> work. I will likely always need `--allow-untracked`, so I looked for a way
> to get this to be configured automatically. I found
> https://secure.phabricator.com/book/phabricator/article/arcanist/#configura
>tion , but the details there are sparse. Any advice?
> 3) The linter picks up and complains about tabs in any of my touched files.
> I can then write an excuse for every `arc diff` I do, or de-tab the files.
> In one case, I changed roughly one line in the file (MkCore.lhs) and didn't
> think it right to de-tab the whole file. Even if I did de-tab the whole
> file, then my eventual `arc land` would squash the whitespace commit in
> with my substantive commits, which we expressly don't want. I can imagine a
> fair amount of git fiddling which would push the whitespace commit to
> master and then rebase my substantive work on top so that the final,
> landed, squashed patch would avoid the whitespace changes, but this is
> painful. And advice on this? Just ignore the lint errors and write silly
> excuses? Or, is there a way Phab/arc can be smart enough to keep
> whitespace-only commits (perhaps tagged with the words "whitespace only" in
> the commit message) separate from other commits when squashing in `arc
> land`?
> 4) For better or worse, we don't currently require every file to be
> tab-free, just some of them. Could this be reflected in Phab's lint
> settings to avoid the problem in (3)? (Of course, a way to de-tab and keep
> the history nice would be much better!)
> 5) In writing my revision description, I had to add reviewers. I assumed
> these should be comma-separated. This worked and I have updated the Wiki.
> Please advise if I am wrong.
> 6) When I looked at my posted revision, it said that the revision was
> "closed"... and that I had done it! slyfox on IRC informed me that this was
> likely because I had pushed my commits to a wip/... branch. Is using wip
> branches with Phab not recommended? Or, can Phab be configured not to close
> revisions if the commit appears only in wip/... branches?
> 7) How can I "re-open" my revision?
> 8) Some time after posting, phaskell tells me that my build failed. OK.
> This is despite the fact that Travis was able to build the same commit
> (https://travis-ci.org/ghc/ghc/builds/30066130). I go to find out why it
> failed, and am directed to build log F3870
> (https://phabricator.haskell.org/file/info/PHID-FILE-hz2r4sjamkkrbf7nsz6b/)
>. I can't view the file online, but instead have to download and then ungzip
> it. Is it possible to view this file directly? Or not have it be
> compressed?
> 9) When I do view the build log, I get no answers. The end of the file
> comes abruptly in the middle of some haddock output, and the closest thing
> that looks like an error is about a missing link in a haddock tag
> `$kind_subtyping` in Type.lhs. I didn't touch this file, and I imagine the
> missing link has been there for some time, so I'm dubious that this is the
> real problem. Are these log files cut off?
> 10) More of a question than a phrustration: is there a way to link directly
> to Trac tickets and/or wiki pages from Phab comments? I like the Phab:D73
> syntax from Trac to Phab, and thanks, Austin, for adding the field at the
> top of Trac tickets to Phab revisions.
> I did fully expect to hit a few bumps on my first use of this new tool, but
> it got to the point where I thought I should seek some advice before
> continuing to muddle through -- hence this email. I do hope my tone is not
> overly negative: I'm *very* appreciative of the work that many of you do to
> support GHC's infrastructure, and I look forward to being able to get and
> provide source code feedback through Phab. We just need to work out some
> kinks, I think! (Any number of these kinks may be solely my fault, of
> course.)
> Many thanks,
> Richard

More information about the ghc-devs mailing list