On Wednesday 31 October 2007, Johannes Schindelin wrote:
quoted text
> On Wed, 31 Oct 2007, Johan Herland wrote:
> > On Wednesday 31 October 2007, Johannes Schindelin wrote:
> > > On Wed, 31 Oct 2007, Peter Karlsson wrote:
> > > > Johannes Schindelin:
> > > > > Why should it?  This would contradict the whole "a commit sha1=20
> > > > > hashes the commit, and by inference the _whole_ history"=20
> > > > > principle.
> > > >=20
> > > > Does it?
> > >=20
> > > Yes!  Of course!  If what you want becomes possible, I could make an=
=20
quoted text
> > > evil change in history long gone, and slip it by you.  You could not=
=20
quoted text
> > > even see the history which changed.
> >=20
> > Well, technically, if the grafts file was part of the repo, you wouldn'=
t=20
quoted text
> > be able to change the (in-tree) grafts file without affecting the SHA1=
=20
quoted text
> > of HEAD. In other words, given a commit SHA1 sum, you can be sure that=
=20
quoted text
> > someone else who checks out the same commit (and has no local=20
> > modification to their grafts file) will see exactly the same history as=
=20
quoted text
> > you do.
>=20
> All this does not change the fact that installing a graft and 'git gc=20
> --prune'ing gets rid of the old history.  D'oh.

So will rebasing and --prune'ing, or pulling a rebased branch and --prune'i=
ng.=20
Git already gives you _plenty_ of different ropes to hang yourself with. Th=
e=20
question is whether adding yet another one is worth it.

quoted text
> Automatically installing grafts is wrong.

I tend to agree with you here, because the possibility for massive confusio=
n=20
is huge, but that doesn't deny the fact that, if used properly (and that's =
a=20
_big_ 'if'), this is a very powerful feature.


=2E..Johan

=2D-=20
Johan Herland, <johan@herland.net>
www.herland.net