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

Dominik Psenner dpsenner at gmail.com
Thu Mar 24 10:18:57 CDT 2011

> -----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

* 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

> 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.


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.

More information about the Mercurial-devel mailing list