My understanding of the stash was that it is semi-permanent store where I can put changes I don't want to commit (yet). According to the help, a "fossil stash (save)" should save all uncommitted changes in my workspace, then revert to the base commit. In my previous example, the output of "fossil stash" indicates that the addition of file "test" was "registered", which I interpreted as "this file is now part of the stash(-id)".
But if I apply/pop that stash on another branch, the attibute "ADD" of that particular file is NOT applied. The file remains an "extra", and will not be part of the following commit. In other words: "fossil stash" records "textual changes", but not changes in "state" (managed/unmanaged). I'm fine with that. The file is still in my working directory, no harm done. And I can easily ADD it again after switching branches. What irritates me is that the output of "fossil stash" doesn't make it clear that an added file will not be part of the stash. IMHO, Fossil should either ommit the line "ADD test" or print an explicit warning about what it DID NOT include in the stash. Otherwise, an inattentive newbie (like me) might loose that file (e.g. by running "fossil clean -f", assuming the file in question was part of the applied stash and thus of the following commit). I know that the described workflow is not the cannonical way to do things in Fossil and that I could easily avoid any problems by committing to a (private) branch, then merge. But as Fossil is not the only DVCS I have to work with, I try to find a "common ground" between different systems to reduce the mental overhead. I really like the way the stash is implemented in Fossil (*), and it's my prefered way to stage/queue/transfer changes that are not quite ready to justify a commit. (*) the only feature I miss is a separate/dedicated undo-stack; so that I could stash my changes, update the tree from upstream, diff the stash, then pop the stash. All WITHOUT loosing the ability to undo the update. A "per command"-undo would be even better, because it would make using the undo-stack much more intuitive and would also soften the "one-level-only" limitation. Regards Oliver -------------------------------------------- Ron Wilson <[email protected]> schrieb am Mo, 10.3.2014: Betreff: Re: [fossil-users] stashing of added files An: [email protected], "Fossil SCM user's discussion" <[email protected]> Datum: Montag, 10. März, 2014 23:18 Uhr On Sat, Mar 8, 2014 at 2:36 PM, <[email protected]> wrote: Hi, I'm new to fossil and not quite shure if this is a bug or a lack of understanding on my part. Welcome to Fossil. I wanted to stash a newly added file, then apply the stash to another (feature-)branch. ... Fossil did record the addition of file "test" to the stash, it even said it applied it on both occasions (stash apply, stash goto). So why did the file remain "unmanaged"? After you add files, you have to commit them. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
