On Wednesday 31 October 2007, Johannes Schindelin wrote: > Hi, > > On Wed, 31 Oct 2007, Peter Karlsson wrote: > > > Johannes Schindelin: > > > > > Why should it? This would contradict the whole "a commit sha1 hashes > > > the commit, and by inference the _whole_ history" principle. > > > > Does it? > > Yes! Of course! If what you want becomes possible, I could make an evil > change in history long gone, and slip it by you. You could not even see > the history which changed. Well, technically, if the grafts file was part of the repo, you wouldn't be able to change the (in-tree) grafts file without affecting the SHA1 of HEAD. In other words, given a commit SHA1 sum, you can be sure that someone else who checks out the same commit (and has no local modification to their grafts file) will see exactly the same history as you do. To a certain degree, this is actually "safer" than today's (out-of-tree) solution, where one can change the grafts file _without_ affecting the current HEAD (SHA1 sum), and thus will not see the same history as someone else who checks out the same HEAD. This is of course _intended_ to a certain degree by the current implementation, but can easily cause confusion if people lose track of what's in their respective grafts files. Of course, this is both a blessing and a curse: Say, for example, we have three commits: ... --> A --> B --> C and commit B changes the (in-tree) grafts file. Now if I have HEAD @ A, I will see a different history than if I have HEAD @ C. Worse: If one person has HEAD @ A, and another person has HEAD @ C, and neither is aware of the grafts file change in B, there is _plenty_ of room for getting confused if the two persons start discussing the repo history. Note, however, that similar confusement can be achieved today if one of the persons forgets having changed his out-of-tree grafts file The grafts file concept is very powerful, but can also be extremely confusing. Adding in-tree versioning of the grafts file will make it more powerful (since we can now easily share and update "errata" to the repo history), but it might also make things _orders_of_magnitude_ more confusing (as demonstrated in the above example, although to be fair, similar confusement can be had in today's out-of-tree solution). At some point things may become so confusing that we'd rather drop the feature instead. ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net
Attachment:
signature.asc
Description: This is a digitally signed message part.
