Hi Richard, On 22 April 2016 07:07PM, Richard Hipp wrote: > On 4/22/16, Steve Schow <st...@bstage.com> wrote: > > 2 - I notice fossil doesn’t endorse or seem to directly support the > > squashing of commits. > > Right. The Fossil philosophy is different from Git. In Fossil, we > work hard to preserve *all* history. You can correct thing (change > the date or user or comment of a check-in or more a check-in to a > different branch) but as in accounting, the original information is > preserved as an audit trail. > > One pithy way of saying this is that Git tries to show what you should > have done while Fossil tries to show what you actually did. > > The equivalent to squashing commits is to do the work on a branch, > then merge the branch when it is done. The merge take the place of > the squash, but preserves the history. > > If you want see a sequence of changes as a single diff, bring up a > timeline that shows all the changes, click on the "node" of the > origin, then click on the last check-in, then it will show you a diff > between those two nodes.
Doesn't working on a branch marked private and merging it later (upon approval) essentially provide the benefits of "squashing" the commits? The only difference would be the branch commits themselves will not be visible on the upstream repository upon merging. Only the merge commit will be seen. Admittedly, changes made that way will be harder to review, though. Probably better to not use private branches for that situation. ---- Thank you, Arnel _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
