Re: Recording merges after repo conversion

[Johan Herland <johan@herland.net>]

[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]

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@herland.net>
www.herland.net

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]