On Thu, 26 Jan 2012 20:54:19 +0100 Lluís Batlle i Rossell <vi...@viric.name> wrote:
> On Thu, Jan 26, 2012 at 02:51:04PM -0500, Richard Hipp wrote: > > On Thu, Jan 26, 2012 at 2:36 PM, Remigiusz Modrzejewski > > > http://nuclearsquid.com/writings/git-add/ > > > > > > Any opinions? > > > > > > > I'm of the old-fashioned opinion that you ought to test your code > > before you check it in. > > Very well explained! I totally agree. > > I imagine that in git, users are expected to commit wrong untested > code (thus, that may not match the commit log), and some minutes > later, edit all the history to make up. Also not testing the > rewrites, of course. The git workflow. I commit untested code all the time, just to save the state of it. Of course, I *only* do this in my local repo, not to something anyone else might see. If I'm using a CSCM, I'll create a private branch for that purpose. Anything that gets pushed (or merged to the trunk) will be tested before the push, and if that results in a merge, tested before the merge results are committed. The Git philosophy seems to be that the repository is as important as anything else produced by the product, so editing history is crucial functionality. So they have tools to collapse/reorder/rewrite commits and hide all that. Personally, I think having accurate history is more important (one of the reasons I don't use git any more), and don't mind exposing it to those I share the code with. That said, between stashes and the ability to check a "bug fix" working copy out of the same repo (my usual mode for such), there's more than enough ways to deal with multitasking. <mike _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
