On Thu, Jan 26, 2012 at 2:36 PM, Remigiusz Modrzejewski <l...@maxnet.org.pl>wrote:
> Hi, > > I've stumbled upon a description of something, that I missed once or twice > in Fossil: > > http://nuclearsquid.com/writings/git-add/ > > Nothing that great: an ability to commit only part of changes to a file. > This kind of a thing can as well be scripted out, or implemented with use > of an external merge program (I acutally manually set up to use vimdiff the > few times I needed it). > > Any opinions? > I'm of the old-fashioned opinion that you ought to test your code before you check it in. (See, for example, the pre-checkin checklist<http://www.fossil-scm.org/fossil/doc/trunk/www/checkin.wiki>for Fossil itself. A similar checklist exists for SQLite.) And I don't know how you can compile and/or run a code file with only some of its changes. One does sometimes have multiple changes in a file and you want to break them up into multiple check-ins. That happens to me regularly when working on SQLite. In that case, I save off the a copy of the file that contains all changes (perhaps in the stash<http://www.fossil-scm.org/fossil/help/stash>), revert <http://www.fossil-scm.org/fossil/help/revert> the file to its unchanged state, then start reapplying the changes one by one, testing at each step and committing as necessary. Is that more work than git-add? Yes. But on the other hand, I don't think it is desirable to introduce new commands that make it easier for you to skip the testing step. -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
