P4D2::File list isn't ignoring the .hgignore file

Create issue
Issue #42 resolved
chipersoft created an issue

The .hgignore file created by MacHg doesn't get ignored like the .hg folder and is being considered as part of the repo. Screenshot attached.

Comments (10)

  1. Jason Harris repo owner

    Actually MacHg for the repositories it creates automatically adds the .hgignore file. Maybe this is wrong... I am thinking about it...

  2. Maya Studios

    In most cases the user wants the .hgignore file to be committed as well (and not being ignored). Though I think MacHg should leave the decision about this to the user and don't automaticall add or ignore this file. Simply leave it as "unknown".

  3. Jason Harris repo owner
    • changed status to resolved
    • changed component to UI

    This is question of detail here. I could easily add a little check box to the create repository panel with something like "commit .hgignore" but I feel it would add confusion much more often then it would be used. The vast majority of cases one wants to have the .hgignore file committed to the project. You also want history tracking on this file. When would you not want the .hgignore file tracked? If you are putting different files in there for one platform versus another, then likely those ignores should go in some ignore.platform =... in your .hgrc configuration file.

    I am very willing to listen to arguments about this... but for now I have decided to close this as designed...

    Thanks for the report. Jas

  4. Maya Studios

    Why don't you just let the user decide? Simply don't place the file under version control by default. Then the user can decide whether he/she wants to ignore it or to commit it. No option checkbox involved in this solution.

    I agree, though, that in most cases this file should be tracked/committed, but in my opinion the user should have full control over his/her repository and my solution would achieve this. If you want, you could add a checkbox to the "Create Repository" dialog that reads "Automatically track .hgignore". This checkbox would be checked by default but could be unchecked, if the user wants it. Should be easy enough to implement.

  5. Maya Studios

    Ah - and please correct the title of this ticket (for later search): ".htignore" -> ".hgignore".

  6. Jason Harris repo owner

    If I don't commit something (like the .hgignore) file then the repository will be a virgin repository and then it will be green like you previously saw and it could push/pull to all repositories and most users will wonder what is going on... (You yourself thought it was surely a bug, and it strikes me that you are not a mercurial novice... :) )

    Other than that your solution would be good. I think users are generally confused by virgin repositories and likely its not what the user wants...

    I'll think on this some more.

    You can remove the code

    NSFileManager* fileManager = [NSFileManager defaultManager];
    NSString* hgignorePath = [newPath stringByAppendingPathComponent:@".hgignore"];
    NSData* dataToWrite = [[DefaultHGIgnoreContentsFromDefaults() stringByAppendingString:@"\n"] dataUsingEncoding:NSMacOSRomanStringEncoding];
    BOOL created = [fileManager createFileAtPath:hgignorePath contents:dataToWrite attributes:nil];
    if (!created)
    	[NSException raise:@"Initialize Repository" format:@"MacHg could not create .hgignore file at %@ while initializing the repository.", hgignorePath, nil];
    NSMutableArray* argsCommit = [NSMutableArray arrayWithObjects:@"commit", @"--addremove", @".hgignore", @"--message", @"initialize repository", nil];
    ExecutionResult* commitResults = [myDocument  executeMercurialWithArgs:argsCommit  fromRoot:newPath  whileDelayingEvents:YES];
    if ([commitResults hasErrors])
    	[NSException raise:@"Initialize Repository" format:@"Mercurial could not commit %@ while initializing the repository.", hgignorePath, nil];

    In /MacHg/Classes/Sheets/RepositorySheets/LocalRepositoryRefSheetController.m to experiment with this if you want...

  7. Maya Studios

    Perhaps you should change some things regarding virgin repositories. For example you could:

    • disable the empty badges for remote repositories when the user clicked on a virgin repository (they're quite confusing and don't represent any (or at least not much) useful information)
    • add some notes in some dialogs explaining with a virgin repository can be pushed to any other repository. On second though, pushing a virgin repository should not be possible at all (add a note dialog instead).
    • have some special magic for cloning a (remote) virgin repository. This is the use case when someone just created a repository on a hg hosting service (like bitbucket). For example link the virgin clone directly to the remote repository instead of confusing the user by allowing him/her to choose any remote repository (what he/she doesn't want in most cases). The user can, however, still use the functions provided by MacHg to push/pull changes to/from any other repository.

    Just some thoughts.

    I think adding ".hgignore" just to have something committed so that the user doesn't get confused with a virgin repository is more a hack than a solution. This just "cures" the symptoms, not the root problem (which would be how virgin repositories are displayed to the user).

  8. Jason Harris repo owner
    • Well you can still pull from remote repositories into a virgin repository so they need to be badged to some degree...
    • We could add dialogs as you say but there are a lot of edge cases here...
    • Overall, I could indeed put more work into this area...

    But on balance whats there removes the symptoms, its almost always the right thing to do and its expedient. (You are right though that one at a stretch might call it a hack, except its a fairly innocuous hack and its almost always what the user wants...)

    In any case: As always its a toss up of where to spend programming resources but I'd rather work in say annotation super view, a refactored history editing facility, better NSTask handling so I can detect queries for passwords, better handling for external merge tools, and well lots of other things...

    However, I certainly won't say no to patches which clarify this area at all! Thus if anyone wants to work on this facet of MacHg let me know! We can have a quick phone call / email exchange to work out some agreeable plan of attack...! That would be great!

  9. Log in to comment