[Python-Dev] hg diff

Tres Seaver tseaver at palladion.com
Mon Mar 7 17:44:55 CET 2011


-----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 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 work acceptably for the kinds of changes that
>>   >  >  diff --git was designed to be an improvement for?
>>   >
>>   >  I don't know. What are the kinds of changes that diff --git was designed
>>   >  for?
>>
>> I don't know exactly how much of git diffcore has been implemented in
>> hg diff --git.  However, git's diff handles renames and copies
>> correctly and pleasantly, including swapping file names (ie, renaming
>> a to b and b to a simultaneously), and can change file modes.
>>
>> That kind of change is rather unpleasant to deal with in a traditional
>> diff format.  Eg, renames are represented as deleting all the lines
>> from one file and re-adding them as a new file.
> 
> Ok, so the next question is what constitutes an acceptable 
> representation. I find the original approach to diff completely
> acceptable, also considering that people rarely rename files,
> and if they do, they typically don't put patches into a bug tracker.

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
quantity of patches went up *significantly* when we made it easy for
somebody who doesn't work on the code all the time to use this workflow
(fork to a public repo, clone, hack, commit, push, request a pull).


Tres.
- -- 
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk11C4cACgkQ+gerLs4ltQ78JwCfSwyPfJHu1C7q25o54EIoOS7L
UrQAoIgNlPmes31eHEIQo1hEkoXxCbL2
=/+0X
-----END PGP SIGNATURE-----



More information about the Python-Dev mailing list