On Wed, 5 Oct 2011 18:24:30 +0200 Lluís Batlle i Rossell <virik...@gmail.com> wrote:
[...] > > And when you find an issue with a commit that is some way back in > > your personal branch it is more logical and easier to review your > > branch if you append the fix to the commit where it belongs > > logically or if you append it at the top of the history > > interspersed with some possibly unrelated changes? > > Exactly, these are usual arguments among git lovers. > > Nevertheless, git manuals say "every commit represents a state of the > tree". Then you may find logical to expect that every commit log > talks about a state of the tree. BUT all this goes away, when you > start using 'rebase'. The commit logs once written do not match > anymore the 'state of the tree' at the time of commit log writing. > Assertions in commit logs like "this part works" may easily not fit > what was meant at the commit time, for example. > > git even comes with 'quick automatic rebase' facilities, that allow > not rechecking any commit log (a task hard to do, in any case). > > Making a review 'easier' by manipulating history can also end up > being some kind of manipulation to a reviewer. A reviewer may judge > better by understanding the development. That sort of "we don't need it, we don't need it" mantra is a typical case of the famous "Blub paradox". I mean, if we have two DVCS tools one of which makes you able to rewrite history and another one which doesn't, the first one is more powerful _in this particular respect_. It's as simple as that. By supporting a feature, the tool does not force you to employ that feature in your workflow. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
