On Mon, Dec 22, 2008 at 12:33 AM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote: > Junio C Hamano <gitster@xxxxxxxxx> wrote: >> "Shawn O. Pearce" <spearce@xxxxxxxxxxx> 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. >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
