On Tue, Oct 4, 2011 at 4: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? > I shunned both the commit artifact and the file that was changed, the openoffice *.odp file. > > 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? > Both the commit and the file were shunned. > > 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. > The problem was operator error, not a bug in fossil. > > Why the shun confused the update? That's the question I'll try to answer... > > > Thanks everyone... > Erlis > > > On Tue, Oct 4, 2011 at 4:33 PM, Bill Burdick <bill.burd...@gmail.com>wrote: > >> You could handle that case -- if you shun the current commit, then check >> the disk against the current repo contents and mark files that are different >> as uncommitted. >> >> >> Bill >> >> >> On Tue, Oct 4, 2011 at 3:15 PM, Richard Hipp <d...@sqlite.org> wrote: >> >>> >>> >>> On Tue, Oct 4, 2011 at 4:09 PM, Erlis Vidal <er...@erlisvidal.com>wrote: >>> >>>> And that's what I don't understand, how could the Update "overwrote" >>>> your changes. >>>> >>>> This is from the update help command >>>> >>>> *Change the version of the current checkout to VERSION. Any >>>> uncommitted >>>> changes are retained and applied to the new checkout. >>>> * >>> >>> >>> Because of the shun, Fossil was confused. It thought that the changes >>> had been committed, since they had been committed immediately prior to the >>> shun. So the files on disk were marked as clean. Hence, Fossil overwrote >>> them. >>> >>> >>> >>>> ** >>>> If you do the same steps, without the shun, just modify some files, >>>> update previous. Would that remove my change in the current checkout? >>>> >>>> Thanks, >>>> Erlis >>>> >>>> >>>> On Tue, Oct 4, 2011 at 3:59 PM, Richard Hipp <d...@sqlite.org> wrote: >>>> >>>>> >>>>> >>>>> On Tue, Oct 4, 2011 at 3:55 PM, Erlis Vidal <er...@erlisvidal.com>wrote: >>>>> >>>>>> Hi Richard, >>>>>> >>>>>> I would like to understand how you lost your changes, but probably >>>>>> because I'm ignorant of the internals I'm not able to understand what >>>>>> just >>>>>> happened here. >>>>>> >>>>>> I've read the Shun documentation and the Update documentation, and I >>>>>> cannot see how what you said here could occur. >>>>>> >>>>>> On Tue, Oct 4, 2011 at 2:06 PM, Richard Hipp <d...@sqlite.org> wrote: >>>>>> >>>>>>> >>>>>>> "No problem", I thought. I'll just shun it. Which I did. Then I >>>>>>> did "fossil update previous" so that I could commit the new version. >>>>>>> But >>>>>>> (oops) that deleted all of my changes. Everything was lost. Despair >>>>>>> and >>>>>>> gnashing of teeth followed. >>>>>>> >>>>>>> >>>>>> It looks like the udpate command was the one that actually create the >>>>>> problem, but following your entire story, it seems that the situation was >>>>>> created by the Shun you did. >>>>>> >>>>> >>>>> Right. I "shunned" my most recent check-in, removing the content from >>>>> the repository. Then I did an "update" to the previous check-in so that I >>>>> could check in the changes again, but this time with the new smaller JPEG >>>>> instead of the massive GIF. But the "update" overwrote *all* of the >>>>> changes >>>>> I had made over the course of the morning. >>>>> >>>>> So the "shun" removed the content from the repository. And the >>>>> "update" removed the content from the disk. >>>>> >>>>> Fortunately, there was still one other copy in the undo stack.... >>>>> >>>>> >>>>> >>>>>> >>>>>> Please (if is not much to ask) can you explain what creates the issue? >>>>>> >>>>>> >>>>>> Sincerely, >>>>>> Erlis >>>>>> >>>>>> _______________________________________________ >>>>>> fossil-users mailing list >>>>>> fossil-users@lists.fossil-scm.org >>>>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> D. Richard Hipp >>>>> d...@sqlite.org >>>>> >>>>> _______________________________________________ >>>>> fossil-users mailing list >>>>> fossil-users@lists.fossil-scm.org >>>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> fossil-users mailing list >>>> fossil-users@lists.fossil-scm.org >>>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >>>> >>>> >>> >>> >>> -- >>> D. Richard Hipp >>> d...@sqlite.org >>> >>> _______________________________________________ >>> fossil-users mailing list >>> fossil-users@lists.fossil-scm.org >>> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >>> >>> >> >> _______________________________________________ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users >> >> > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- D. Richard Hipp d...@sqlite.org
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
