Hello, on Thursday 06 July 2017 at 14:01, Richard Hipp wrote: > 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....
Indeed it is. To put it into perspective, I have a bit more than 700 "fossil update" in my main dev machine over the last 6 years, while I encountered this unusal state less than 10 times, and only once did I really could work around it. > > 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? Yes, this is very similar to what I usually do (except I do it on the same machine) and that's the bulk of my 700 "fossil update"s. Now imagine you leave things as they are after (3) to do some non-dev stuff (or some dev on other repositories), and you receive a serious windows-specific bug report. You drop everything to work on it, forgetting the "fossil up". You eventually make a fix in some code path that is never reached on Linux, or for another reason you decide to commit straight away. Last time I was in this situation, "fossil up" would mark almost every as a merge conflict. Maybe it got better since then? Anyway, you could resolve the conflicts if there are not many of them, or you could copy the final file somewhere, do "fossil up", and copy them back if there are few files involved. That's how I dealt with the <10 times mentioned above. And then I had precious data, which happened to be spread over two dozen files with on average half a dozen hunks in each, and no obvious way of recognizing old or mangled data (that's the problem with data, instead of code or understandable text). So I really missed a way of asking fossil to just commit the files as they were but with another parent than what was currently recorded as the current commit. Natacha _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
