* Added api_url configuration to RemoteConfig
* Added api_url remote config parameter to the documentation
* Fmt
* Readded use statement erroneously removed
* chore: bring back https in gitlab link
* docs(website): add missing dot to remote docs
* refactor(remote): clean up constant handling
* fix: fix the behavior and add fixture test
* docs: add example of api_url
---------
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
* feat: jujustu support
If the .git directory can't be opened (usually because the `.git` directory is missing) it attempts to find the git repository in the location used by Jujutsu (i.e. `.jj/repo/store/git`). If the Jujutsu git directory doesn't exist, then the origin error is propogated.
CODE
test: add unit tests for opening jujutsu repo
Update git-cliff-core/src/repo.rs
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
Update git-cliff-core/src/repo.rs
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
Update git-cliff-core/src/repo.rs
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
Update git-cliff-core/src/repo.rs
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
* docs: Add page to website for jujutsu
---------
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
* fix(remote): preserve first time contributors
* fix: update based on clippy feedback
* docs: add new-contributors back in
* refactor: switch to using time
- add test for timestamp method as well
* refactor: polish implementation
---------
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
* feat: find upstream remote when using ssh
The `upstream_remote` function was relying on `url::Url::parse` to extract the `owner` and `repo` from the `url`. But that only works when the repo is cloned using a URL, e.g. `https://github.com/orhun/git-cliff.git`. However, this would fail to parse when cloned using SSH, e.g. `git@github.com:orhun/git-cliff.git`.
If the url::URL::parser fails, we now try to parse an SSH remote in the format `git@hostname:owner/repo.git`.
The error from `upstream_remote` also notes that a posible reason for it failing would be that the `HEAD` is detached.
* Update git-cliff-core/src/repo.rs
* Update git-cliff-core/src/repo.rs
---------
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
* chore(docker): ignore rust toolchain in docker builds
This commit adds the known names of the rust-toolchain files to the
.dockerignore file. This has two reasons why it makes sense:
- The initial docker layer already has a set up rust toolchain that is
sufficient to build the project. Thus, by providing a toolchain file,
the toolchain would be installed again during docker build.
- Currently cargo-chef only copies the toolchain files during cooking
but it gets not used during the building of the dependencies in the
cook call, see
https://github.com/LukeMathWalker/cargo-chef/issues/271.
With this in mind, currently the dependencies were actually build
twice. Once with the installed toolchain from the image itself, and
then in the actual cargo build call with the toolchain speciefied in
the toolchain file. Building them twice resulted in timeouts when
building the arm64 images as they are emulated using qemu, which is
itself already slower than building natively.
Now one could argue, that as soon as the mentioned issue is solved using
the toolchain again would be fine. But then it would be still needed to
assemble the Dockerfile in a way that the toolchain is not build twice.
Because the current structure of the Dockerfile builds the toolchain
once in the cargo-chef prepare step and once during the cargo build step
(and would later build it during the cargo-chef cook instead of cargo
build).
With all this in mind using no toolchain file but instead just using
the sufficient rust installation from the base image makes sense.
* Revert "chore(docker): disable building arm64 docker images temporarily (#879)"
This reverts commit cde2a8e322.
Commit 73f75d5289 made it possible to
build the arm64 image again without running into timeouts.
* feat(commit): add `raw_message` to `Commit`
* test(fixtures): add test generate all fields in conventional commits
* test(fixtures): add test do not discard missing fields in conventional
commits when reading from context
* docs(website): add `raw_message` fields to `context.md`
* fix(bitbucket): pull requests release metadata not matched correctly
- update BitbucketPullRequest struct to use merge_commit
- update metadata matching to support short sha format
- add tests for Bitbucket remote
* test: update bitbucket fixture to include pr test
* chore(fixture): use link in bitbucket fixture
---------
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
* feat(git): latest with one tag should include root
* feat(git): test root commit with one tag
* feat(git): remove the include_root boolean flag
Use the fact that a range contains (or doesn't) contain
".." as a discriminant between the two cases:
- ".." means full (left-exclusive) range between two commits;
- no ".." means everything from the root commit (inclusive) to
the commit sha in the range
* fix: remove unnecessary reference
* nit: gentler English in comment
* feat: add color to the help text
* fix: use colors closer to logo colors
* style: update placeholder color
---------
Co-authored-by: Orhun Parmaksız <orhunparmaksiz@gmail.com>
