On 7/6/17, Natacha Porté <nata...@instinctive.eu> wrote: > > On the other hand, the situation in which I was is the checkout being > already in the desired state, but fossil having recorded a wrong > commit as current, so I would need a change of current commit while > preserving the whole file system, instead of preserving a diff.
Huh. That does sound like a unusual state. I don't recall ever getting myself into such a state before.... > > A "fossil update" then would try to reapply some changes that are > already in the checkout, unbeknownst to fossil, and I can't imagine it > would go well. Would fossil even realize some hunk are already applied > like patch does? Actually, Fossil does a pretty good job of recognizing when a hunk has already been applied and ignoring it. If you do a "fossil update" and find out otherwise - if you get a lot of conflicts - then you can always back out using "fossil undo". Thinking further - maybe I do get myself into your unusual state on a regular basis. I do it like this: (1) Make edits on Linux but do not commit. (2) Copy the files to Windows and verify that they work there too. (3) Run "fossil commit" on Linux. At this point, the Windows machine has all the same files as the newest check-in, but its "checkout" is from the prior check-in. I fix this by running "fossil up". Fossil tries to merge the changes into files that already has those changes, sees that all the patches have already been applied, makes no changes to the files, and exits without complaint. Is that similar to what you are trying to do? -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
