On Wed, Oct 05, 2011 at 06:06:07PM +0200, Michal Suchanek wrote: > 2011/10/5 Lluís Batlle i Rossell <virik...@gmail.com>: > > git looks to me as a tool for publishing development steps, not necessarily > > very > > related to the development history. The 'git version graph' is determined > > by the > > users the same way as they choose filenames or directories, and many git > > groups > > even consider keeping the git graph close to development history as a > > 'basic and > > inexpert approach' to git. > > It is because it is not useful to have every *actual file edit* > recorded as commit. You often edit multiple files to perform a change, > or do some work on the project, save it, go for lunch, and then do > some more work on it. > > From a totally purist point of view should the history be recorded > every time you save a file? Every time you write or delete a > character? No, it is saved in logical pieces - commits.
I consider commits as relevant milestones in the development, and I use branches to keep differentg granularity of commits. > 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. > I don't mind fossil keeping these dead branches. In fact, git does so > too until you manually prune the repository of unreferenced objects. > You can also select to show only live branches in fossil so the > difference is mostly cosmetical, as are all the differences between > distributed VCSes. git even cannot store branch histories, beyond the big resulting graph of unnamed commits. For example, a branch name can only designate a commit (leaf), not more than one. And branch names are not part of history. Some git deployments even forbid or limit pushing new branches to a public repository. On the other hand, fossil will always respect the checkin order, and the states related to every checkin log. As many other VCS, but not with git. Regards, Lluís _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
