Re: [PATCH v4 4/5] git-p4: add support for large file systems

Lars Schneider [off-list ref] writes:

quoted

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.