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!
We introduce the h--init-forges-state function in charge of
initializing the forge state and setting all the forges status to
loading. It prevents the forge names to gradually pop-up during a
forge request and instead display them with their appropriate status.
The synchronous git process call was freezing the whole UI for a
*pretty long* time when checking out a big git repository.
We move into using a asynchronous process. This change required quite
a lot of sync-related changes. Both in the h.el codebase as well as in
the test suite.
On top of making the git call asynchronous, we also take advantage of
not freezing the UI anymore to open a window displaying the git clone
progress.
h--pick-relevant-forges is an artifact of a former architecture.
On top of being some useless code, it was brittle and was preventing
us from cloning a repository from savannah.
We use the Gitea API to determine whether or not a given repo exists.
If it does, we use the API response to properly determine the SSH and
HTTPS clone URLs.
Félix Baylac Jacqué