Hello, on Thursday 06 July 2017 at 10:59, Richard Hipp wrote: > On 7/6/17, Natacha Porté <nata...@instinctive.eu> wrote: > > I was recently in a very uncomfortable situation, with precious > > uncommitted data in the current checkout and the need to change where > > the checkout "current commit" points to. > > That's what the "fossil update" command is for.
I'm afraid I didn't explain the situation clearly enough, or I have a major misunderstanding of fossil commands. I was under the impression that "fossil update" changes the "current commit" not only in fossil book-keeping, but also in the file-system as well, somewhat like "rebasing" the current set of changes to the designated "current commit". In shell terms, I understand "fossil update" to work like $ diff -r virtual-reference/ ./ >/tmp/temporary-patch $ fossil revert $ fossil checkout $targetcommit $ patch </tmp/temporary-patch 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. In shell terms, I'm looking for something equivalent to: $ mkdir ../tmp-checkout $ cd ../tmp-checkout $ fossil open /path/to/fosisl $ fossil checkout $targetcommit $ cp -r ../working-checkout/* ./ $ cd .. $ rm -rf working-checkout $ mv tmp-checkout working-checkout I agree that it shouldn't happen, and indeed doesn't happen often, while "fossil update" is routinely used when everything is well. I happens to me most often (in situations where data is not precious) in a situation like the one described by Warren Young, with several checkout directories, and somehow a directory with an older checkout gets newer files. For example, I got this once when I tested a few independent features which overlap in the affected code, before committing any of them. I threw them together in the same checkout directory and do whatever testing I felt needed. Later, when all the features but one are committed, and the other checkout directories are used for other works, I wanted to take this testing checkout, fast-forward to the branch head without changing the files on disk, and I can directly commit. It's a bit contrived, but less so then the other times I needed the feature. 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? Anyway, that would be a lot of a conflicts to solve, while I know that the files on disk are actually merged. On the other hand, the help says "The --keep option leaves files on disk unchanged, except the manifest and manifest.uuid files." which seems to do exactly the bookkeeping update I need. Am I missing something? Natasha _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
