Deprecating fetch

Martin Geisler mg at
Fri Sep 2 03:28:50 CDT 2011

Jesse Glick <jesse.glick at> writes:

> On 08/11/2011 11:32 PM, Matt Mackall wrote:
>> These extensions are unloved and largely unmaintained.
> I do not know about maintained, but I use Fetch several times a day
> and as far as I know so do most of my colleagues and it works fine. I
> would certainly be upset to have to manually run update and then
> possibly merge and then commit with a meaningless message every time I
> had something to push and needed to synch remote changes (which is the
> usual case); this would make my normal workflow of
> diff/commit/out/fetch/push significantly slower.

I run 'hg pull' and 'hg rebase' instead -- and that saves me the empty
merge commit.

There's even a combined command: 'hg pull --rebase'. I guess this is
just a matter of taste, but I actually never run 'hg pull --rebase' or
'hg pull --update', I always do the commands one at a time.

> What is so hated? Git users seem to be advised to run git pull
> routinely, and Googling "mercurial fetch" shows various sites mostly
> complaining that it is too hidden.

I think the other core devs also tend to run commands one by one, and so
the fetch extension is not used much by us. This in turn means that it
receives less care tan other parts -- we only know about breakage in it
when its tests fail.

> (In fact I would appreciate a command to not just fetch but then
> immediately push the result so long as there were no 3-way file
> merges. Sure there _might_ be some semantic problem resulting from the
> merge, but this is quite rare in a big repo, and anyway that is what
> continuous integration is for. Compared to CVS/Subversion users, for
> whom commit does an implicit merge, you would still come out ahead
> since in case of subtle problems you could at least go back and check
> whether the original commit prior to the automated merge worked
> correctly.)

Yeah, I see what you mean here -- but I think such an extension should
be a third-party extension until the core developers begin using it.

Martin Geisler

aragost Trifork
Professional Mercurial support

More information about the Mercurial-devel mailing list