On Dec 12, 2010, at 8:15 PM, Richard Hipp wrote: > > > On Sun, Dec 12, 2010 at 8:04 PM, James Turner <[email protected]> wrote: > I would think if I merge a branch that deletes the file and I have local > changes the file would still exist on disk but would be treated like a > untracked file. Meaning, if I was to run fossil extras after the merge the > file would show up. Does this make sense? > > It "makes sense" in the sense that I understand what you are saying. But I > don't understand the "why". Please explain why you want the file to become > untracked? To me, it seems like this would open you up to errors, since > having untracked files laying around might cause your local tests to work, > but then fail when somebody else checked out the same version that lacks > those same files. > > FWIW, Fossil used to behave as you describe (it left untracked files laying > around), but I changed it yesterday to actually delete the file from disk. I > thought that change was a bug fix. Am I wrong? (Note: you can still recover > the file using "fossil undo") See > http://www.fossil-scm.org/fossil/info/70744b76e6 >
For some reason I thought git handled merges this way, I guess I was seeing the behavior in previous fossil versions. It looks like git treats it as a merge conflict (not that this means fossil has to do the same) like Joerg has suggested. > > On Dec 12, 2010, at 7:30 PM, Richard Hipp wrote: > >> >> >> On Sun, Dec 12, 2010 at 7:24 PM, Joerg Sonnenberger >> <[email protected]> wrote: >> On Sun, Dec 12, 2010 at 06:57:56PM -0500, Richard Hipp wrote: >> > Suppose you have the "trunk" branch checked out and you have made changes >> > to >> > file xyz.txt locally, but have not checked them in. Then you do a merge of >> > branch "other-branch": >> > >> > fossil merge other-branch >> > >> > The file xyz.txt has been deleted in other-branch. What should fossil's >> > response be? Should it retain the locally edited copy of xyz.txt, or >> > should >> > it delete file xyz.txt? >> >> Consider it a merge conflict. >> >> You mean refuse to do the merge? >> >> Certainly a conflict warning will be issued, but it seems like a flat-out >> refusal to do the merge is the wrong approach. In addition to the conflict >> warning, Fossil needs to do something with the file. >> >> As I ponder this question further, I'm leaning toward making a DELETE action >> override any EDIT or RENAME action. So if a file has been deleted in the >> local version, then a merge from a version where the file still exists keeps >> the file deleted. And if a file still exists in the local version, then a >> merge from a version where that file is deleted cause the file to become >> deleted locally. Any objections to this approach? >> >> >> >> Joerg >> _______________________________________________ >> fossil-users mailing list >> [email protected] >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> >> >> >> -- >> D. Richard Hipp >> [email protected] >> _______________________________________________ >> fossil-users mailing list >> [email protected] >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > > > > -- > D. Richard Hipp > [email protected] > _______________________________________________ > fossil-users mailing list > [email protected] > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
