On Tue, Mar 11, 2014 at 10:28 AM, <[email protected]> wrote: > 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.
I think I've seen this too. It might be a bug in "fossil stash". > 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 > -- D. Richard Hipp [email protected]
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
