a little phrustrated

Tue Jul 22 13:58:31 UTC 2014

Hi Richard,

Sorry for missing this email - it slid out of my queue...

On Wed, Jul 16, 2014 at 8:54 AM, Richard Eisenberg <eir at cis.upenn.edu> wrote:
> 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/#configuration
> , 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>

-- 
Regards,

Austin Seipp, Haskell Consultant
Well-Typed LLP, http://www.well-typed.com/