"lilinchao@xxxxxxxxxx" <lilinchao@xxxxxxxxxx> writes:
> I found an issue described like this:
>
> The blame information can be completely wrong when fetching it from
> a shallow clone, without errors or warnings. When the outcome is invalid
> data, it's extremely difficult to diagnose that it comes from a shallow clone.
> If a line in a file was not changed in the commits that were downloaded as
> part of the shallow fetch, git will report the first known commit as the author.
> This has a big impact on the auto-assignment of new issues.
>
> It looks like this is another scenario that can prove this feature is necessary.
In other words:
Users may want more history than the repository offered for
cloning, which happens to be shallow, can give them.
And the way chosen by "--reject-shallow" is to require that the
source repository has the entire history.
I wonder if the design of this UI is flexible enough so that we can
extend it to allow "I need the history that goes back at least to X"
in the future. "I need the history goes back to all the roots" then
becomes a narrow special case of that.
> After I applied your review suggestions above, then we can reject a
> non-local clone from shallow repo. For now, it will clone a empty
> repo with --no-local option.
It is my understanding that your patch with or without my suggestion
only deals with local clone and does not change anything for
non-local case. A "local-only" solution is a good place to start
and is a good test bed to experiment with the user experience, but I
view without support for non-local clone, it would not be ready for
general use.
Thanks.
