Hello, > > > Users can always go back to the original format. At least I don't > > > expect this new format becoming the default too quickly. > > This is the most crucial issue here, as far as I am concerned: there are > already tons of .zip files out there that were created by git archive, and > there will inevitably be loads of tons more *having the current pax header > format*. > > So tools wanting to deal with Git archives will have to handle those as > well, i.e. do *precisely* as René suggested and use get-tar-commit-id. As > such, the value of changing the format *now* is a bit like closing the > barn's door after pretty much all of the horses left (except the old one > that has a few troubles getting up in the morning but that is too nice to > the kids to shoot). That's not really an argument. The situation you describes applies to all file formats and it always ends in the same way: A new file format is designed and then slowly adopted by the rest of the users, in case of git I imagine this to be a quick process taking maybe a year or two. Newly created files use the new file format and old files still hang around but their importance is dwindling until you can safely support only the new format. But to get there, a new file format has to be adopted in the first place. > > Sure thing. If this is going to be implemented, I would add options > > to choose what / what style of metadata to include. > > Why not put your money where your mouth is? I.e. get your head down into > the code and come up with a patch (because otherwise it is unlikely that > your idea will go anywhere)? I'd love to but I prefer to ask if there is interest in such a change in the first place. I'm not going to waste my time implementing this and then being told that the git project is not interested in this kind of functionality. So can someone give me a clear signal? > Ciao, > Johannes Yours sincerely, Robert Clausecker -- () ascii ribbon campaign - for an 8-bit clean world /\ - against html email - against proprietary attachments -- 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