Override file modifiedTime by git commit history

[lawrenceching]

Override the modifiedTime by git commit history.

1. Add option "enableShallowClone" to enable/disable shallow clone
2. When enableShallowClone is false, clone without "--depth 1" so that we can retrieve real commit time for a file

[stevetweeddale]

Thanks for this PR! If you could remove the non-functional formatting changes that would make reviewing this a little easier.

I like the idea though. In fact to be honest, assuming I understand what you're doing here, I'm not sure if anyone would ever really want the local file modified time in the graph. I'd be tempted to a) make this the default, and b) strip out the option and role this into the next API-changing release.

[lawrenceching]

Hi @stevetweeddale ,

I do think so.

But the problem is, git does not record last modified time for a file.
The only way(If I didn't get it wrong) is to get the timestramp for file latest commit.

In the README, you expects a shallow clone (git clone --depth 1) to speed up buidling a project. That makes sense.
However, shallow commit lost all commit history.

The simple-git git.log(file) method returns the latest commit for given file. If you do a shallow clone, it returns the the latest commit for the whole repository, instead of file.

// https://github.com/stevetweeddale/gatsby-source-git/pull/26/files#diff-a6f3904c41211be170d9b0eb87e49ea8d02d0fd5a7224d6772174b425dacf90fR109
const latest = log.latest;
const {date, message, author_name} = latest;

So, are you expecting to enable this feature by default, and have a longer git clone time?
I'm open for any decision.

BR,
Lawrence

[stevetweeddale]

Ah righto, I hadn't connected that a shallow clone doesn't give you accurate commit times. That is significant as the original project this plugin was written for had a big history including binary files so a full clone was prohibitively slow, and I can imagine other users needing the clones to be shallow.

However, I've got recollections of other pull requests that wanted a full checkout rather than shallow clone. It makes sense for there to be an option to switch between a full clone/shallow clone where necessary, though given Gatsby's emphasis on speed my instinct would still be for "fast by default", and only doing a full clone when necessary.

[lawrenceching]

Hi @stevetweeddale ,

I updated my change, could you have a look when you have time? Thank you.

[lawrenceching]

@stevetweeddale, hope you can grep a chance to merge, and publish the new package to NPM.
Or would it be easier if to transfor the ownership as we discuss in this issue https://github.com/stevetweeddale/gatsby-source-git/issues/38？

[itsmejoeeey]

I encountered this problem today - I'd love to see these changes merged!

Are any further changes required or is this good-to-go?

[darthsteven]

We should probably document this in the readme?

[darthsteven]

Thanks for your work on this, and your patience!

The code to update the modifiedTime seems to work well for me in testing and seems like a great addition to the source plugin.

Rather than the slightly awkward enableShallowClone: false type construct, which makes me stop and think about exactly what the implication is, let's simply expose the 'fetch depth' as per other tools that do this sort of thing.

So, is there any chance that you could please:

• Rework this to add a fetchDepth option that defaults to 1, and the pass it all the way through.
• Add some documentation to the readme about the option, and saying why you might want to set it to something like 0. Also can we document the message and authorName fields too please?

[lawrenceching]

Finally I see some progress here.
I will update my PR accordingly this week.

[lawrenceching]

Test Evidence

1. fetchDepth is absent
   All files' modifiedTime is incorrect(the time of my latest commit)
   

2. fetchDepth is 0
   modifiedTime and message reflect to correct commit
   

@darthsteven, good to merge?

[lawrenceching]

Hi, any comment on this PR?

if no major concern on this change, I suggest we can merge this change into master.
And leave the minor issues to another PR.

Another round of review&change may delay this change to 2024...