Re: [PATCH 2/2] fast-import: add special '-' blob reference to use the previous one.
- From
Felipe Contreras <felipe.contreras@gmail.com>
- Date
- Dec 22, 2008, 02:10 UTC
- Message-ID
- <94a0d4530812211810x7d9772cbq9934dd6ea6e7f62a@mail.gmail.com>
- In-Reply-To
- <20081221223335.GF17355@spearce.org>
On Mon, Dec 22, 2008 at 12:33 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
Show 11 quoted lines
> Junio C Hamano <gitster@pobox.com> wrote: >> "Shawn O. Pearce" <spearce@spearce.org> writes: >> >> > Hmph, so if create a new path with a blob of "-" the repository >> > will be corrupt because the zero id was used and error was produced. >> > >> > Actually I think you have the same bug in the prior patch with the >> > mode being inherited. I wonder if we shouldn't put error checking >> > in too to validate that versions[0] describes a file entry. >> >> Why are these patches necessary?
Yeah, I realized I didn't explain that after sending the patches.
Show 22 quoted lines
>> The proposed commit message describes what it does, but does not give hint >> to even guess being able to use this new feature helps in what situation. >> As far as I can see, these changes allow the exporter to say "this aspect >> of the new data is the same as the previous one", but I thought that the >> way in which fast-import works already revolves around "you have this >> tree, and the next tree is different from it in this and that way." Why >> does one need be able to mention "this is the same as the previous one" >> explicitly in the first place? > > Hmm. Actually, imagine you were dumping from git-diff output style > stream into a fast-import stream. > > If a file changes only content, the mode is shown in the index line. > Yay us. But what if the index line wasn't present in the diff? You > don't know the prior mode of the file, but you do have its content. > > If a file changes only mode, we get no content hints in the diff. > How do you send that into fast-import without making the frontend > keep track of every path's current mode? > > Though I agree, these details should be described in the commit > messages, not left as an exercise for the maintainer to make up.
Exactly. That's what happens with monotone; you usually have the contents or the new mode, but not both at the same time.
-- Felipe Contreras