When compiling with --enable-shared, the libpython file is not ignored by Mercurial (or Bazaar, I guess).  Any objection to the attached patch?  I used a wildcard, but could also hard-code the full filename with a fixed shared lib number.

I would also propose to remove *.rej and *.orig from the ignore files.  It’s helpful to see them in hg status in case you had a difficult merge and did not fix all files.  My usage is that I remove *.rej and *.orig after I’m done merging (or checking that the revert is okay).

+libpython*.so*  is fine, but please don't remove the rej and orig. By convention and practice, those files are meant to be in .ignore files to prevent accidental checkins.  Usually when the conflict occurs you are notified immediately and you fix them subsequently. Being notified of pending merge by seeing the.rej files in the hg status seems remote to me.

As I've said before, I would vote to not have .rej and .orig in .hgignore.  You can always add them to your personal .hgignore, but I know of no way to tell mercurial "I *don't* want to ignore these files that are in the repo .hgignore".  If there is such a way I'll be happy with that.

> By convention and practice, those files are meant to be in .ignore
> files to prevent accidental checkins.

Maybe with other tools.  Mercurial will tell you what new files are to be added in the next commit once to four times, depending on your setup, so I don’t understand how people accidentally commit .rej files (or .svn directories or Mac OS X crap).

I strictly have not faced any problem with those rej and orig files being present in the .hgignore. I also thought keeping the .hgignore in the repo was for distribution and never knew that it can affect local views (If you remove .rej and .orig your local version, will it help?)

Yes, mercurial presents us with a list of files are that being added/committed, so we can be careful in not add those spurious leftovers. But at a time when you want to be fast with doing everything via cli options you are at a risk of adding unwanted files (unless protected by .hgignore file).

I see that .hgignore can ignore itself. So, once commited with itself to ignore, I believe people can have personal customization in there. This suggestion is with the understanding that repo/.hgignore is just to distribution and does not affect hg tracking behavior. Please correct me if I am wrong here.

I have no idea what you mean by "for distrabution" in this context.  The .hgignore in the checkout causes hg to ignore the files/patterns listed in it when any hg commands are run against that checkout.  And no I can't remove it in my "local copy", since the whole point of the file is that is is under version control in the repo.

By "for distribution", I meant that everyone who checks out ( clones)
from hg.cpython.org repository share the same .hgignore file, instead
of each person having to create their own file. 

I got an impression from the earlier message that hg tracks (or
ignores tracking) based on .hgignore file in the server itself, which
I wanted to clarify.

Well, since there's no central server for hg, it can't track based on the server.  Perhaps I confused you by saying that the .hgignore file was "in the repo".  (It is "in the repo" in the sense that any tracked file is in the repo, but it's effect comes from its existence in the checkout tree from which you are running the hg commands.)

So yes, the .hgignore you get when you clone is so that everybody has the same base list.  That's why we are arguing about its appropriate contents :)

I tried to a line .hgignore inside .hgignore file, so that it can ignore itself (weird concept, but wanted to try if it works) and users can make local customization of it without any problem. This has been suggest at many places in the Internet.  I tried by completing removing the file and adding a new one with .hgignore ignoring itself. But it does'nt seem to work. 

So a possible solution seems like this: If .rej and .orig needs to be removed from .hgignore, one should just remove it from the .hgignore file and for people who do not want to be bothered by .rej/.orig files in hg st, they can create an addition ignore directive in their .hgrc
http://mercurial.selenic.com/wiki/TipsAndTricks#Ignore_files_in_local_working_copy_only

Your experiments with .hgignore and your thoughts about server vs. clone .hgignore give me the impression of a misunderstanding of how it works.

To clarify: The repo .hgignore file is a repo-specific listing of patterns to ignore.  As such, it needs to be shared, i.e. put under version control.

The ignore files (the repo .hgignore and optional files configured in ~/.hgrc or $SOMECLONE/.hg/hgrc) are consulted only for some commands:

- hg status (ignored files are not considered unknown)
- hg add . (a recursive add does not consider ignored files)
- hg addremove (etc.)

This explains why putting .hgignore in the .hgignore file cannot possibly work.

If *.rej and *.orig are ignored, they don’t show up in “hg status”, and are not added with “hg add somedir”.  My point is that this behavior is not useful: it does not protect from anything (who adds directories when merging changesets?  also, who does not run status and diff before commit?  they should), and does not help us check whether we’ve properly merged all files.  I prefer to see the *.rej files in hg status output, check them and delete them.

So, can I commit?  I’m willing to update the devguide and reply to possibly angry python-dev feedback with an explanation of how to ignore those files on a per-user or per-clone basis.

Eric, sure go ahead. As I am not affected by remains of .rej and .orig (neither have I found their usefulness (yet)), so my concerns can be stepped over. Plus, I have found a way to ignore files via patterns in .hgrc.

I already see you and RDM proposing the change, so I am okay to follow. But if you think discussion in python-dev or python-committers would be helpful it would be a good idea, because it affects people's working environment and some might have some concerns or ideas (which might be helpful).

On Sat, Jun 25, 2011 at 08:38:04PM +0000, Senthil Kumaran wrote:
>  As I am not affected by remains of .rej and .orig (neither have I
>  found their usefulness (yet)), so my concerns can be stepped over. 

Just a side-note. I wondered why is my case so, and I realized that I
had integrated k3diff to handle any conflicts during merge so when a
conflict arises, it immediately invokes k3diff and it allowed me to
handle the conflicts giving me the contexts which are stored in .rej
files.

New changeset 4d351135f128 by Éric Araujo in branch '3.2':
Make VCSes ignore the compiled shared library file (#12255)
http://hg.python.org/cpython/rev/4d351135f128

New changeset bdad5bc9a2ed by Éric Araujo in branch '3.2':
Stop ignoring Mercurial merge conflits files (#12255).
http://hg.python.org/cpython/rev/bdad5bc9a2ed

New changeset 9356d2d61e9f by Éric Araujo in branch '2.7':
Make VCSes ignore the compiled shared library file (#12255)
http://hg.python.org/cpython/rev/9356d2d61e9f

New changeset 4e5127874adf by Éric Araujo in branch '2.7':
Stop ignoring Mercurial merge conflits files (#12255).
http://hg.python.org/cpython/rev/4e5127874adf

This is also fixed in 3.3, but I missed a reference in the merge commit message.