Second stab at fixing this bug. Except I tool the time to do it in a
non-rushed clean way this time around.
We introduce a properly tested is-clone-url-in-code-root predicate. We
then plug this predicate at the clone call sites instead of wrapping
the interactive command.
Trying to clone a repository already living in the code root was
leading to a bogus "xxx does not seem to be a valid git repository
URL" error.
We fix this by first resolving the repository path on the local disk
and check whether or not we already cloned it. If that's the case,
open the repository instead of trying to clone it.
The git stdout newline separator is customizable. Sadly for us, it
seems like it uses a carriage return (CR) separator by default. Emacs
won't treat CR as a newline, it needs a CR;LF.
We can configure git to use CR;LF, that being said, we don't want to
modify the user's git configuration here.
Adding a process filter to rewrite the newline separators on the go.
Supporting the git/ssh scheme for fully qualified URLs.
Quoting https://git-scm.com/docs/git-clone#_git_urls:
> The following syntaxes may be used with them:
> ssh://[user@]host.xz[:port]/path/to/repo.git/
> git://host.xz[:port]/path/to/repo.git/
> http[s]://host.xz[:port]/path/to/repo.git/
> ftp[s]://host.xz[:port]/path/to/repo.git/
>
> An alternative scp-like syntax may also be used with the ssh protocol:
> [user@]host.xz:path/to/repo.git/
git clone is creating a destination empty directory before even
attempting to clone the remote URL. It means that if the user-supplied
remote URL happen to be invalid, an empty directory is getting created
at dest, preventing us to try cloning the same repository once again.
We fixed that issue by checking whether the remote git repository
exists using git ls-remote **before** calling git clone.
git ls-remote will fail on a git repository not containing any git
commit. We add a function to the test bed creating a git repo with one
commit. It's a bit hacky, but that's the best setup I could come with.
We embed a dummy git repo to the my-repo-pins codebase and copy it
during the test phase to a tmp workspace.
Simple change that also accepts `.git` *files*, instead of only `.git`
directories, as indicating valid git projects. This is a cheap way (i.e. low
performance cost) to detect git worktree repos.
Closes#11
Changelog:
- Add the my-repo-pins-max-depth customization variable. This variable
prevents my repo pins from accidentally recursing too far in the
code-root directory. Solves a performance issue with git subtrees.
- When cloning a project from a fullly qualified URL, we make sure the
project does not exists locally first. If it does, we jump to the
local clone without trying to clone it again.
We currently discriminate a regular directory from a project by
looking for a .git directory. This heuristics works reasonably well
but isn't perfect. It'll fail for non-git projects, git worktree, etc.
We were recursing through the code root until we reached a project. If
the project detection heuristics fails, we'll recurse way too deep.
This can create some serious performance issues.
We introduce a maximum recursion depth to prevent the tree walker from
recursing too deep. We set this maximum to 2 by default to reflect the
expected <forge>/<user>/<project> scheme.
We expose this maximum depth via a customization variable. If set to
nil, there won't be any limit.
Kudos to Marcin S. aka. m-cat for the help.
Bug report: https://github.com/NinjaTrappeur/my-repo-pins/issues/7
When cloning a project from a fullly qualified URL, we make sure the
project does not exists locally. If it does, we jump to the local
clone without trying to clone it again.
Fixes https://github.com/NinjaTrappeur/my-repo-pins/issues/9
Removing the unnecessary ".el" suffix. It was originally here to
disambiguate h.el from the original h project.
We now have a unique name, we don't need this disambiguation anymore.
As mentionned by riscy in the comment
https://github.com/melpa/melpa/pull/8093#issuecomment-1173207615, you
don't need any progn for let, lambda, defun and when bodies.
Removing the unecessary progn calls, leaving the 4 necessary ones: the
ones wrapping the if/else bodies.
Hinted by the Melpa maintainers here:
https://github.com/melpa/melpa/pull/8093
Using a single letter name was a mistake. Renaming the project to
something a bit more sensible. Maybe not too sensible that being said:
we had to adopt a pun.
Kudos to Wiwi for the pun: it's perfect.
We had a bug when git was exiting with a strange error code. We were
ending up with a event in the form of:
exited abnormally with code 128
I'm not sure how to properly handle these events. I fixed this error
by calling the callback regardless of the event. It might backfire in
the future though: in some cases, a process can trigger a event
without exiting according to the manual. In that case, we'll end up
calling the callback with nil as exit code. I'm not 100% sure h.el
will handle that gracefully.
That being said, I never encountered this use case so far. I guess
it'll be a problem for future me to solve!
Félix Baylac Jacqué
Ninjatrappeur