Re: Recording merges after repo conversion

On Wednesday 31 October 2007, Johannes Schindelin wrote:

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