Enable "hg push --new-branch" by default in hgrc

[Dominik Psenner]

> -----Original Message-----
> From: Mads Kiilerich [mailto:mads at kiilerich.com]
> Sent: Thursday, March 24, 2011 3:25 PM
> To: Dominik Psenner
> Cc: 'Mercurial Developers'
> Subject: Re: Enable "hg push --new-branch" by default in hgrc
> 
> On 03/24/2011 03:02 PM, Dominik Psenner wrote:
> > We're working a lot with named branches to keep track of bug-related
> fixes.
> > We push those changes also to our master repository as we want that
> > information to become historical.
> >
> > The odd thing about this is that we have to type --new-branch almost for
> > every push we do, so it would be natural to enable it by default.
> > Unfortunately this is the only thing I was able to come up with and I'm
> > worried having this in my hgrc could be dangerous:
> >
> > -- quote
> > [alias]
> > push = push --new-branch
> > -- quote
> >
> > What do you guys think about making --new-branch configurable in hgrc
> > without the need of an alias definition?
> 
> The reasons why an alias could be dangerous and a bad idea also applies
> to making it configurable in other ways.

By which means?

> You can use defaults, even
> though it has been deprecated for exactly the same reasons.

[defaults] is not available in tortoisehg and is deprecated

> 
> Is it really a problem that you have to specify --new-branch? It could
> be argued that it is especially good for you because you make so many
> branches and so easily can push a branch that shouldn't have been pushed
> anyway.

I believe we have all brains in our heads. :-) Branches are pushed in case
when:

* one has worked for long time on a bug (named branch) and a hdd headcrash
would be a real pain
* the bug (named branch) is fixed (closed) and merged into default or
abandoned

> 
> A workflow where every push introduces a new branch is not exactly the
> most common best practice with Mercurial. Taken to the extreme you might
> get scalability issues, but if it works for you then it is fine.
> 

*duh*

We share here the same issue tracker and love to have comments etc there,
but at the same time we love to keep track of what changes were necessary to
fix a specific bug too.