On Wednesday, June 4, 2014, Alysson Gonçalves de Azevedo < agalys...@gmail.com <javascript:_e(%7B%7D,'cvml','agalys...@gmail.com');>> wrote:
> I started to use fossil just today, but let me participate too :) > > Everyday I have a list of tasks that I have to work on and when I finish, > I like to separate the changes of each task by commit. > > To do that, I just open GUI, check the lines of the files that i want to > commit. > (Just like this print: > http://i1-linux.softpedia-static.com/screenshots/gitg_5.jpg, where I > click on the - and + to stage the line). > > But today, using fossil, I couldn't find anyway to do that, so I had to > put all the changes on the same commit. > > Well, in the theory I can work on one task at time and commit when I > finish, but in the practice I work on all the tasks at same time. > Right. Having to backport fixes to maintenance release branches will make one hunger for tools that make it easier to disentangle a pile of changes. It really helps to have individual bug fixes and feature additions isolated for easy cherry-picking into maintenance release branches (as well as for easy code review (prior to and after integration). The Fossil and SQLite developers have the luxury of mostly not doing backports though. Admittedly, that is my first answer to backports as well: don't! And when i don't have to worry about maintenance release, i do tend to put less effort into having clean commits -- depends on the codebase, and whether there is a code review process, or who the reviewers are. But not everyone has that luxury, or at least not all the time. Still, the community and maintainers appear have spoken. Fossil is at least not appropriate for some projects that I work on, and yet I yearn for something Fossil-like. Nico --
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
