* bzr commit raises a weird conflict @ 2013-04-09 7:50 Bastien 2013-04-09 8:42 ` Christopher Schmidt 2013-04-09 10:28 ` Giorgos Keramidas 0 siblings, 2 replies; 10+ messages in thread From: Bastien @ 2013-04-09 7:50 UTC (permalink / raw) To: emacs-devel I wanted to push a tiny docstring bugfix (bug#14163) but could not. "~$ bzr commit" complains about a conflict. "~$ bzr conflicts" yields: Conflict: can't delete leim/ja-dic because it is not empty. Not deleting. I first ran "~$ make maintainer-clean" before trying to commit, because I did build Emacs from this directory. How can I resolve this "conflict"? I know it safer to build from a dedicated branch, and to use a clean branch for commits, but still, I don't understand what's wrong. Thanks for any help, -- Bastien ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: bzr commit raises a weird conflict 2013-04-09 7:50 bzr commit raises a weird conflict Bastien @ 2013-04-09 8:42 ` Christopher Schmidt 2013-04-09 9:37 ` Bastien 2013-04-09 15:13 ` Eli Zaretskii 2013-04-09 10:28 ` Giorgos Keramidas 1 sibling, 2 replies; 10+ messages in thread From: Christopher Schmidt @ 2013-04-09 8:42 UTC (permalink / raw) To: emacs-devel Bastien <bzg@gnu.org> writes: > How can I resolve this "conflict"? > > I know it safer to build from a dedicated branch, and to use a clean > branch for commits, but still, I don't understand what's wrong. I don't understand what's wrong, either. bzr resolve --take-other solved it for me. This is probably another bug in bzr. Christopher ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: bzr commit raises a weird conflict 2013-04-09 8:42 ` Christopher Schmidt @ 2013-04-09 9:37 ` Bastien 2013-04-09 15:13 ` Eli Zaretskii 1 sibling, 0 replies; 10+ messages in thread From: Bastien @ 2013-04-09 9:37 UTC (permalink / raw) To: Christopher Schmidt; +Cc: emacs-devel Hi Christopher, Christopher Schmidt <christopher@ch.ristopher.com> writes: > bzr resolve --take-other > > solved it for me. It did for me as well, thanks for the trick. I've pushed the fix. -- Bastien ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: bzr commit raises a weird conflict 2013-04-09 8:42 ` Christopher Schmidt 2013-04-09 9:37 ` Bastien @ 2013-04-09 15:13 ` Eli Zaretskii 2013-04-10 7:38 ` Christopher Schmidt 1 sibling, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2013-04-09 15:13 UTC (permalink / raw) To: Christopher Schmidt; +Cc: emacs-devel > From: Christopher Schmidt <christopher@ch.ristopher.com> > Date: Tue, 9 Apr 2013 09:42:39 +0100 (BST) > > Bastien <bzg@gnu.org> writes: > > How can I resolve this "conflict"? > > > > I know it safer to build from a dedicated branch, and to use a clean > > branch for commits, but still, I don't understand what's wrong. > > I don't understand what's wrong, either. The directory is removed in the master repository, but not in the local branch. That's a conflict that prevents a clean merge. > bzr resolve --take-other > > solved it for me. This is probably another bug in bzr. It's not a bug, and the above is precisely the way to resolve such conflicts (of course, you could also use --take-mine, but in this case that would be wrong). Bastien, next time you have such non-text conflicts, type bzr help conflict-types and read there (it's a long entry, so redirect to a pager or to an Emacs buffer). In particular, this specific conflict is described under "Deleting parent". ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: bzr commit raises a weird conflict 2013-04-09 15:13 ` Eli Zaretskii @ 2013-04-10 7:38 ` Christopher Schmidt 2013-04-10 15:31 ` Eli Zaretskii 0 siblings, 1 reply; 10+ messages in thread From: Christopher Schmidt @ 2013-04-10 7:38 UTC (permalink / raw) To: emacs-devel Eli Zaretskii <eliz@gnu.org> writes: >> From: Christopher Schmidt <christopher@ch.ristopher.com> >> bzr resolve --take-other >> solved it for me. This is probably another bug in bzr. Hi Eli, thank you very much for your explanation. I should have investigated before calling in another bug. I will be more careful next time. My apologies for the noise. Greetings, Christopher ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: bzr commit raises a weird conflict 2013-04-10 7:38 ` Christopher Schmidt @ 2013-04-10 15:31 ` Eli Zaretskii 2013-04-12 8:49 ` Bastien 0 siblings, 1 reply; 10+ messages in thread From: Eli Zaretskii @ 2013-04-10 15:31 UTC (permalink / raw) To: Christopher Schmidt; +Cc: emacs-devel > From: Christopher Schmidt <christopher@ch.ristopher.com> > Date: Wed, 10 Apr 2013 08:38:19 +0100 (BST) > > thank you very much for your explanation. I should have investigated > before calling in another bug. I will be more careful next time. > > My apologies for the noise. It was not noise: you helped Bastien to solve his problem. No need to apologize for that. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: bzr commit raises a weird conflict 2013-04-10 15:31 ` Eli Zaretskii @ 2013-04-12 8:49 ` Bastien 0 siblings, 0 replies; 10+ messages in thread From: Bastien @ 2013-04-12 8:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Christopher Schmidt, emacs-devel Eli Zaretskii <eliz@gnu.org> writes: > It was not noise: you helped Bastien to solve his problem. No need to > apologize for that. Indeed, no apologies needed -- thanks all for the info. -- Bastien ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: bzr commit raises a weird conflict 2013-04-09 7:50 bzr commit raises a weird conflict Bastien 2013-04-09 8:42 ` Christopher Schmidt @ 2013-04-09 10:28 ` Giorgos Keramidas 2013-04-09 11:23 ` Bastien 2013-04-09 15:31 ` Eli Zaretskii 1 sibling, 2 replies; 10+ messages in thread From: Giorgos Keramidas @ 2013-04-09 10:28 UTC (permalink / raw) To: Bastien, emacs-devel; +Cc: Christopher Schmidt On 2013-04-09 09:50, Bastien <bzg@gnu.org> wrote: > I wanted to push a tiny docstring bugfix (bug#14163) but could not. > > "~$ bzr commit" complains about a conflict. > > "~$ bzr conflicts" yields: > Conflict: can't delete leim/ja-dic because it is not empty. Not deleting. > > I first ran "~$ make maintainer-clean" before trying to commit, > because I did build Emacs from this directory. > > How can I resolve this "conflict"? On 2013-04-09 09:42, Christopher Schmidt <christopher@ch.ristopher.com> wrote: > Bastien <bzg@gnu.org> writes: > > How can I resolve this "conflict"? > > > > I know it safer to build from a dedicated branch, and to use a clean > > branch for commits, but still, I don't understand what's wrong. > > I don't understand what's wrong, either. > > bzr resolve --take-other > > solved it for me. This is probably another bug in bzr. That's because leim/ja-dic/ was removed recently, but if you are merging in an unclean checkout (with build output from previous builds), bzr notices that: (a) The directory should be removed as part of the merge (b) The directory is not empty So it takes the safer approach of aborting the merge with a conflict, instead of blindly removing the directory. This is an artifact of the fact that bzr likes tracking directory changes too, as part of the branch history. In this case it acts a bit silly, because there are *no* files tracked remaining after the directory is fully removed from a branch, so it should just go ahead and remove the directory from the branch, but leave the filesystem intact. Since there are no files left in the originally tracked directory, future merges or updates will not care about this path anyway. Running 'bzr resolve --take-other' basically tells bzr to ignore whatever happens to exist in the filesystem because of the local branch and consider the 'source branch' the authoritative source of what it should do with leim/ja-dic/. And it solves this minor merge problem ;) -- Giorgos Keramidas; gkeramidas@gmail.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: bzr commit raises a weird conflict 2013-04-09 10:28 ` Giorgos Keramidas @ 2013-04-09 11:23 ` Bastien 2013-04-09 15:31 ` Eli Zaretskii 1 sibling, 0 replies; 10+ messages in thread From: Bastien @ 2013-04-09 11:23 UTC (permalink / raw) To: Giorgos Keramidas; +Cc: Christopher Schmidt, emacs-devel Hi Giorgos, Giorgos Keramidas <keramida@ceid.upatras.gr> writes: > That's because leim/ja-dic/ was removed recently, but if you are merging > in an unclean checkout (with build output from previous builds), bzr > notices that: > > (a) The directory should be removed as part of the merge > (b) The directory is not empty > > So it takes the safer approach of aborting the merge with a conflict, > instead of blindly removing the directory. > > This is an artifact of the fact that bzr likes tracking directory > changes too, as part of the branch history. In this case it acts a bit > silly, because there are *no* files tracked remaining after the > directory is fully removed from a branch, so it should just go ahead and > remove the directory from the branch, but leave the filesystem intact. > Since there are no files left in the originally tracked directory, > future merges or updates will not care about this path anyway. > > Running 'bzr resolve --take-other' basically tells bzr to ignore > whatever happens to exist in the filesystem because of the local branch > and consider the 'source branch' the authoritative source of what it > should do with leim/ja-dic/. And it solves this minor merge problem > ;) Thanks for the detailed explanation -- will remember this next time. -- Bastien ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: bzr commit raises a weird conflict 2013-04-09 10:28 ` Giorgos Keramidas 2013-04-09 11:23 ` Bastien @ 2013-04-09 15:31 ` Eli Zaretskii 1 sibling, 0 replies; 10+ messages in thread From: Eli Zaretskii @ 2013-04-09 15:31 UTC (permalink / raw) To: Giorgos Keramidas; +Cc: bzg, christopher, emacs-devel > Date: Tue, 9 Apr 2013 12:28:04 +0200 > From: Giorgos Keramidas <keramida@ceid.upatras.gr> > Cc: Christopher Schmidt <christopher@ch.ristopher.com> > > > "~$ bzr commit" complains about a conflict. Bastien should have seen this conflict announced when you updated or merged from upstream. He probably didn't notice that, but he can look that up in your ~/.bzr.log entry for the time of update/merge. > > "~$ bzr conflicts" yields: > > Conflict: can't delete leim/ja-dic because it is not empty. Not deleting. > > > > I first ran "~$ make maintainer-clean" before trying to commit, > > because I did build Emacs from this directory. maintainer-clean cannot resolve this, because the problem is not in the file system. The problem is in the history meta-data. Deleting files or directories manually, when such conflicts happen, doesn't help, because bzr cannot detect when these conflicts are resolved; you must tell it explicitly about the resolution, using the "bzr resolve" command. The documentation I mentioned in my other mail in this thread says that bzr needs to be told when the conflict is resolved (unlike with text conflicts, where it can detect resolution automatically). > That's because leim/ja-dic/ was removed recently, but if you are merging > in an unclean checkout (with build output from previous builds), bzr > notices that: > > (a) The directory should be removed as part of the merge > (b) The directory is not empty > > So it takes the safer approach of aborting the merge with a conflict, > instead of blindly removing the directory. > > This is an artifact of the fact that bzr likes tracking directory > changes too, as part of the branch history. In this case it acts a bit > silly, because there are *no* files tracked remaining after the > directory is fully removed from a branch, so it should just go ahead and > remove the directory from the branch, but leave the filesystem intact. It is not silly. "bzr up" merges the upstream with what you have, and also leaves intact any unversioned files you happen to have. Bazaar cannot know what is the unversioned file in the directory that was deleted upstream. It could just be a new file you intend to add to version control, but just didn't yet "bzr add". If bzr removes the directory from the history metadata, that file would become an orphan--you won't be able to add it, because its parent directory is gone. (That directory and its history could be recovered, of course, but doing that is non-trivial, either.) So bzr punts and leaves it to you to resolve the snafu. If this branch is never used to add new files, Bastien can prevent this nuisance by setting the bzr.transform.orphan_policy option, see the description in "bzr help conflict-types". > Since there are no files left in the originally tracked directory, > future merges or updates will not care about this path anyway. "bzr update" preserves unversioned files as well, because that could be work in progress that you don't want to lose. ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-04-12 8:49 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-04-09 7:50 bzr commit raises a weird conflict Bastien 2013-04-09 8:42 ` Christopher Schmidt 2013-04-09 9:37 ` Bastien 2013-04-09 15:13 ` Eli Zaretskii 2013-04-10 7:38 ` Christopher Schmidt 2013-04-10 15:31 ` Eli Zaretskii 2013-04-12 8:49 ` Bastien 2013-04-09 10:28 ` Giorgos Keramidas 2013-04-09 11:23 ` Bastien 2013-04-09 15:31 ` Eli Zaretskii
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.