a little phrustrated

[Edward Z. Yang]

Hello Richard,

> 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, this was fairly painful for me as well.  One way to make the pain
go away and help others out is improve the .gitignore files so these
files are not considered tracked.  Here is another thread discussing
this problem:

    http://comments.gmane.org/gmane.comp.version-control.git/238173

though I haven't read through it fully yet.

> 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, but I CR so infrequently manually Xing through the prompt is not bad
(also, helps me remember if I *actually* forgot to add a file.)  Also,
see above :)

> 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`?

As far as I know, we have a fair amount of latitude in modifying the
linter, so maybe hvr can fix this :)

As for the other questions, I'd love to know answers to them too.

Cheers,
Edward