Yes, that's my vision of it. I've come to several situations in which feature A and feature B share the same file.
I then proceed to remove all the code from feature B, run the tests for the A, pass them, then commit. Then apply back the lines from feature B, retest, pass, and commit. Actually in those cases, sometimes I can swap the order: first go with feature B, as I know feature A it's not compete yet, so I "stash" the A, proceed to B to deliver it quickly, then switch to my lower priority A. Once I worked in a company with continuous integration, and perhaps they were doing it wrong, but you actually committed into a specific test branch in to get the code to be tested. In my personal life, I do a lot of embedded code for microcontrollers, so automated tests are not available. I test my code by hand, it seems to pass, yet contains bugs. Even for Qt I work like that. Another case I could use it a lot is in documents, as Richard said. On Mar 20, 2015 10:05 AM, "bch" <brad.har...@gmail.com> wrote: > Can we define partial commit ? > > Are we talking about when I <code>, <code>, <code> and then realize > that I've got two features' worth of new material and would like to > separate them so that Feature B is held back, Feature A is applied > (and yes, tested, etc., etc) and committed, then Feature B is applied > (tested, etc.) and committed ? > > Or am I misunderstanding ? > > -bch > > > On 3/20/15, Richard Hipp <d...@sqlite.org> wrote: > > On 3/20/15, Stephan Beal <sgb...@googlemail.com> wrote: > >> On Fri, Mar 20, 2015 at 12:56 PM, Abilio Marques <abili...@gmail.com> > >> wrote: > >> > >>> I personally would like a selective stash. Perhaps one where you can > >>> selectively push some changes (then fossil could proceed to remove them > >>> from the actual files), or selectively pop/apply some changes (but I > >>> imagine this one could get things confusing, specially if used with > >>> apply). > >>> ... > >>> What are your opinions? Is this useful? Is this powerful? What would > your > >>> approaches be? > >>> > >> > >> IMO it's inherently evil because it promotes checking in untested > subsets. > >> Automated tests require a full, valid tree. Checking in a part of a > change > >> may well lead to code which runs on your machine but doesn't run on > >> remotes > >> (continuous integration systems or other users). > >> > > > > I agree with Stephan, except to note that some repositories do not > > store code. If you are checking in changes to text documentation, > > then maybe testing is not as important and a partial commit would be > > ok. > > > > I'm still having trouble understanding how the partial commit would be > > *useful*, though. > > -- > > 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 > > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
