Using stash and doing update then commits to appropriate branches along mostly addresses the need to split out changes from a single editing session. The one thing it cannot do is easily accommodate a mix of changes in a single file. That said I think I disagree that this is really needed. In git it appears to me that if you didn't have the foresight to "add" each of a series of changes as you worked then you have the same effort in teasing out one change from another as you would in fossil.
I think the rough equivalent to "git add" is "fossil stash snapshot". I could see a gui or script that could take all the hunks from a changed file and store them in individual stashes being useful. In short implementing the SourceTree mechanism should be possible in fossil using stash save and or snapshot ... well, maybe ... Illustration: foo.txt has changes A, B, C and D. After each change the developer had the foresight to do a "fossil stash snapshot". Now the developer decides to put changes B and D into branch b-d and keep changes A and C on the trunk: fossil stash save -m "saving changes A, B, C and D as a single stash for safeties sake" fossil update trunk fossil stash apply A; fossil commit -m "committing A to trunk" fossil stash apply B; fossil update b-d; fossil commit -m "Moved change B to branch b-d and committed it" # A is applied to trunk and B to b-d but now it gets ugly fossil update original-refid fossil stash apply C fossil merge --backout refid-for-change-b fossil merge --backout refid-for-change-a fossil commit -m "Applied A+B+C-B-A fossil update c-d fossil commit -m "committing C to c-d" and so forth .... The inability to do an incremental stash makes this difficult for anything other than simple use cases. Suggestion: consider adding a mechanism to either apply a delta from two stashes to the working set or a way to do an incremental stash. Then the methodology of using stash to replace the git index should work. Editorial: I might occasionally use such a feature but I have very seldom felt any need to do this complex messing around *after* coding. Usually I just realize that a change belongs on a different branch and do update to that branch, commit, update back to where I was. I.e. use a little discipline in place of flexibly complexity. For the once in a blue moon where I goof and put a change in the wrong place I use do a couple of cherrypicks to move the change to the appropriate branch. On Thu, Jun 5, 2014 at 9:40 AM, Nico Williams <n...@cryptonector.com> wrote: > On Thu, Jun 5, 2014 at 10:36 AM, B Harder <brad.har...@gmail.com> wrote: > > drh> Fossil allows you to commit a subset of files (by listing the > > files on the "fossil commit" command line) but there is no mechanism > > for committing a subset of lines within a single file. > > > > That, and there _are_ branches/tags which are encouraged to be used... > > my prev comment was for the case where a single file gets two-thoughts > > worth of changes (subset of lines). For subsets of lines (assume we > > want two logical commits), I head to my editor, tease out logical > > Key words there: "tease out". You have to stare at diffs and do/undo > part of the change by manual application of diffs. > > Compare to SourceTree's interface to the index: > > > https://www.google.com/search?q=sourcetree+stage+hunk+screenshots&tbm=isch&tbo=u&source=univ&sa=X&bih=663 > > Or git add -e or -p, or hg record. > > SourceTree's GUI interface lets you: > > - stage/discard/neither by hunk > - stage/discard/neither specific lines in hunks > - edit hunk lines to be staged > > That's also what git add -e lets you do. > > It's just much easier to disentangle large diffs this way than with > manual teasing out via $EDITOR. > > > section1 -> tmp file. fossil stash save -m "logical thought temp1" > > ./file-of-interest; > > re-enter tmp.file -> file-of-interest; fossil ci -m "description of > > logical thought" ./file-of-interest; fossil stash pop [edit if > > necessary]; fossil ci -m "description of other logical thought" > > ./file-of-interest > > I know how to do this. I did this for many, many years before the > advent of git, and my learning git add -p/-e. Even a grumpy systems > guy whose every command-line is a script... can learn to love not > having to do error-prone operations like this in such a manual way. I > could never teach my non-programmer spouse to do what you do to work > around Fossil's lack of anything like hg record or the git index, but > with SourceTree's interface to git she does this every day without > breaking a sweat. > > Nico > -- > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority...
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
