Re: Recording merges after repo conversion
- From
Johan Herland <johan@herland.net>
- Date
- Oct 31, 2007, 14:37 UTC
- Message-ID
- <200710311537.30384.johan@herland.net>
- In-Reply-To
- <Pine.LNX.4.64.0710311340500.4362@racer.site>
On Wednesday 31 October 2007, Johannes Schindelin wrote:
Show 23 quoted lines
> 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 > > > > > 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. > > All this does not change the fact that installing a graft and 'git gc > --prune'ing gets rid of the old history. D'oh.
So will rebasing and --prune'ing, or pulling a rebased branch and --prune'ing. Git already gives you _plenty_ of different ropes to hang yourself with. The question is whether adding yet another one is worth it.
> Automatically installing grafts is wrong.
I tend to agree with you here, because the possibility for massive confusion is huge, but that doesn't deny the fact that, if used properly (and that's a _big_ 'if'), this is a very powerful feature.
...Johan
-- Johan Herland, <johan@herland.net> www.herland.net