Bazaar

pulling with unresolved conflicts creates confusing state if there are new conflicts

Bug #686151 reported by Glenn Morris
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Medium
Unassigned

Bug Description

Using bzr 2.2.2, I did `bzr pull' and had a conflict with one file. I did not resolve the conflict. Later on, the same file was modified upstream. When I pulled again, I ended up in a confusing state. Example:

mkdir test1
cd test1
touch 1
bzr init
bzr add
bzr commit -m "commit1"

cd ../

bzr branch test1 test2
cd test1; edit 1 and commit

cd test2; edit 1 but do not commit
bzr pull reports "Text conflict in 1"
bzr status reports:
modified:
  1
unknown:
  1.BASE
  1.OTHER
  1.THIS
conflicts:
  Text conflict in 1

At his point, all is fine.

cd test1; edit 1 and commit
cd test2; bzr pull

Now confusing things happen. bzr pull reports:

  Text conflict in 1
  Conflict adding file 1.BASE. Moved existing file to 1.BASE.moved.
  Conflict adding file 1.OTHER. Moved existing file to 1.OTHER.moved.
  Conflict adding file 1.THIS. Moved existing file to 1.THIS.moved.
  4 conflicts encountered.

bzr status reports:
modified:
  1
unknown:
  1.BASE
  1.BASE.moved
  1.OTHER
  1.OTHER.moved
  1.THIS
  1.THIS.moved
conflicts:
  Text conflict in 1
  Conflict adding file 1.BASE. Moved existing file to 1.BASE.moved.
  Conflict adding file 1.OTHER. Moved existing file to 1.OTHER.moved.
  Conflict adding file 1.THIS. Moved existing file to 1.THIS.moved.

At this point, I have two sources of confusion:

1) The statement "conflict adding file" make me thing I, or bzr, have done a `bzr add' on one of those .BASE etc files.

2) It's not clear to me how to resolve this situation. If I do `bzr revert 1', I am still left with 3 conflicts:
  Conflict adding file 1.BASE. Moved existing file to 1.BASE.moved.
  Conflict adding file 1.OTHER. Moved existing file to 1.OTHER.moved.
  Conflict adding file 1.THIS. Moved existing file to 1.THIS.moved.

Trying to revert any of those files fails with "ERROR: Path(s) are not versioned".

The only solution I've found is `bzr revert .' to revert the whole directory. There are times when that might not be appropriate though, eg if I have changes to other files in that directory.

Revision history for this message
Vincent Ladeuil (vila) wrote :

IMHO bzr should refuse to pull if the working tree contains conflicts unless told otherwise à la --no-strict in push.

Changed in bzr:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Vincent Ladeuil (vila) wrote :

Or may be even the option is a bad idea, a working tree with conflicts is generally already broken and requires user intervention, doing a pull on top of that will never magically resolve the conflicts already present.
In the best case there will be no new conflicts but this bug is about getting new ones which 1) don't make sense, 2) are a real pain to resolve for unsuspecting users .

Revision history for this message
Glenn Morris (rgm+lp) wrote :

> bzr should refuse to pull if the working tree contains conflicts unless told otherwise

Perhaps; does any other VCS behave like that?

Personally, I think the final state in test2 shouldn't happen to depend on whether or not I happen to do a pull
after the first commit to file 1 in branch test1.

Revision history for this message
Vincent Ladeuil (vila) wrote :

> Personally, I think the final state in test2 shouldn't happen to depend on whether or not I happen to do a pull after the first commit to file 1 in branch test1.

I don't think so.

After the first pull, the uncommitted changes are related to the result of this pull so they depend on it (the canonical example is that if these changes were committed upstream, they should just disappear).

If you want pull to succeed, you can shelve (or revert) your changes before doing the pull.

After all, when a file is modified outside an editor, you usually get a warning about getting the newer version when you attempt to modify the copy known to the editor. The workflows are quite similar here, hence my proposal to warn the user before shooting him in the foot.

Revision history for this message
Martin Pool (mbp) wrote : Re: [Bug 686151] Re: pulling with unresolved conflicts creates confusing state if there are new conflicts

On 10 December 2010 06:00, Vincent Ladeuil <email address hidden> wrote:
> IMHO bzr should refuse to pull if the working tree contains conflicts
> unless told otherwise à la --no-strict in push.

I agree it should probably decline by default, but to me the analogy
is more to trying to merge into an already dirty directory. There are
quite valid reasons to do it, but you will be mixing things together
and if you've made a mistake it may be a bit hard to back it out.

--
Martin

Jelmer Vernooij (jelmer)
tags: added: conflicts
Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.