Hi, [Shawn Cc'ed, since it affects fast-import] On Mon, 26 Nov 2007, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > > On Sun, 25 Nov 2007, Junio C Hamano wrote: > > > >> I am not sure if abort should be the default. > > > > I tried to be conservative. > > > >> If a straight dump-restore is made without rewriting, the result will > >> be identical to the original, right? > > > > Yep. > > ... > > I agree that for most serious operations sed is not good enough. > > My comment was more about the perception from a new user (not a "new git > user", but a "new fast-export and fast-import user"). > > When you see a command pair foo-export and foo-import, and it is > advertised that you can pipe them together, a new user would first try a > straight dump-restore, and would see the warning even though he did not > do any editing on the stream. > > Huh? Why does a tag signature become invalid because of merely > exporting and then importing? What is this warning about? Okay, I did not see that. > You would explain "yeah in your trial run you did not edit but the > command pair is to allow you editing the contents in between, and if you > do that, the object names might change.". > > If the default were "straight copy", then the user will not get an > invalid signature on his trial run, but will get an invalid signature > when he rewrites the object stream. You would get a message on the list > like this: > > Hello, I tried fast-export piped to fast-import so that I can > rewrite my repository, but I am getting invalid signature on > signed tags. It does not seem to happen if I do not edit but > just use the fast-export output without modification. What am I > doing wrong? > > And that is the time the explanation first becomes useful. IOW, you are > warning at the wrong place. "It may or may not corrupt the signature, I > do not know. Because it depends on what you are going to do with my > output, I cannot know. I am warning you anyway to cover my backside". > > I am wondering if fast-import input syntax can be extended to allow > checking inconsistencies. A command to import a tag could take an > additional object name and tell it to warn if the name of the tagged > object (the one sent with "from:%d\n" part) is different from that > object name. At that point, you know the object was rewritten and the > signature is invalid, and the choice of warning, stripping or aborting > becomes a useful thing to have. Why not check by default? Whenever there is a tag message containing the magic BEGIN line, it should check and at least warn if it does not match... Ciao, Dscho - 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
