On Thu, Jun 30, 2005 at 07:21:11PM +0200, Goffredo Baroncelli wrote:
> On Thursday 30 June 2005 03:02, Matt Mackall wrote:
> > On Thu, Jun 30, 2005 at 08:52:26AM +0800, Soh Tk-r28629 wrote:
> >
> > > I think 'hg pull' should check and fail if the current repo contain
> > > uncommitted changes. Though we can also make 'hg update' do the
> > > work, 'pull' might be in the better possition. Comment?
> >
> > hg pull has no effect on the working directory (there may not even be
> > one) so it doesn't make sense there.
> >
> > hg pull -u and hg update already check whether there are uncommitted
> > changes and prompt you to do -m.
>
> hg bheaves so _ONLY_ if the merge is performed between differents branchs....
>
> The patch below adds a check that prevents the merging if -m or -f are
> not passed to hg update.
I'm sorry if I was unclear. The current behavior is _intentional_,
even if I haven't explained it well. It mimics 'cvs update':
If I have version X checked out and modified (let's call this version
X'), and I then try to check out Y, if Y is a linear descendent of X,
then we merge the changes from Y into the working directory and claim
that the working directory is now based on Y (let's call this Y').
This means you don't need to check in X' and then do a real merge
between X' and Y later.
Thus you can be working on a small patch for a week, resync from
upstream, and now your changes are against the tip rather than the
version from a week ago.
The -m flag is needed when Y is not a descendent of X, but on another
branch. This means that update is attempting to merge branches.
--
Mathematics is the supreme nostalgia of our time.
|
