Deprecating fetch

[Jesse Glick]

On 09/02/2011 04:28 AM, Martin Geisler wrote:
> I run 'hg pull' and 'hg rebase' instead -- and that saves me the empty merge commit.

Fine if that works for your purposes, especially if there is reluctance to have many merge commits in the repository. (I think a proper fix of 
http://mercurial.selenic.com/bts/issue981 would make this less relevant.)

But besides forcing you to remember which changesets might have already been propagated somewhere else, it destroys the original commit IDs - which might have already 
been recorded in a bug tracker or elsewhere - and (like svn commit) loses the occasionally interesting historical information of what parent changeset you actually made 
this commit against.

So pull --rebase is not something you can recommend without complicated qualifications to someone asking the inevitable simple question: "What should I do when push 
complains about a new remote head?" There are a number of potential answers, but "run fetch and try again" is the simplest and is usually unobjectionable.

> the fetch extension is not used much by us. This in turn means that it receives less care than other parts

Understood, but that on its own is not a good reason to deprecate a useful feature, especially one used in many people's basic workflow. After all, most programmers write 
software not used by themselves or other programmers, but still somehow manage to make it keep working. :-)

> I think such an extension [as fetch+push] should be a third-party extension until the core developers begin using it.

Yes of course.