by the way, I don’t really use git much other then bare minimum to save something on github, so please don’t explain anything in terms of git concepts, I won’t understand you.
I used RCS and SCCS a lot in the past. In RCS, you have to explicitly checkout a file to edit it, locking it out from anyone else changing it until you check it back in. I understand that fossil doesn’t checkout files exclusively that way. In fossil we use “add” which includes the file to a set of files that will be commited in the next commit. We can edit away, the file is not really “checked out” per say, like it is in RCS and SCCS. Its just flagged for the next commit. We make changes and run commit and then at that point its just a file in the filesystem…fossil may be able to tell us it has changed…but its not part of the next commit list until we add it again. right? > On Aug 15, 2017, at 12:48 PM, Stephan Beal <sgb...@googlemail.com> wrote: > > On Tue, Aug 15, 2017 at 8:43 PM, Steve Schow <st...@bstage.com > <mailto:st...@bstage.com>> wrote: > So one quick question…is a hash created only during commit? doesn’t happen > yet during “add” right? > > The hash is calculated during the commit and includes (among many other > things) the timestamp of the commit in its calculation. Thus a commit of the > exact same information at two points in time (milliseconds-precision, if i'm > not mistaken) are guaranteed to have two different hashes. > > I always forget, when you’re talking about “checkin” are you referring to > stuff that has been added or stuff that has been committed? > > git distinguishes between those in a different way than fossil does. In > fossil "add" is kind of like RCS, CVS, and SVN understand "add", and very > much NOT how git understands "add". > > I hear what you’re saying that, if I commit a file to get the hash, then > update the source to have the new hash, the file then appears as having been > “changed”. Its not clear to me it would continue to be part of the next > checkin though unless it is added again? > > That's git terminology - fossil doesn't work that way. > > Its just that the file in place would be showing as having changed compared > to the repository, due to the version being updated in there. > > Correct. "fossil changes" would list that file as changed. > > -- > ----- stephan beal > http://wanderinghorse.net/home/stephan/ > <http://wanderinghorse.net/home/stephan/> > "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of > those who insist on a perfect world, freedom will have to do." -- Bigby Wolf > _______________________________________________ > 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
