2011/10/5 Lluís Batlle i Rossell <virik...@gmail.com>: > On Tue, Oct 04, 2011 at 02:34:06PM -0700, Mike Meyer wrote: >> On Tue, Oct 4, 2011 at 1:50 PM, Erlis Vidal <er...@erlisvidal.com> wrote: >> >> > You shun a commit or a file in a commit? Is in fossil the shun generating a >> > different commit? >> > >> > you can delete with git files that has history with >> > >> > git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch >> > file_name' HEAD >> > >> > and that will generate a new commit without the file you just deleted (yes >> > I know, that git command is really cryptic that's why I'm liking fossil so >> > much :) >> > >> > but I don't see how this will affect modified files. If the files are >> > commited before, then you will never will lose those changes... unless you >> > have shun those files, but I don't think that's the case, the file that was >> > shun was a big image file, or I'm wrong? >> > >> > I don't understand, but I feel that maybe I have to learn more fossil >> > before continue, because I have the feeling this was more a bug than a >> > misuse of a feature. >> > >> >> You've just hit on a philosophical difference between git and fossil. In the >> fossil community - and hence in fossil itself - development history is >> pretty much sacrosanct. The very name "fossil" was to chosen to reflect the >> unchanging nature of things in that history. >> >> In git (or rather, the git community), the development history is part of >> the published aspect of the project, so it provides tools for rearranging >> that history so you can present what you "should" have done rather than what >> you actually did. > > I use to make an analogy to open-software/closed-software, talking about > open-development/closed-development. > > 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. 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? You can always create a new branch and put the commits in a different order on that branch, merging the original commit with the fixup, start applying your local changes at a later time in the upstream project history. Git provides more tools to make this history rewriting easier so that the presented development steps are easier to understand to a reviewer. You have to find some balance between shunning all history and recording every character typed. 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. In one you get a command shipped as part of core, in other you can find a dozen contributed scripts that do the same or roll your own. It's just a matter of taste or the core tools and available scripts being more fitting for a particular task at hand. Thanks Michal _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
