On Fri, 11 Jan 2013 17:11:44 +0100 Gilles <gilles.gana...@free.fr> wrote:
> >Fire up Fossil web UI and click on the links marked "patch" and > >"diff" in the commit view. > > This is really what I want to do: Being able to see all the things I > tried on a file in the branch. Most of the time, I want to keep track > of things I tried just in case instead of just forgetting about them > with "fossil revert". `fossil revert` is there for special "whoops!" cases, not for organising some sort of serious workflow around it. > Can this be done with calling a Windows application, either a regular > editor or a differ instead of the Fossil web server? I prefer working > with dedicated applications. There's no "official" GUI front-end for fossil, but there are several attempts at creating such a thing. Google mail archives for it, using something like http://www.google.com/search?q=GUI+site%3Amail-archive.com%2Ffossil-users%40lists.fossil-scm.org to get the relevant discussions/links. Using GUI diffing programs was also discussed several times. > >Technically, just by doing `fossil update <branchname>` as this tries > >to merge your uncommitted local changes with the <branchname> you're > >switching your open checkout to. > > I was under the impression that "update" simply told Fossil than any > subsequent commit should be done on that thread/trunk. Good to know > that "update" will perform a merge, so it has consequences. The logic behind `fossil update` is like follows. Your work tree (working directory, current checkout and whatever else it's being named) is always based on some state stored in the repository (except for the special case when the repository has no commits at all yet). So the main task of `fossil update` is to bring your work tree to the state held by the commit you supplied to this command (directly, or via the name of a branch or a tag). Of course, when fossil does this, it has to be non-destructive: it should not stomp over untracked files (files present in the work tree but not being managed by fossil) and it should preserve your local modifications, if any, which it does by merging. After than, when you modify something and record a commit, that new commit "inherits" certain properties from the base commit of your work tree, and if that commit is "on a branch", then your new commit will be on that same branch, too. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
