a little phrustrated

[John Lato]

Speaking more as a bystander than anything else, I'd recommend that the ghc
dev team just go ahead and detab files. Yes, merging branches will be
painful, but it's a one-time pain. Better that than the ongoing pain mixed
tabs and spaces seem to be causing.
And merging doesn't even have to be that painful. Just cherry-pick the
detab commit into your wip branch, if there are any conflicts resolve them
to your branch, detab again and commit. It could be completely automated.

John L.

On Jul 16, 2014 6: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.
>
> 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?
>
> 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
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140716/e847d95a/attachment.html>