[fossil-users] Conflicts during update
Hi All, I've done fossil update and got a suspicious message about merge conflicts (see below). The list of changes is long (21k), so I can't easily see all changes file by file and the last thousand is just ADDED or REMOVED. Is there a way I can check what merge conflicts fossil means in this case? A dumb search for word 'CONFLICT' in the source code does not show anything. Cheers, Jacek - updated-to: 69d46bf6291d65675c1de18a6509c19d527aa6fd 2015-08-12 06:32:31 UTC tags: trunk comment: ceg-deployer: work on the API that can support the wizard (user: Jacek) changes: 21089 files modified. WARNING: 102 merge conflicts "fossil undo" is available to undo changes to the working checkout. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
On Wed, Aug 12, 2015 at 9:07 AM, Jacek Cała wrote: > Hi All, > > I've done fossil update and got a suspicious message about merge conflicts > (see below). The list of changes is long (21k), so I can't easily see all > changes file by file and the last thousand is just ADDED or REMOVED. > > Is there a way I can check what merge conflicts fossil means in this case? > A dumb search for word 'CONFLICT' in the source code does not show anything. > Search for '<' and '>' As someone recently pointed out, if you have changed the line endings (from Windows to Unix or vice versa) between 2 versions, the whole file will be seen as changed, and could lead to confusing conflicts. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
Thanks for the suggestion... no luck in finding '<'. It matches only _FOSSIL_ and a few binary files. It could be the line endings because I work primarily on Windows and whenever fossil complains about CR/LF I just ignore it (saying 'a' during the commit). However, I guess, there is no way to list files that were reported as conflicting during merge, is there? Cheers, Jacek 2015-08-12 8:21 GMT+01:00 Stephan Beal : > On Wed, Aug 12, 2015 at 9:07 AM, Jacek Cała wrote: > >> Hi All, >> >> I've done fossil update and got a suspicious message about merge >> conflicts (see below). The list of changes is long (21k), so I can't easily >> see all changes file by file and the last thousand is just ADDED or REMOVED. >> >> Is there a way I can check what merge conflicts fossil means in this >> case? A dumb search for word 'CONFLICT' in the source code does not show >> anything. >> > > Search for '<' and '>' > > As someone recently pointed out, if you have changed the line endings > (from Windows to Unix or vice versa) between 2 versions, the whole file > will be seen as changed, and could lead to confusing conflicts. > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of > those who insist on a perfect world, freedom will have to do." -- Bigby Wolf > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
On Wed, Aug 12, 2015 at 10:13 AM, Jacek Cała wrote: > Thanks for the suggestion... no luck in finding '<'. It matches only > _FOSSIL_ and a few binary files. It could be the line endings because I > work primarily on Windows and whenever fossil complains about CR/LF I just > ignore it (saying 'a' during the commit). > > However, I guess, there is no way to list files that were reported as > conflicting during merge, is there? > Not that i am aware of. i know svn requires one to manually tell it "the conflict for this specific file is resolved," but fossil does not do so, and it does not remember that a file is conflicted. When a conflict occurs, the conflicting part(s) of the file will be wrapped up in blocks which look like this (copy/pasted from a recent mail by Richard): <<< BEGIN MERGE CONFLICT: local copy shown first <<< === COMMON ANCESTOR content follows === MERGED IN content follows == >>> END MERGE CONFLICT > If you don't see any of those in your source-controlled files then fossil does not know about a conflict. If it reports a conflict and yet does not tag it with such a block, then something is wrong (in fossil), but we are not currently aware of any such bugs. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
Ok, puzzle solved. As suggested in the fossil message I did 'fossil undo' and then 'fossil update > fossil.log'. That revealed the problematic conflicts: CONFLICT path/to/the/problematic/files/... - edited locally but deleted by update As a result fossil did not delete all 102 conflicted files but left them in my local working copy. That's not the best resolution, I think, because right now if I run 'fossil change' I cannot see any changes yet still these files are not in the remote repo. I can think of git which works nice in such cases. It would prevent me doing 'pull' (equivalent of 'fossil update') and would complain that the pull would destroy the local changes. That would force me to see the changes first, then make a decision about what I wanted to do with my local changes and only then do the pull. What do you think? Would that be possible for fossil, too? Cheers, Jacek 2015-08-12 9:19 GMT+01:00 Stephan Beal : > On Wed, Aug 12, 2015 at 10:13 AM, Jacek Cała wrote: > >> Thanks for the suggestion... no luck in finding '<'. It matches only >> _FOSSIL_ and a few binary files. It could be the line endings because I >> work primarily on Windows and whenever fossil complains about CR/LF I just >> ignore it (saying 'a' during the commit). >> >> However, I guess, there is no way to list files that were reported as >> conflicting during merge, is there? >> > > Not that i am aware of. i know svn requires one to manually tell it "the > conflict for this specific file is resolved," but fossil does not do so, > and it does not remember that a file is conflicted. When a conflict occurs, > the conflicting part(s) of the file will be wrapped up in blocks which look > like this (copy/pasted from a recent mail by Richard): > > <<< BEGIN MERGE CONFLICT: local copy shown first <<< > === COMMON ANCESTOR content follows > === MERGED IN content follows == > >>> END MERGE CONFLICT > > > If you don't see any of those in your source-controlled files then fossil > does not know about a conflict. If it reports a conflict and yet does not > tag it with such a block, then something is wrong (in fossil), but we are > not currently aware of any such bugs. > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of > those who insist on a perfect world, freedom will have to do." -- Bigby Wolf > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
On Wed, Aug 12, 2015 at 1:44 PM, Jacek Cała wrote: > ... > CONFLICT path/to/the/problematic/files/... - edited locally but deleted by > update > > As a result fossil did not delete all 102 conflicted files but left them > in my local working copy. That's not the best resolution, I think, because > right now if I run 'fossil change' I cannot see any changes yet still these > files are not in the remote repo. I can think of git which works nice in > such cases. It would prevent me doing 'pull' (equivalent of 'fossil > update') and would complain that the pull would destroy the local changes. > That would force me to see the changes first, then make a decision about > what I wanted to do with my local changes and only then do the pull. What > do you think? Would that be possible for fossil, too? > i'm only vaguely familiar with fossil's update- and conflict-detection/reporting bits, so i cannot say anything useful. To me it sounds like "6 one way and half-a-dozen the other." As a rule, fossil doesn't like to explicitly prevent the user doing anything, as doing so is normally part of a project-specific mentality/policy, and fossil tries not to impose any such things on projects. By not allowing you to perform an update, fossil might effectively lock you out of your repo until you resolve the conflict _before_ updating, and that doesn't sound like the right approach to me. Perhaps others more well-versed in those parts of the code can provide some insights on whether or not it would be feasible. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
So I've seen a very similar thing happen twice on a windows machine, where fossil reports conflicts in a lot of files (in one case it was binary code for LabVIEW, so no possible line endings) but individual inspection of differences with a proper binary differ listed nothing. Only a close/reopen cleared whatever was going on from fossil. I've never been able to track it down as a repeatable bug, but I do actually believe there might be some odd edge case. Tomek > Date: Wed, 12 Aug 2015 10:19:33 +0200 > From: Stephan Beal > To: "Fossil SCM user's discussion" > Subject: Re: [fossil-users] Conflicts during update > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > On Wed, Aug 12, 2015 at 10:13 AM, Jacek Ca?a wrote: > > > Thanks for the suggestion... no luck in finding '<<<<<'. It matches only > > _FOSSIL_ and a few binary files. It could be the line endings because I > > work primarily on Windows and whenever fossil complains about CR/LF I just > > ignore it (saying 'a' during the commit). > > > > However, I guess, there is no way to list files that were reported as > > conflicting during merge, is there? > > > > Not that i am aware of. i know svn requires one to manually tell it "the > conflict for this specific file is resolved," but fossil does not do so, > and it does not remember that a file is conflicted. When a conflict occurs, > the conflicting part(s) of the file will be wrapped up in blocks which look > like this (copy/pasted from a recent mail by Richard): > > <<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<< > === COMMON ANCESTOR content follows > === MERGED IN content follows == > >>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > If you don't see any of those in your source-controlled files then fossil > does not know about a conflict. If it reports a conflict and yet does not > tag it with such a block, then something is wrong (in fossil), but we are > not currently aware of any such bugs. > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of > those who insist on a perfect world, freedom will have to do." -- Bigby Wolf > -- next part -- > An HTML attachment was scrubbed... > URL: > <http://lists.fossil-scm.org:8080/pipermail/fossil-users/attachments/20150812/4bef1cf8/attachment.html> > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
Hi Tomek, As mentioned in my previous e-mail, in my case it was an issue with files changed in my working copy which were deleted in the remote repo. Fossil reported them as 'edited locally but deleted by update' and left them in my working copy. I find it inconvenient because the only way I can think of to resolve it is to do 'fossil undo', see the changes, address them and then 'fossil update' makes sense. Cheers, Jacek 2015-08-12 14:09 GMT+01:00 Tomek Kott : > So I've seen a very similar thing happen twice on a windows machine, where > fossil reports conflicts in a lot of files (in one case it was binary code > for LabVIEW, so no possible line endings) but individual inspection of > differences with a proper binary differ listed nothing. Only a close/reopen > cleared whatever was going on from fossil. I've never been able to track it > down as a repeatable bug, but I do actually believe there might be some odd > edge case. > > Tomek > > > Date: Wed, 12 Aug 2015 10:19:33 +0200 > > From: Stephan Beal > > To: "Fossil SCM user's discussion" > > Subject: Re: [fossil-users] Conflicts during update > > Message-ID: > > > > Content-Type: text/plain; charset="utf-8" > > > > On Wed, Aug 12, 2015 at 10:13 AM, Jacek Ca?a > wrote: > > > > > Thanks for the suggestion... no luck in finding '<<<<<'. It matches > only > > > _FOSSIL_ and a few binary files. It could be the line endings because I > > > work primarily on Windows and whenever fossil complains about CR/LF I > just > > > ignore it (saying 'a' during the commit). > > > > > > However, I guess, there is no way to list files that were reported as > > > conflicting during merge, is there? > > > > > > > Not that i am aware of. i know svn requires one to manually tell it "the > > conflict for this specific file is resolved," but fossil does not do so, > > and it does not remember that a file is conflicted. When a conflict > occurs, > > the conflicting part(s) of the file will be wrapped up in blocks which > look > > like this (copy/pasted from a recent mail by Richard): > > > > <<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<< > > === COMMON ANCESTOR content follows > > === MERGED IN content follows == > > >>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > > > > If you don't see any of those in your source-controlled files then fossil > > does not know about a conflict. If it reports a conflict and yet does not > > tag it with such a block, then something is wrong (in fossil), but we are > > not currently aware of any such bugs. > > > > -- > > - stephan beal > > http://wanderinghorse.net/home/stephan/ > > http://gplus.to/sgbeal > > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of > > those who insist on a perfect world, freedom will have to do." -- Bigby > Wolf > > -- next part -- > > An HTML attachment was scrubbed... > > URL: < > http://lists.fossil-scm.org:8080/pipermail/fossil-users/attachments/20150812/4bef1cf8/attachment.html > > > > > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
On Aug 12, 2015 1:19 AM, "Stephan Beal" wrote: > > On Wed, Aug 12, 2015 at 10:13 AM, Jacek Cała wrote: >> >> Thanks for the suggestion... no luck in finding '<'. It matches only _FOSSIL_ and a few binary files. It could be the line endings because I work primarily on Windows and whenever fossil complains about CR/LF I just ignore it (saying 'a' during the commit). >> >> However, I guess, there is no way to list files that were reported as conflicting during merge, is there? > > > Not that i am aware of. If there really are conflicts, [fossil changes] should report them. Also, fiddling with your diff command might be illustrative, example: [fossil set diff-command "diff -bu"] for producing unified diff that ignores whitespace, and "diff -u" for acknowledging whitespace... > i know svn requires one to manually tell it "the conflict for this specific file is resolved," but fossil does not do so, and it does not remember that a file is conflicted. When a conflict occurs, the conflicting part(s) of the file will be wrapped up in blocks which look like this (copy/pasted from a recent mail by Richard): > > <<< BEGIN MERGE CONFLICT: local copy shown first <<< > === COMMON ANCESTOR content follows > === MERGED IN content follows == > >>> END MERGE CONFLICT > > > If you don't see any of those in your source-controlled files then fossil does not know about a conflict. If it reports a conflict and yet does not tag it with such a block, then something is wrong (in fossil), but we are not currently aware of any such bugs. > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
On Aug 12, 2015, at 5:44 AM, Jacek Cała wrote: > > CONFLICT path/to/the/problematic/files/... - edited locally but deleted by > update > > As a result fossil did not delete all 102 conflicted files but left them in > my local working copy. That's not the best resolution, I think Historically, Fossil never deletes working copy files on “fossil mv/rm”. This holds true when you merge one branch into another: when you update to the target branch, the deleted files reappear, then on “fossil merge” the old working copy files are left behind, even though they are no longer on the current branch in the repo. However, Fossil recently got an optional feature that — as I understand it — will become the default in Fossil 2.0. Meanwhile, in 1.x, you have to enable it in your Fossil binary first, with: $ ./configure --with-legacy-mv-rm $ make && sudo make install The option is named strangely, so I hope it changes, but it’s still named that way in trunk, as of [d17dc8f220] anyway. The option’s name doesn’t tell you what it actually does in Fossil 1.x, which is to enable a new setting, mv-rm-files, which when set causes “fossil mv/rm” to behave like Unix mv/rm: the working copy files are [re]moved at the same time the repo changes are scheduled, so you no longer need to do 2-step mv/rm. The interesting bit here is that with this option set, merging a branch with removed files also removes working copy files, as you expected it to. Fossil will be more consistent in its behavior when mv-rm-files becomes the default behavior. > It would prevent me doing 'pull' (equivalent of 'fossil update') and would > complain that the pull would destroy the local changes. I did some testing, and Fossil will indeed destroy local changes in such situations. It actually doesn’t require branches to do so. Test case: mkdir test cd test fossil init ../test.f f open ../test.f echo ‘Initial contents’ > foo f add foo f ci -m 'added foo' echo 'Changed foo' > foo f set mv-rm-files 1 f rm foo cat foo Result: foo disappears, along with your local changes! This is a bug. The solution is to fully implement the decision table in the Mercurial documentation for its rm command: https://www.selenic.com/mercurial/hg.1.html#remove Note that Mercurial demands -f to make it accept an rm command if there are local changes. Otherwise, Mercurial goes to state ‘W’, whereas Fossil currently goes to state ‘RD’. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
On Aug 12, 2015, at 2:13 AM, Jacek Cała wrote: > > I work primarily on Windows and whenever fossil complains about CR/LF I just > ignore it (saying 'a' during the commit). Don’t do that. Fossil is trying to tell you about a real problem. It means you have either got: a. A file with mixed line ending styles (e.g. LF most places but CR+LF in a few places); or b. A text file using a line ending style inconsistent with your current Fossil settings. Instead of ignoring the warning, you should either: 1. Decide that the project’s line ending style is CR+LF to cater to Windows defaults, then set the crnl-glob setting so that Fossil knows which files are text files, and thus don’t need this warning; or 2. Choose LF instead, and use text editors on Windows that don’t rewrite LF files as CR+LF, and which visually warn you about mixed line endings. If you don’t make a decision and stick to it, you get two bad effects. First, you can’t tell case ‘a’ above from case ‘b’. Second, you’re checking in a bunch of pointless diffs, potentially one per line, which makes automatic merging impossible. Option 2 is preferable, if you can get away with it. Unless you’re still using Notepad, you probably *can* get away with it these days. If you must choose option 1 for some reason, I recommend that you use Fossil’s versioned crlf-glob setting. (i.e. vi .fossil-settings/crnl-glob) One alternative is to set it via the Admin/Settings UI, but that only affects new clones; it doesn’t change the settings on sync in existing clones. The other alternative is to do it via the “fossil setting” command, but that’s unmaintainable and doesn’t let you easily use line breaks, which makes the *glob settings much more readable. > I guess, there is no way to list files that were reported as conflicting > during merge, is there? Except for the deleted files case brought up in my other post, Fossil tells you this at least two different ways: $ f update MERGE foo/bar.txt * 1 merge conflicts in foo/bar.txt updated-to: 99c79be1294d… etc. WARNING: 1 merge conflicts and, after an incomplete update: $ f stat repository: /path/to/repo.fossil … CONFLICT foo/bar.txt This doesn’t currently (!) happen with the mv-rm-files enabled, if you said “fossil rm”. Instead of CONFLICT, you get DELETED. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
Thanks Warren for valuable comments. I had to resolve the problem and cannot easily revert to the suspicious state I had reported previously. I wonder whether 'fossil stat' would give me the answer I was looking for. Will remember it for the future. Cheers, Jacek 2015-08-12 21:12 GMT+01:00 Warren Young : > On Aug 12, 2015, at 2:13 AM, Jacek Cała wrote: > > > > I work primarily on Windows and whenever fossil complains about CR/LF I > just ignore it (saying 'a' during the commit). > > Don’t do that. > > Fossil is trying to tell you about a real problem. It means you have > either got: > > a. A file with mixed line ending styles (e.g. LF most places but CR+LF in > a few places); or > > b. A text file using a line ending style inconsistent with your current > Fossil settings. > > Instead of ignoring the warning, you should either: > > 1. Decide that the project’s line ending style is CR+LF to cater to > Windows defaults, then set the crnl-glob setting so that Fossil knows which > files are text files, and thus don’t need this warning; or > > 2. Choose LF instead, and use text editors on Windows that don’t rewrite > LF files as CR+LF, and which visually warn you about mixed line endings. > > If you don’t make a decision and stick to it, you get two bad effects. > First, you can’t tell case ‘a’ above from case ‘b’. Second, you’re > checking in a bunch of pointless diffs, potentially one per line, which > makes automatic merging impossible. > > Option 2 is preferable, if you can get away with it. Unless you’re still > using Notepad, you probably *can* get away with it these days. > > If you must choose option 1 for some reason, I recommend that you use > Fossil’s versioned crlf-glob setting. (i.e. vi .fossil-settings/crnl-glob) > > One alternative is to set it via the Admin/Settings UI, but that only > affects new clones; it doesn’t change the settings on sync in existing > clones. > > The other alternative is to do it via the “fossil setting” command, but > that’s unmaintainable and doesn’t let you easily use line breaks, which > makes the *glob settings much more readable. > > > I guess, there is no way to list files that were reported as conflicting > during merge, is there? > > Except for the deleted files case brought up in my other post, Fossil > tells you this at least two different ways: > > – $ f update > MERGE foo/bar.txt > * 1 merge conflicts in foo/bar.txt > > updated-to: 99c79be1294d… etc. > WARNING: 1 merge conflicts > > and, after an incomplete update: > > $ f stat > repository: /path/to/repo.fossil > … > CONFLICT foo/bar.txt > > This doesn’t currently (!) happen with the mv-rm-files enabled, if you > said “fossil rm”. Instead of CONFLICT, you get DELETED. > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
> On Aug 12, 2015, at 2:52 PM, Jacek Cała wrote: > > I had to resolve the problem and cannot easily revert to the suspicious state > I had reported previously. The past isn’t as important as fixing the Fossil text file inconsistency for the future. If you’re going to use CR+LF line endings, you really need to set crnl-glob appropriately for your repository. I said in the previous email that going with LF is better, but didn’t explain why. There are several reasons to do it, even if you’re primarily on Windows: 1. Fossil itself comes out of the Unix world, so when in doubt, it assumes LF. You see this in the behavior of the “convert” option in the warning you’ve been ignoring by selecting “a” every time. 2. Programmer’s tools on Windows and Unix typically understand the other platform’s line endings, so choice of platform is less a concern as it once was when trying to decide on a style. Since Fossil’s CR/LF tests are structured toward detecting LF-only accidentally turning into CR+LF, and not the other way around, choosing CR+LF as the project style means you can’t detect certain classes of errors. Test case: $ od -c x.txt 000g o o d l i n e \r \n b a d l 020i n e \n That file checks into the repo without warning with crnl-glob enabled for ‘*.txt’, despite the missing \r on the second line. This is because with crnl-glob enabled for a file, it isn’t checking whether the file has internally-consistent line endings, it is *ignoring* changes that only involve CR characters. If you check it in and then fix the file, Fossil still doesn’t complain, since you’ve told it that the new CR character is expected. But here’s a surprise: If you now convert that fixed file to LF-only, Fossil *still* doesn’t warn you because you’ve told it that CR changes are not worth warning about, and all you’ve done is removed two CR characters. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
Thus said Warren Young on Wed, 12 Aug 2015 13:50:10 -0600: > Fossil will be more consistent in its behavior when mv-rm-files > becomes the default behavior. Personally, I like the current behavior of leaving the files behind, though I can see that some would like a different behavior. I'm not sure how changing this will make it any more consistent. Thanks, Andy -- TAI64 timestamp: 400055cbdda0 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Conflicts during update
On Aug 12, 2015, at 5:57 PM, Andy Bradford wrote: > > Thus said Warren Young on Wed, 12 Aug 2015 13:50:10 -0600: > >> Fossil will be more consistent in its behavior when mv-rm-files >> becomes the default behavior. > > I'm not sure > how changing this will make it any more consistent. The OP laid out one case: f checkin --branch feature f rm --hard foo/bar.txt f ci -m ‘removed unwanted bar.txt file’ f up trunk f merge feature With the “classic” behavior, bar.txt comes back when you “up trunk,” which is expected, but remains left behind after the merge, which is not expected. With mv-rm-files enabled, merging the feature branch removes bar.txt from the local checkout. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
