Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> throws too much. That would welcome their effort to enhance the >> importer, if they find it more useful to keep some other information >> found in global headers, without breaking the intent of this change. > > I don't think that we're throwing away anything because the PAX header is > intended to be a _header_, not a _file_, yet > `contrib/fast-import/import-tars.perl` currently treats PAX headers that > way. What I meant (and wrote) was information contained within the header. You could store such metadata (e.g. this tree came from this commit from the upstream project) in the commit object while importing, for example. As I wrote, I do not think we need to implement such feature right now. I am just saying that we should make sure we are not unintendely discouraging future developers from doing so by giving an impression that we are claiming "a pax header is intended to be a header and has no interesting information---never look at it". If we said "We discard the headers because it is the most expedient way and we currently have no use for them", that would make it clear that it is OK for them (the future ourselves developers) to extend the code not to lose the information, as long as they keep ignoring the prefix thing alone, if they want to follow the course set by this change. >> Having said all that, even before "git archive" existed, release >> tarballs by many projects had leading prefix so that a tarball >> extract would be made inside a versioned directory. To truly help >> users of the importer, doesn't the logic to allow the user to say >> "please strip one leading level of directory from all the tarballs I >> feed you, as I know they are versioned directories" belong to the >> command line option of the importer? > > I guess nobody needed an explicit way to strip path prefixes yet, since > the implicit way works so well. Now you confused me. If implicit way already works well, why are we adding this patch to make it implicitly ignore?
