Rich-Harris/degit

--mode=git doesn't seem to respect git hash provided to degit

brunobely opened this issue · 5 comments

When trying to degit a private repo I used the following command:

degit user/repo#commit my-project --mode=git

However, instead of having #commit cloned to the my-project directory, I had the latest commit. Not sure if WAI or if it's a bug but figured I'd file an issue.

I think you might've found a bug.
With this commit hash we are expecting version 2.2.2, but we get 2.8.4.

➜  /tmp degit Rich-Harris/degit#79d492b7820fa57ba1b2fc2020e74e87bf43f3a2 degit-test --mode=git
> cloned Rich-Harris/degit#79d492b7820fa57ba1b2fc2020e74e87bf43f3a2 to degit-test
➜  /tmp cd degit-test
➜  degit-test head -n3 CHANGELOG.md
# degit changelog

## 2.8.4
➜  degit-test

Somebody please correct me if I have done something wrong.

On our project, we've also found that unless the provided commit hash is the most recent one for the repository, it will fail. In other words, if you choose the latest commit hash, degit will work just fine. But if that repository pushes a newer commit, the older hash stops working.

Hmmm... Could that be because it does git clone --depth 1?

Nevermind what I said in that previous comment. degit does not do depth 1 in _cloneWithGit method. Tiged does. I misremembered.

I noticed that there is a really good pull request that would add ability to use older commit hashes, subdirs and uses depth 1 for faster cloning. I have totally missed this before:
https://github.com/Rich-Harris/degit/pull/228/files

We've implemented subdirs and depth 1 in tiged, but have not added ability for older hashes.
I will see try to get that merged to tiged/tiged soon.

@brunobely @visnaut This has now been fixed in the newest version of tiged. https://github.com/tiged/tiged

That pull request did not work. So I had to do it myself. It was actually quite fun to figure it out.