I believe the tracker sent an error message to python-dev as a
result of a failed hook execution. If someone with the
power would release that message so we can see what the error
was, I'd appreciate it :)
--David
___
Python-Dev mailing list
Python-Dev@
hersome, and a double underscore name stands out very
> clearly as being part of the infrastructure rather than
> something user-defined.
But directly calling a __xxx__ method in Python is a very
unusual thing to do. It would be extremely odd to have that
be the expected way to call a
or may not be true of unittest, but if it hasn't been
maintained its present utility is questionable so it may be just as
well to delete it.
--
R. David Murray www.bitdance.com
___
Python-Dev mailing list
Python-Dev@
long as we aren't distributing mercurial itself, I don't see
how a script could be a problem. But, then, IANAL.
--
R. David Murray www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://ma
branch. You are even less likely to hit a push race by
following that technique, since the time between the pull -u and the
push is minimized.
--
R. David Murray www.bitdance.com
___
Python-Dev mailing list
Python-Dev@py
On Thu, 17 Mar 2011 05:11:23 +0100, Jesus Cea wrote:
> On 17/03/11 04:41, R. David Murray wrote:
> > Dealing with a null merge when someone else has committed between the
> > time I started the merge dance (I always pull just before I start that)
> > and the time I push is
On Thu, 17 Mar 2011 11:26:13 +0100, Georg Brandl wrote:
> Am 17.03.2011 06:14, schrieb R. David Murray:
> > The fun part comes if there are changesets. At this point there
> > are two options: go through each of the branches doing an up/merge/ci,
> > and then pull/push. O
could indeed be a better way to
go for this particular scenario. I'll have to check that out.
--
R. David Murray www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinf
On Thu, 17 Mar 2011 13:35:50 +0100, Jesus Cea wrote:
> On 17/03/11 06:14, R. David Murray wrote:
> > Clearly, this procedure is not for everyone
>
> Clearly not :).
>
> So you do a "hg strip" and start over again.
>
> The problem with this is that you
On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou wrote:
> On Thu, 17 Mar 2011 09:24:26 -0400
> "R. David Murray" wrote:
> >
> > It would be great if rebase did work with share, that would make a
> > push race basically a non-issue for me.
>
> reba
e above sense to worry about.
When I start working on a feature branch I will be working in a separate
clone and will not rebase. But I will probably produce a collapsed
patch when I'm ready to apply to mainline, so the concern with rewriting
On Thu, 17 Mar 2011 16:00:50 +0100, Antoine Pitrou wrote:
> On Thu, 17 Mar 2011 10:50:24 -0400
> "R. David Murray" wrote:
> > On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou
> > wrote:
> > > On Thu, 17 Mar 2011 09:24:26 -0400
> > > "R.
On Thu, 17 Mar 2011 20:00:29 +0100, Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 17/03/11 14:45, R. David Murray wrote:
> > Not if the cpython repo is in a fully merged stated. And if it
> > isn't, I will wait until it is. (The update
hrough the
whole thingan issue was submitted for a particular section and I
updated that section and the other one talking about the same topic
(sorry I don't remember which one off the top of my head)).
--
R. David Murray http://www.bitdance.com
__
generated one last
time for its upcoming last bugfix release. It's easy enough (now that we
no longer have to deal with svnmerge) that I've been doing that, myself.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mail
hange.
>
> Anyway, I thought I was supposed to pull from head to 3.2 and 2.7. What is
> "dev"?
That's "doc speak", I guess. http://docs.python.org/dev/library, for
example, points to the library reference for the docs on the default
branch.
--
R. David Murray
On Thu, 17 Mar 2011 14:33:00 +0100, wrote:
> On Thu, 17 Mar 2011 09:24:26 -0400
> "R. David Murray" wrote:
> >
> > It would be great if rebase did work with share, that would make a
> > push race basically a non-issue for me.
>
> rebase as well as str
On Sun, 20 Mar 2011 12:17:25 +0100, Antoine Pitrou wrote:
> Le dimanche 20 mars 2011 à 00:06 -0400, R. David Murray a écrit :
> > On Thu, 17 Mar 2011 14:33:00 +0100, wrote:
> > > On Thu, 17 Mar 2011 09:24:26 -0400
> > > "R. David Murray" wrote:
> >
On Sun, 20 Mar 2011 00:06:01 -0400, "R. David Murray"
wrote:
> It would have been nice if rebase had refused to run given that
> there were merges, since it clearly doesn't work in that case.
To clarify, that should have read "given that there were merges
*between br
ges (except
for the RFC 4180 one) and made them on 3.1, 3.2, and harmonized default.
So this should all be good now, except for the RFC change. I guess I'll
see about doing that one later.
--
R. David Murray http://www.bitdance.com
___
o you're working with.
And, as I discovered, only if they are on a single branch. Which is
something *none* of the documentation I've read has mentioned. Perhaps
that's because named branches are relatively new?
--
R. David Murray http://www.bitdance.com
before starting my merge dance and am unlikely
to *re*run the regrtest after having to do an hg pull/merge heads,
exactly the same size hole is going to exist in my hg workflow.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing l
latform-independence. UNIX won't
> understand that, and I don't think we're gonna be able to convince all
> the kernel developers to implement this simplified shebang.
+1. If one of the points is to be compatible with PEP 394, then
the above seems like a bad
ad the same need to merge to tip as with hg,
and the same lack of enforcing of the running of tests.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
On Mon, 21 Mar 2011 18:33:00 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
> > On Mon, 21 Mar 2011 14:07:46 +0900, "Stephen J. Turnbull"
> wrote:
> > > No, at best the DVCS workflow forces the developer on a branch to
> > >
On Mon, 21 Mar 2011 15:59:51 +0100, Adrian Buehlmann wrote:
> On 2011-03-21 14:40, R. David Murray wrote:
> > On Mon, 21 Mar 2011 18:33:00 +0900, "Stephen J. Turnbull"
> > wrote:
> >> R. David Murray writes:
> >> > On Mon, 21 Mar 2011 14:0
hell does, while my bash shell doesn't: because I
don't use bash, I installed mercurial without bash-completion.
So: there is completion support for hg update for both bash and zsh.
Not sure about other shells.
--
R. David Murray http://www.bitdance.com
7;t really know (probably a null merge, but you'll
have to figure out the state of your repo first...or you could start
over with a fresh clone).
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
to some
> sort of serialization scheme?
Note that svnmerge broke at exactly the same scale point, for exactly the
same reason: every svnmerge touched root properties, thereby effectively
serializing access to the tree. There were lots of curses from people
trying to svnmerge at th
made changes, whereas that safety-belt svn up before
the svn ci doesn't.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
from
one or more people with interest in this area, maybe we can get some
people with relevant knowledge onto the development team.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.or
orrect solution, otherwise you'll
just run in to the trouble when you try to merge the branch into default.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinf
operly, but they are isolated
cases and don't bother me much (mostly a couple older tools that just
don't have good non-ascii support).
> Mind you, I've never managed to get the <-- button working reliably
> either, but to be fair that's insanely complicated too.
No idea
On Sun, 27 Mar 2011 19:46:35 +0100, Jon Ribbens
wrote:
> On Sun, Mar 27, 2011 at 02:21:25PM -0400, R. David Murray wrote:
> > > Mind you, I've never managed to get the <-- button working reliably
> > > either, but to be fair that's insanely complicated
part is debugging the TAL when you make a mistake, but
even that isn't a whole lot worse than any other templating language.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
les to your personal ignore list See the 'ignore'
entry under 'ui' in the hgrc documentation.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo
On Wed, 30 Mar 2011 12:17:05 +1100, Mark Hammond
wrote:
> On 30/03/2011 12:09 PM, R. David Murray wrote:
> > The solution is to add such
> > directories and/or files to your personal ignore list See the 'ignore'
> > entry under 'ui' in the hgrc document
> elegant solution.
Flicker or not, I don't like it myself. I've turned off javascript on
bugs.python.org in my browser, and now it doesn't bother me anymore.
But I don't think that is a good long term solution. Making it optional
based on a setting in the user profile might
indeed redundant, but the sidebar is not really usable here.
I agree with this point. The sidebar list of questions is effectively
useless.
Most FAQ lists start with the long list of questions. I don't see
why this one should be different :)
--
R. David Murray http://www.bitdance.com
On Thu, 31 Mar 2011 23:59:36 +0200, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
wrote:
> Notice that the issue title was always there, in your browser's title
> bar (unless you have a web browser that doesn't display the page title).
I do.
--
R. David Murray http://
On Fri, 01 Apr 2011 08:29:29 +1000, Nick Coghlan wrote:
> On Fri, Apr 1, 2011 at 2:34 AM, R. David Murray wro=
> te:
> > I agree with this point. =A0The sidebar list of questions is effectively
> > useless.
>
> Indeed. If it's simple, I'd actually be inc
On Fri, 01 Apr 2011 12:47:12 +0200, Georg Brandl wrote:
> Am 01.04.2011 01:12, schrieb R. David Murray:
> > On Fri, 01 Apr 2011 08:29:29 +1000, Nick Coghlan wrote:
> >> On Fri, Apr 1, 2011 at 2:34 AM, R. David Murray
> >> wro=
> >> te:
> >> >
e can argue about the semantics when we
discuss individual tests :)
100% branch coverage as measured by coverage.py is one good place to
start for building such a comprehensive test suite. Existing tests
for C versions getting (or newly testing) Python code is another.
Bug reports from alternate
rs. It never occurred to me to change the variable and type c
> without first checking that the variable had changed... :-)
>
> It is however fixed in 2.7.
For the curious:
http://bugs.python.org/issue5215
--
R. David Murray http://www.bitdance.com
_
#x27;t reread the PEP to check.) The
idea is to use the test suite as the check for this, adding tests as
necessary.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
27;t that distutils2 would help the OP,
but that the OP could help Distutils2 and the community by taking his
use case to the developers and making sure that that use case is
supported before the release of packaging in 3.3.
--
R. David Murray http://www.bitdance.com
l super() is almost certainly deliberate.
Why not? It seems more useful than using it for chaining,
especially given the compiler hack in Python3.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python
> IronPython,
> and Jython to succeed, does the CPython project need to come to a halt? I
> don't
> think many people here really believe that to be the case.
No, I don't think any of these things are aims. But if/once the Python
stdlib is a separate repo, then in *that*
a mailing list for
security related announcements on which only the "security officer" or
"security team" posts announcements, and security related announcements
*only*. Then then the people responsible for security in any context
(a distribution, a
ually.
I agree that this is a concrete example that the PEP could address.
I myself don't know enough about decimal/cdecimal or the Python C API
to know why cdecimal can't duck type here, but it certainly sounds
like a good example to use to clarify the requirements being advocated
by the PEP
ng implementation-pain-wise and
lets-make-this-work-wise with the other implementations. The end result
will be better test coverage and clearer APIs in the stdlib.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On Sun, 17 Apr 2011 19:17:11 +0200, Stefan Krah wrote:
> R. David Murray wrote:
> [snip a lot]
>
> Thank you, this cleared up many things.
Heh. Keep in mind that this is my viewpoint. I *think* Brett agrees
with me. I'm sure he'll speak up if he doesn't.
> Th
(or even perhaps CPython developers) may want to
contribute Python-only versions and/or tests for things that would have
been affected by the PEP. I don't have time to do it right now,
but if I can pry any time loose I'll have it near the top of my list.
--
R. David Murray
y or any platform without
an accelerator (that is, anything *using* the python code) would be
expected to pass it.
I would hope that such tests would be vanishingly rare (that is,
that all needed tests can be expressed as black box tests).
--
R. David Murray http:/
on which to register the defect.
>
> What kind of object is *obj*?
Whatever object is being used to represent the data being parsed when
the defect is found. Right now that's always a Message, but that won't
continue to be true. The rest of
I'm not
> sure we want that at this point.
Personally, I consider myself an stdlib maintainer: I only occasionally
dabble in C code when fixing bugs that annoy me for some reason.
I suppose that's why I'm one of the people backing this PEP. I think
there are other CPython
27;s always the practicality beats purity argument:
if the PEP turns out to really get in the way of something everyone wants,
then we can agree to an exception.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-De
also enlightening to look at the output of hg churn. The number
of active CPython developers over the past year is not huge, and very
few of them have spoken up in this thread.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailin
; what "public" vs "private" is for) should not be tightly coupled to the
> > decision about whether to bother to explain what an API does?
>
> With what criteria would you propose to replace it with?
I believe Jean-Paul was suggesting that just because an interface is
language design principle (as I understand it) is that
mutable object do not return themselves upon mutation, while
immutable objects do return the new object.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@python
27;t remember what
it was, though.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
pull
in .hg/last-message.txt, and just type 'Merge' in front of my previous
first line. I don't add the merge-from number, because I figure if you
know which branch you are looking at you know which branch the merge
came from, given that there is a strict progression.
--
R. David Mu
ou are applying a single changeset to multiple branches,
as we often do in our workflow, then I think duplicating the commit
message is (1) easy to do and (2) very helpful when looking at
hg log output.
--
R. David Murray http://www.bitdance.com
__
sary.
>
> > I thought the whole point of merging was that you brought a changeset
> > from one branch to another. This why I just write "merge" because
> > otherwise you're technically duplicating information that is pulled
> > onto the branch by merging.
&g
On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson
wrote:
> 2011/5/9 R. David Murray :
> > On Mon, 09 May 2011 09:08:53 -0500, Benjamin Peterson g> wrote:
> >> I thought the whole point of merging was that you brought a changeset
> >> from one branch to another
On Tue, 10 May 2011 11:51:19 +0900, "Stephen J. Turnbull"
wrote:
> R. David Murray writes:
> > On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson
> wrote:
>
> > > *cough* http://mercurial.selenic.com/wiki/GraphlogExtension
> >
> > I'
ut is better because it
indicates the causation more clearly. (I don't think it is necessary to
capture the subtlety of conditional assignment in the error message.)
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Pyth
x occasional
failures when when the randomly generated temporary path happened to
match the regex.
You will note the *active* verbs "fixed", "improve", and "change"
figure in there prominently :)
(Eh. And proofreading this email I see I made a grammar er
On Tue, 10 May 2011 17:45:44 +0400, Oleg Broytman wrote:
> On Tue, May 10, 2011 at 09:33:13AM -0400, R. David Murray wrote:
> > commit:
> > 11999: sync based on comparing mtimes, not mtime to system clock
> > NEWS:
> > Issue 11999: fixed sporadic sync failure
On Wed, 11 May 2011 00:59:08 +1000, Nick Coghlan wrote:
> On Tue, May 10, 2011 at 11:11 PM, R. David Murray w=
> rote:
> > How about:
> >
> > "reference to variable 'y' precedes an assignment that makes it a local
> > variable"
>
> For
On Tue, 10 May 2011 13:56:58 -0400, Terry Reedy wrote:
> On 5/10/2011 10:59 AM, Nick Coghlan wrote:
> > On Tue, May 10, 2011 at 11:11 PM, R. David Murray
> > wrote:
> >> How about:
> >>
> >> "reference to variable 'y' precedes an as
On Thu, 19 May 2011 01:16:44 +0900, "Stephen J. Turnbull"
wrote:
> Robert Collins writes:
>
> > Its probably too late to change, but please don't try to argue that
> > its correct: the continued confusion of folk running into this is
> > evidence that confusion *is happening*. Treat that as e
een once the
> bots update? If so, I'm impressed, and "thank you!" to all involved.
> Apple and MacPorts have long since washed their hands of that release.
You will note that Tiger is *not* in the stable set :)
--
R. David Murray http://www.bitdance.com
if anything
ought to be tweaked.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/arc
to look at Python/ceval.c.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/arc
_function_name(
var_one, var_two, var_three):
print x
vs
for x in long_function_name(
var_one, var_two, var_three):
print x
That's a case where I'd be likely to use even more than two indentation
levels. Usually, though, I try to refactor the statement
mentally ignore the "== typecode" part and see
> the switch structure more clearly.
I don't do much C coding, so I don't have the right to an opinion on
that (FWIW, I find constant-first jarring). But I'd hate to see the
above in python code. The fact that you li
t;> this may come across as weird though :)
> >
> > Whereas I read it as 'has the value' (or just 'is' ;=).
>
>
> Am I the only one who reads == as "equals"?
No :)
Especially considering that Python actually has an 'is' operator.
I haven't read through your post, but if you don't know about it I
suspect that you will be interested in the following:
http://code.activestate.com/pypm/pysandbox/
I'm pretty sure Victor will be happy to have someone else interested in
this topic.
--
R. David Murray
On Sun, 19 Jun 2011 15:40:01 -0400, Jim Jewett wrote:
> Does this really need to be a bare except?
No, but that's a separate bug report, which you are welcome to
file. The issue I closed was about moving the existing code.
--
R. David Murray http://www.bitd
t is to
run just a selected set of fixers (so that you could use it to generate
python3 code), but it seems to me that renaming modules is something
that 3to2 (and 2to3, of course) should be good at.
--
R. David Murray http://www.bitdance.com
___
to following the existing coding
conventions of stdlib modules...
(I initially called it InvalidMultipartCTEDefect, but all of the other
names were spelled out, so)
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
quest issues (ie: bugs) in
the tracker are tagged 2.7. I expect to see that percentage continue
to decrease over time.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/list
roposed code would allow me, when writing a generator in
my code, do something that would allow me to yield up all the
values from an arbitrary generator I'm calling, over which I have
no control (ie: I can't modify its code)?
--
R. David Murray http://www.bitdance.com
is that I am more comfortable calling them
all attributes than calling them all members. The term 'members'
isn't used anywhere in the language itself, as far as I can recall,
whereas getattr and setattr are evidence that the language considers
them all attributes. I think we do the
On Mon, 27 Jun 2011 15:27:12 +0100, Michael Foord
wrote:
> On 27/06/2011 15:08, R. David Murray wrote:
> > 'data attributes' can so easily become something else in Python...it
> > seems to me that the only real difference between 'data attributes' and
> &
type type). I don't think anyone would argue with you
about that in general. (In specific there might in fact be some
places in the docs where such a change would improve clarity!)
So, the correct generic term for something that can be accessed
via attribute notation is attribute. T
On Mon, 27 Jun 2011 20:30:12 +0100, Michael Foord
wrote:
> On 27/06/2011 20:22, R. David Murray wrote:
> > [snip...]
> > So, the correct generic term for something that can be accessed
> > via attribute notation is attribute. The more specific term for an
> > at
esn't cover "class attributes that aren't
> descriptors").
Also, instances can have methods as instance attributes.
Trying to use 'instance attributes' for non-method attributes is a bad
idea, I think.
Given that there is no one thing that covers al
cified, someone suggested that the overall sleep time could also be
> truncated to a minimum of zero, i.e. treating negative values as zero.
Please file a bug report at bugs.python.org.
--
R. David Murray http://www.bitdance.com
___
Pytho
we're not too
likely to know how to work with it on Windows if you don't install it
from the MSI.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinf
roject kicks off, but I wanted to release/post now
so that there might be a chance of some review happening while I still
have time to respond quickly to the feedback.
--
R. David Murray http://www.bitdance.com
[*] I believe that if you try to use an email6 Message object with the 3.2
things as flat as practical. Namespace
packages clearly have utility, but please let's not descend into
java-esq package hierarchies.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://
> Or perhaps worms dig their way carefully around known bugs?
Hexlify, wormaround...our Barry is just full of interesting words :)
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.p
-like system, I need to know the path to said script.
We're trying to make python as easy to use on Windows as it is on Unix.
If find-script-on-path is considered a worthwhile feature, then as Mark
said it should be added to base Python (on all platforms), not special-cased
in the Windows laun
u did in what I wrote, though.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
documentation for test.support to
the devguide, and then vet the test suite so that unlink and friends
are always called as 'support.unlink', etc.
--
R. David Murray http://www.bitdance.com
___
Python-Dev mailing list
Python-Dev@py
On Wed, 27 Jul 2011 16:58:53 +0300, Eli Bendersky wrote:
> R. David Murray wrote:
> > But they aren't redundant, since the test.support versions ignore
> > errors.
>
> As I mentioned elsewhere, it's not good practice to have two functions with
> the same name
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
On Fri, 29 Jul 2011 15:38:31 +0200, Antoine Pitrou wrote:
> On Fri, 29 Jul 2011 15:28:44 +0200 > Ãric Araujo wrote:
> > 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,
901 - 1000 of 1206 matches
Mail list logo
