Hi Richard,
Sorry for missing this email - it slid out of my queue...
On Wed, Jul 16, 2014 at 8:54 AM, Richard Eisenberg
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.
Yes, you can use: $ git config --global diff.ignoreSubmodules dirty to ignore this. If you don't pass --global, it will only take affect in the repository you perform it in. This should fix this problem.
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/#configurat... , but the details there are sparse. Any advice?
No, it doesn't look like it I'm afraid. I asked upstream about it this morning (it was very easy to write a patch for), and unfortunately they do not want to allow this feature (it's very easy to add it as a config option, but I digress). In the mean time, you can use 'arc alias' to create a version of 'arc diff' like what you want: $ arc alias udiff diff -- --allow-untracked Then run: $ arc udiff instead. I think this is really a short-term solution; in the long run we should commit .gitignore entries for everything since the reason for this is that having untracked files is generally a liability that should be caught.
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`?
I'm afraid right now I don't have some fancy stuff to help automate this or alleviate it. I personally suggest that we take the pain on these as an opportunity to remove things, per recent discussions. We can't remove it all in one swoop, but we should start being aggressive about enforcing style errors. In short, I'd suggest you - Add silly excuses for now - Land your changes - Commit fixes for the lint errors *after* that. - Commit lint fixes one file at a time. If we keep doing this, we'll begin making a lot of headway on this, I'm sure. (The nice thing is that now, you can be lazy and fix violations, then let Phabricator or Travis-CI do builds for you.)
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!)
We could exclude all the files that have tabs, but it would be a lot still. See above though - I suggest we use this as an opportunity to remove this stuff. Just be aggressive about cleaning it up after it lands. The average lifespan of a review is fairly short in practice. I think it should be pretty easy to keep up. The lint rules do still need some tweaking probably though, so if you do see something bogus, please do so.
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.
That's correct, but separated by spaces should work too - thanks!
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?
Joachim ran into this today. In short, I fixed this by tweaking the repository settings. Phabricator will now autoclose commits ONLY if they occur on the master branch. This means you should feel free to push to wip/* branches as much as you want without fear now. Sorry!
7) How can I "re-open" my revision?
I'm afraid you can't.
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?
This is a bug in my script because it's a piece of crap, both the failure and the build logging. I'm working on a Much Better Version™ not written in Shell script but Haskell that should fix all this, hopefully I can deploy it soon. It will also include more features that may or may not actually work. :) I'd prefer to keep the log files compressed if that's OK. An uncompressed log from ./validate is over *ten* megabytes already, and it doesn't even correctly capture *all* of the logs! In comparison, the .gz version is a short 300kb. That's a crazy space savings, especially since this bot will hopefully report more soon.
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?
Again, bug. Sorry about that. The shell script is already falling on its face.
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.
There's unfortunately no syntax for this. HOWEVER, I have just this morning rolled out a change to phabricator.haskell.org that now allows you to set the Trac issue #s in a revision, and it will hyperlink it! For example: https://phabricator.haskell.org/D88 Look at the 'Trac Issues' field, which hyperlinks to the right issue - yay! You can even specify this field when using arcanist, if you add something like: 'Trac: #9303' to the commit message when you run `arc diff`.
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.)
Actually, it looks like most of them are *my* fault, but I hope all of these answers help a lot!
Many thanks, Richard
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/