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. As with any other tool, if you don't agree with the philosophy behind fossil, you're going find it really frustrating to use. That's why I don't use git. To many operations that should be simple wound up being "just use rebase to ...", and I'd rather avoid anything that mucks with history. <mike
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
