Edward Thomson <[email protected]> writes:
> If I'm understanding you correctly, then on the libgit2 side, I'm very much
> opposed to this proposal. We never execute commands, nor do I want to start
> thinking that we can do so arbitrarily. We run in environments where that's
> a non-starter
>
> At present, in libgit2, users can provide their own mechanism for running
> clean/smudge filters. But hash transformation / compatibility is going to
> be a crucial compatibility component. So this is not something that we
> could simply opt out of or require users to implement themselves.
While I suspect the "apparent flexibility" does not equal to "we
must be able to run arbitrary external programs" in the proposal, I
do agree that hash transformation MUST NOT be configurable like
this. We do not want to add random source of incompatible mappings
when there is no need to introduce confusion.
If old object names under old hash users find in log messages and
other places need to be easily looked up in a repository that has
been converted, then:
(1) get_sha1() equivalent in the new world should learn to fall
back to use old hash when there is no object with that name
under new hash;
(2) in addition to the above fallback, there should be a syntax to
explicitly tell that function that it is using the old hash;
(3) get_commit_buffer() should learn to optionally allow converting
old hash in log messages to new ones, in a way similar to how
textconv filter can be specified by the end-users to make
binary blob easier to grok by text-based tools (the important
part is that such a filter does not have to be limited to
"upgrade hash algorithm"---it can be more general "correct
misspelt words automatically" filter).
With 1+2, you can say "git log $sha1" and also "git log sha1:$sha1"
to disambiguate. 3 would be icing on the cake.
