RFR (XS) 8200430: Remove JTwork and JTreport from the .hgignore files (original) (raw)

coleen.phillimore at oracle.com coleen.phillimore at oracle.com
Fri Mar 30 14:58:52 UTC 2018


On 3/30/18 9:13 AM, David Holmes wrote:

On 30/03/2018 9:34 PM, coleen.phillimore at oracle.com wrote:

On 3/29/18 7:25 PM, Vladimir Kozlov wrote:

On 3/29/18 4:22 PM, David Holmes wrote:

On 30/03/2018 1:04 AM, coleen.phillimore at oracle.com wrote:

open webrev at http://cr.openjdk.java.net/~coleenp/8200430.01/webrev bug link https://bugs.openjdk.java.net/browse/JDK-8200430

I can see these were added somewhat incidentally as part of another fix, but I also recall a discussion on slack about it. Why do you want to remove them from .hgignore? I remember our slack conversation said it was ok to remove them. I was referring to a conversation a while ago to add them. Yes, why? It is useful to have them there instead of having copy of .hgignore  on each machine I run. Stefan has an offlist discussion with me about this too.  Why do you have them in your .hgignore?  I want to purge them when I say hg purge, but I guess I can also type hg purge -all.    Is it for hg status to find actually new files that haven't been hg added yet? That seems useful to me also. Yes I want hg status to ignore them so I don't have to type "hg status -mard". I have a least three "home" directories with a .hgignore that I have to copy across. :) I was not familiar with "hg purge" but it seems to me that an extension that specifically deletes untracked file should not be honouring the .hgignore rules. Though I guess if it uses hg status to find those untracked files ... Not sure what consideration weighs the most here. :)

Yours does!  It always does :)  I'm going to withdraw this RFR and document this discussion in the RFE.  I have an hg purge set of options that removes JTwork directories now.

Coleen

David

thanks, Coleen

Vladimir

FWIW I had these in my local .hgignore anyway so can always add them back there. David Tested in local repository. Thanks, Coleen



More information about the hotspot-dev mailing list