On Fri, 29 Jul 2011 15:28:44 +0200 Éric Araujo wrote:

Le 29/07/2011 14:50, Antoine Pitrou a écrit :

...

...

changeset: 71562:bdad5bc9a2ed user: Éric Araujo summary: Stop ignoring Mercurial merge conflits files (#12255).

R. David Murray and I think that it’s more useful to have these files show up in the output of “hg status”, to let the user know that some merged file have to be checked before commit.

Mercurial will prevent you from committing before you have solved conflicts, so I'm not sure what this brings. "hg res -l" is the command to remember when you want to list files with conflicts.

People confused by the merge/resolve system could exit their merge tool without actually merging the changes (I know it happened to me!), so these files act as a reminder that not everything is right.

I don't know, I don't use a merge tool. But presumably the merge tool would only call "hg resolve -m" on those files which have actually been resolved? (if it calls that command at all)

...

The fact that "make clean" doesn't wipe these files is an additional annoyance.

make clean removes generated files, but *.rej and *.orig are backups, which you may want to save or re-apply.

What use are these backups really? We are using a (D)VCS, you are not losing anything. Regards Antoine.

On Fri, 29 Jul 2011 16:21:42 +0200 Éric Araujo wrote:

...

What use are these backups really? We are using a (D)VCS, you are not losing anything.

The .orig files after a revert could contain code that’s not committed anywhere. See also RDM’s reply to your message.

I would point out that by using "hg revert", you deliberately want to forget some local changes. Besides, "hg status" is meant to show untracked files which could *potentially* be tracked. It's not like anybody wants to track .orig and .rej files, so having them in the ignore list is still the right thing to do. Regards Antoine.

On Fri, 29 Jul 2011 12:19:45 -0400 "R. David Murray" wrote:

...

Besides, "hg status" is meant to show untracked files which could *potentially* be tracked. It's not like anybody wants to track .orig and .rej files, so having them in the ignore list is still the right thing to do.

That's one view. My view is that 'hg status' tells me all the files that have appeared in my tree that I'm either not currently tracking or explicitly ignoring (because the project's automated tools will deal with them). Nothing in there about limiting it to files I *might* want to track. That is how I've always used my version control systems.

Ok, I understand. However, it also makes things more tedious for other people who don't user their VCS in such a way, so it would be nice how other people feel about this. Regards Antoine.

On Fri, Jul 29, 2011 at 7:22 PM, R. David Murray wrote:

On Fri, 29 Jul 2011 23:36:03 +0200, Antoine Pitrou wrote:

...

On Fri, 29 Jul 2011 12:19:45 -0400 "R. David Murray" wrote:

...

...

Besides, "hg status" is meant to show untracked files which could *potentially* be tracked. It's not like anybody wants to track .orig and .rej files, so having them in the ignore list is still the right thing to do.

That's one view.  My view is that 'hg status' tells me all the files that have appeared in my tree that I'm either not currently tracking or explicitly ignoring (because the project's automated tools will deal with them).  Nothing in there about limiting it to files I *might* want to track.  That is how I've always used my version control systems.

Ok, I understand. However, it also makes things more tedious for other people who don't user their VCS in such a way, so it would be nice how other people feel about this.

They can add those files to their personal .hgrc.  I can't *remove* those ignores via mine.

Well, *I* don't ever want to check in .orig or .rej files (because various tools create them) so I want them in my .hgignore file. Here's a sample .hgignore file I carry around with me: http://code.google.com/p/appengine-ndb-experiment/source/browse/.hgignore -- --Guido van Rossum (python.org/~guido)

Antoine Pitrou writes:

Besides, "hg status" is meant to show untracked files which could *potentially* be tracked.

And if you don't want to track them, you need to deal with them somehow.

It's not like anybody wants to track .orig and .rej files, so having them in the ignore list is still the right thing to do.

No, because their appearance in the working tree means something needs to be dealt with by the programmer. That's unlike other files which are generated and *don't* need to be dealt with by the programmer (or can be deterministically regenerated at will), so can safely be ignored. -- \ “When I was a kid I used to pray every night for a new bicycle. | `\ Then I realised that the Lord doesn't work that way so I stole | _o__) one and asked Him to forgive me.” —Emo Philips | Ben Finney

On Fri, 29 Jul 2011 15:28:44 +0200, =?UTF-8?B?w4lyaWMgQXJhdWpv?= wrote:

Le 29/07/2011 14:50, Antoine Pitrou a écrit :

...

...

changeset: 71562:bdad5bc9a2ed user: Éric Araujo summary: Stop ignoring Mercurial merge conflits files (#12255).

R. David Murray and I think that it’s more useful to have these files show up in the output of “hg status”, to let the user know that some merged file have to be checked before commit.

Mercurial will prevent you from committing before you have solved conflicts, so I'm not sure what this brings. "hg res -l" is the command to remember when you want to list files with conflicts.

People confused by the merge/resolve system could exit their merge tool without actually merging the changes (I know it happened to me!), so these files act as a reminder that not everything is right.

Or people who decide the particular merge tool isn't going to help in a particular case. I do that reasonably often.

.orig is also created by hg revert; my usage is that I remove this file after I’ve checked that the revert is okay.

And by patch. This is my major reason for disliking having these files ignored. I want to know about the .rej and .orig files patch generates that I may have forgotten about, and not just to clean them up. Their existence is a signal that there's something I haven't finished working through (or that I at least need to check that I worked through it before deleting them).

...

The fact that "make clean" doesn't wipe these files is an additional annoyance.

make clean removes generated files, but *.rej and *.orig are backups, which you may want to save or re-apply. I’m not sure it would be right to lose them. Maybe distclean?

Exactly. Which is another reason these files should not be ignored: even distclean should probably not remove the backup files generated by patch, which means that hg status should show the files because they aren't part of the distribution. Which means (assuming there is agreement with my logic :) that make distclean probably *should* remove the stuff generated by coverage, given that we are ignoring that stuff now. --David