On Thu, Jun 5, 2014 at 8:47 PM, Alysson Gonçalves de Azevedo <agalys...@gmail.com> wrote: > I'm not Nico, but allow me answer that as well. > > When I was learning to use git, my teacher told me: > "When you have a set of changes where a peace of code requires another > peace, you must commit all that together. But if you have a change that > doesn't have any dependeces, you should commit that change alone."
Where to draw the line is a bit of an art. The programmer (and code reviewers) have to judge what changes are independent in some way and which are too interrelated to be separable. This is true. > And, well, the same "reason" you can use to not allow partial chink-in of a > file can be used to not allow commits on a set of files. So, if we have > commit what we tested, we alwayes must to commit all the changes in all the > files. That's the same point that DRH made, and so it gets the same answer: you must test each commit. And there's a way to with git, and surely that can also be scripted for Fossil (or written right into Fossil). And yes, every time your individual commits fail to pass tests you have to go rebase. So there is another reason to not want an index: if you get it, you'll inexorably also want rebase functionality, including interactive rebase. And if you hate (or misunderstand) rebase, you'll then not want an index. I hadn't considered this. Of course, I like rebase -- no surprise there. And the Fossil community evidently hates rebase. I suspect I can't sell you on rebase, even though I'd like to, and even though I think a dislike of rebase results mostly from misunderstanding what it is and how to use it. (As opposed to a dislike of having to rebase, which is what happens when an upstream asks a contributor to rewrite their history -- more homework -> dislike.) Nico -- _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
