Lars Schneider <larsxschneider@xxxxxxxxx> writes: >> Also the exact format of these attributes entries looks like very >> closely tied to GitHub LFS and not generic (for example, there is no >> reason to expect that any large-file support would always use the >> "filter" mechanism or the gitattributes mechanism for that >> matter), … > Agreed. Instead of just the filter name I will replace everything > after the pathname with a single git-p4 config value: I actually was going to suggest not doing any such replacing. You obviously need to cutomize the extensions list and specific paths that hold large contents, but having .attributeDescription() and .attributeFilter() that appear to be customizable sends a message to the reader that the code aims to support things other than GitHub LFS. I somehow doubt that really is the case (as you later mention, this would not work at all for solutions that are not based on gitattributes in the first place). It would be less misleading if it is made painfully obvious that this part of the code is about one specific backend. > Well, you have a very good point here. From my point of view you can > use git-p4 in two ways: > > _Way 1_: Your project is stored in Perforce and it will stay in > Perforce. You use git-p4 on a regular basis to interact with the > Perforce repository. > _Way 2_: Your project is stored in Perforce and you want to migrate it > to Git. You use git-p4 once to perform the migration. Afterwards you > never touch git-p4 or Perforce again. > > My large file system feature is intended to be used only for _Way 2_ > for exactly the reasons you mentioned. Would it still be OK to add > this feature to git-p4? Maybe with a appropriate warning in the docs? I could not tell, from the documentation that came in the patch, which one between the above two ways is supported, which made me assume that it aimed to support #1, as the desire to have a bidi bridge seems to be fairly common. It is a valid use case to migrate away and not looking back. But that is the only workflow that is supported, that fact needs to be documented more clearly, I would think. Otherwise those who expected a bidirectional bridge by reading the documentation would be disappointed, possibly after wasting a lot of time trying to figure out why their "git p4 submit" is not sending the full large blob contents back to the depot. Thanks. -- 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