Le 09/03/2011 03:41, Guido van Rossum a écrit :
On Tue, Mar 8, 2011 at 9:32 PM, Éric Araujo mer...@netwok.org wrote:
I’m of the opinion that hg diffs should always use the extended git
format, given their usefulness. A tool working with hg diffs that does
not support this format is broken
On 09.03.2011 06:44, Martin v. Löwis wrote:
IMO, it's hg diff --git that's broken, as it doesn't include the base
revision (other formats, such as hg export, do).
I asked about it on #mercurial. It turns out that not including the
base changeset id in the diff is an oversight, not a choice;
The idea is to pull their remote branch but not merge it, which will create
multiple heads locally.
“hg pull some-repo-uri” does that.
Then find the common ancestor of my regular local head and the new head,
and diff the ancestor with the new head.
I think Mercurial revsets can do that, but I
IMO, it's hg diff --git that's broken, as it doesn't include the base
revision (other formats, such as hg export, do).
I agree that it's poor form to omit the revisions, and we should
supplicate Mercury at his temple. But I don't see the problem for
Reitveld integration; they're easily
On Tue, Mar 8, 2011 at 6:30 PM, Éric Araujo mer...@netwok.org wrote:
What’s the command you use with git? Maybe someone will find the
Mercurial one.
Something like the following, assuming we're both working on branch master
to begin with.
git fetch their-repository
With a branch you can easily view the full patch, making a branch
strictly more general.
I just asked this before: how *exactly* do you do that?
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or the
CPU burden).
For Mercurial, that's more difficult than you might expect. There is hg
On 2011-03-08 09:38, Martin v. Löwis wrote:
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or the
CPU burden).
For Mercurial, that's more
On 2011-03-08 10:53, Adrian Buehlmann wrote:
On 2011-03-08 09:38, Martin v. Löwis wrote:
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or
On Tue, 08 Mar 2011 09:38:27 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or the
CPU
Martin v. Löwis writes:
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or the
CPU burden).
For Mercurial, that's more difficult
On Mar 08, 2011, at 12:01 PM, Stephen J. Turnbull wrote:
Barry Warsaw writes:
I hear this complaint [about branches being no help in reviewing] a
lot from hg and git users, so maybe it's just the nature of the
tools. In which case, I'm fine with whatever works better for
Python.
On Tue, Mar 8, 2011 at 12:34 AM, Martin v. Löwis mar...@v.loewis.dewrote:
With a branch you can easily view the full patch, making a branch
strictly more general.
I just asked this before: how *exactly* do you do that?
I confess: I'm not sure exactly how to do it in hg. I know it's easy
Am 08.03.2011 11:30, schrieb Stephen J. Turnbull:
Martin v. Löwis writes:
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I haven't thought about the UI or
Am 08.03.2011 11:19, schrieb Antoine Pitrou:
On Tue, 08 Mar 2011 09:38:27 +0100
Martin v. Löwismar...@v.loewis.de wrote:
However, as Michael points out, you can have your tools generate the
patch. For example, it shouldn't be too hard to add a dynamic patch
generator to Roundup (although I
Hi,
Le 08/03/2011 19:04, Daniel Stutzbach a écrit :
With a branch you can easily view the full patch, making a branch
strictly more general.
I just asked this before: how *exactly* do you do that?
I confess: I'm not sure exactly how to do it in hg. I know it's easy in
git; I assume it's
Hi,
First, thank you for stepping up again to work on the code review
integration.
It seems that the dev guide recommends to use the --git option in hg
diff.
From “hg help diffs”:
While this standard format [unified diff] is often enough, it does
not encode the following information:
On Tue, Mar 8, 2011 at 9:32 PM, Éric Araujo mer...@netwok.org wrote:
I’m of the opinion that hg diffs should always use the extended git
format, given their usefulness. A tool working with hg diffs that does
not support this format is broken IMO.
Can you please contribute changes to Rietveld
I’m of the opinion that hg diffs should always use the extended git
format, given their usefulness. A tool working with hg diffs that does
not support this format is broken IMO.
IMO, it's hg diff --git that's broken, as it doesn't include the base
revision (other formats, such as hg export,
Martin v. Löwis writes:
Doesn't hg diff -r 'ancestor(branch,default)::branch', where branch
is the unmerged branch you would like to inspect, do the right thing?
What would I specify as branch if all I have is
http://bitbucket.com/turnbull/foo;, and know that it must be the
On 09.03.2011 06:44, Martin v. Löwis wrote:
I’m of the opinion that hg diffs should always use the extended git
format, given their usefulness. A tool working with hg diffs that does
not support this format is broken IMO.
IMO, it's hg diff --git that's broken, as it doesn't include the base
Martin v. Loewis writes:
I’m of the opinion that hg diffs should always use the extended git
format, given their usefulness. A tool working with hg diffs that does
not support this format is broken IMO.
IMO, it's hg diff --git that's broken, as it doesn't include the base
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/06/2011 11:32 PM, Martin v. Löwis wrote:
Am 07.03.2011 03:43, schrieb Stephen J. Turnbull:
Martin v. Löwis writes:
Am 07.03.2011 02:24, schrieb Stephen J. Turnbull:
Martin v. Löwis writes:
It seems that the dev guide
On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
If we can get to a mode where non-committers can push to a fork on
hg.python.org, we can dodge the patch format issue by having folks post
pull requests for that fork instaed.
For the repoze and pylons projects, we have found the quality and
On Mon, 7 Mar 2011 12:04:18 -0500
Barry Warsaw ba...@python.org wrote:
On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
If we can get to a mode where non-committers can push to a fork on
hg.python.org, we can dodge the patch format issue by having folks post
pull requests for that fork
On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
On Mon, 7 Mar 2011 12:04:18 -0500
Barry Warsaw ba...@python.org wrote:
On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
If we can get to a mode where non-committers can push to a fork on
hg.python.org, we can dodge the patch format issue by
On Mon, Mar 7, 2011 at 10:04, Barry Warsaw ba...@python.org wrote:
On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
On Mon, 7 Mar 2011 12:04:18 -0500
Barry Warsaw ba...@python.org wrote:
On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
If we can get to a mode where non-committers can
On 07/03/2011 18:32, Thomas Wouters wrote:
On Mon, Mar 7, 2011 at 10:04, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
On Mon, 7 Mar 2011 12:04:18 -0500
Barry Warsaw ba...@python.org mailto:ba...@python.org
On Mon, 7 Mar 2011 13:04:11 -0500
Barry Warsaw ba...@python.org wrote:
On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
On Mon, 7 Mar 2011 12:04:18 -0500
Barry Warsaw ba...@python.org wrote:
On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
If we can get to a mode where
On 07/03/2011 18:35, Michael Foord wrote:
On 07/03/2011 18:32, Thomas Wouters wrote:
On Mon, Mar 7, 2011 at 10:04, Barry Warsaw ba...@python.org
mailto:ba...@python.org wrote:
On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
On Mon, 7 Mar 2011 12:04:18 -0500
Barry Warsaw
On Mar 07, 2011, at 07:44 PM, Antoine Pitrou wrote:
I agree with Thomas' answer here: while a branch makes it easier to
maintain a patch (but you can also use e.g. Mercurial Queues), it
doesn't make it easier to *review*. You are assuming that I, as a
reviewer, want to know about the history of
On Antoine Pitrou solip...@pitrou.net wrote:
How do you review a branch?
Below is an example from github (because that's where my experience with
reviewing DCVS branches comes from), but I think it communicates the idea
well.
The user hsoft forked my blist project, made some changes, and sent
On Mon, Mar 7, 2011 at 17:28, Daniel Stutzbach stutzb...@google.com wrote:
With a branch you can easily view the full patch, making a branch strictly
more general.
The advantage of having a branch comes when you want to review the second
or third iteration of a proposed change. With a
Barry Warsaw writes:
I hear this complaint [about branches being no help in reviewing] a
lot from hg and git users, so maybe it's just the nature of the
tools. In which case, I'm fine with whatever works better for
Python.
First, let me remind you that PEP 374 was quite clear about one
Martin v. Löwis writes:
It seems that the dev guide recommends to use the --git option in hg
diff. I'm working on the Rietveld integration, and found that this
option makes things worse: the regular diff includes the base revision
of the patch; hg diff --git doesn't.
Does the regular diff
Am 07.03.2011 02:24, schrieb Stephen J. Turnbull:
Martin v. Löwis writes:
It seems that the dev guide recommends to use the --git option in hg
diff. I'm working on the Rietveld integration, and found that this
option makes things worse: the regular diff includes the base revision
Martin v. Löwis writes:
Am 07.03.2011 02:24, schrieb Stephen J. Turnbull:
Martin v. Löwis writes:
It seems that the dev guide recommends to use the --git option in hg
diff. I'm working on the Rietveld integration, and found that this
option makes things worse: the regular
Am 07.03.2011 03:43, schrieb Stephen J. Turnbull:
Martin v. Löwis writes:
Am 07.03.2011 02:24, schrieb Stephen J. Turnbull:
Martin v. Löwis writes:
It seems that the dev guide recommends to use the --git option in
hg
diff. I'm working on the Rietveld integration,
It seems that the dev guide recommends to use the --git option in hg
diff. I'm working on the Rietveld integration, and found that this
option makes things worse: the regular diff includes the base revision
of the patch; hg diff --git doesn't.
So I would rather like people not to use the --git
39 matches
Mail list logo
