Re: RFC: grafts generalised

["Stephen R. van den Berg" <srb@cuci.nl>]

Dmitry Potapov wrote:
>I don't think that the grafts file is the right place for this kind of
>information.

Yet the grafts file is exactly the place where this type of
"overlay-information" is being placed now.  It seems to be the natural place.

> Perhaps, it would be better to have a separate file or
>even a directory with files where commit-id identifies a text file with
>a new commit object, which should be placed instead of an old one.  So,
>it will be easy to tell git filter-branch to use this new information.

Not quite sure why this makes it easier.  The point is that there
is not supposed to be a grafts file in a proper repository.  Thus,
having a lot of these files means a larger disruption to the core, and
I'd like the core to be as efficient and lean as possible given an empty
grafts file.  So I'd prefer to keep it to one file.

>However, if you want more than just ability to edit commits in a text
>file but also inspect changes using normal git commands and gitk (as it
>is possible with grafts), it will require changes to the git core, which,
>perhaps, not difficult to implement using pretend_sha1_file(), but I am
>not sure that everyone will welcome that...

I'd want to avoid a plethora of files, and the changes that can be
specified are supposed to be partial overrides, not complete rewrites.
So using pretend_sha1_file() is a bit overkill and more than I was
aiming for.

The point is, that the changes in grafts (as they are now) are *not*
used when cloning.  I.e. the only thing you mess up is your *own*
repository, not someone else's.  I.e. you can't make someone remote
think that the repository has been altered.  That would require git
filter-branch, which immediately changes all the historical SHA1s, and
makes the changes in history blatantly visible.
-- 
Sincerely,
           Stephen R. van den Berg.

You are confused; but this is your normal state.