-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 16:58, Barry Warsaw wrote:
> I guess this is just a Mercurial quirk I'll have to get used to. It's not
> something I ever bother with in Bazaar because, while those intermediate
> commits are still part of the merged branch's history, it's
On Feb 04, 2011, at 04:35 PM, M.-A. Lemburg wrote:
>Tarek Ziadé wrote:
>> You are building a patch and submit it to reviews (in roundup or in a
>> clone or retvield etc). You get feedback and you refine the patch.
>>
>> I don't think you want to keep that history, e.g. "changing this and
>> that
On Fri, Feb 4, 2011 at 11:57 PM, Tarek Ziadé wrote:
> I'd rather have a best practice guide *now* and refine it later. e.g.
> "how to contribute to python via mercurial."
>
> I think we have people here with a decent expertise of Mercurial that
> can come up w/ this, even if it's changed after.
Y
Tarek Ziadé wrote:
> You are building a patch and submit it to reviews (in roundup or in a
> clone or retvield etc). You get feedback and you refine the patch.
>
> I don't think you want to keep that history, e.g. "changing this and
> that in my patch after feedback from MrX about Y"
>
> The main
On Feb 4, 2011, at 9:44 AM, Dirkjan Ochtman wrote:
> I think extra clones per issue could work for some larger issues that
> require lots of work, but I don't think the
> every-small-feature-on-a-branch model (as practiced in Twisted, IIRC)
> is particularly helpful. On the other hand, I do think
On Fri, Feb 4, 2011 at 14:31, Tarek Ziadé wrote:
> That's why I think it's much cleaner to work with mq to build a clean
> single-commit patch, even if a clone may be used for temporary states
> and sharing.
>
> We are experiencing merge hell right now in Distutils2, as the
> contributor list gro
Le vendredi 04 février 2011 à 14:48 +0100, Jesus Cea a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/02/11 14:31, Tarek Ziadé wrote:
> >> As a general rule, rebase should be done ONLY in personal clones not
> >> shared by anybody. Or, in this particular case, a clone should b
On Fri, Feb 4, 2011 at 2:48 PM, Jesus Cea wrote:
..
> I am not sure what way is better. Keeping ALL the history would be
> interesting anyway, but most of my tiny commits would break the build (I
> commit everytime I stop for thinking, pee, whatever. It is like autosave
> in my text editor), so th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 14:31, Tarek Ziadé wrote:
>> As a general rule, rebase should be done ONLY in personal clones not
>> shared by anybody. Or, in this particular case, a clone should be
>> automatically destroyed after merging to main development line.
>
> T
On Fri, Feb 4, 2011 at 1:50 PM, Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/02/11 13:15, Victor Stinner wrote:
>>> Rebasing is good before committing to the "real" repository, but anybody
>>> with a checkout clone will suffer.
>>
>> Why?
>
> Rebasing alters history
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 13:15, Victor Stinner wrote:
>> Rebasing is good before committing to the "real" repository, but anybody
>> with a checkout clone will suffer.
>
> Why?
Rebasing alters history. It messes with the "inmmutable" nature of
history. Anybody wi
Le vendredi 04 février 2011 à 13:08 +0100, Jesus Cea a écrit :
> I support this, but implementation would be non trivial.
Yes, it is non trivial, but it would be helpful :-)
> The problem is how to cope with security issues
As I wrote: if security matters, only core developers should be able to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/02/11 12:52, Victor Stinner wrote:
> It would be nice to create a branch for each issue (or each attached to
> an issue?)
Change "branch" to "temporal clone".
I support this, but implementation would be non trivial.
I have missed forever about
Hi,
When a patch is attached to an issue, it is usually a patch for the last
stable release or to trunk (2.7 or 3.2 trunk). The problem is that
latter the patch doesn't apply to trunk anymore and the author have to
update its patch. Sometimes, we ask to update a patch six months or one
year after
14 matches
Mail list logo
