- Apr 04, 2021
-
-
Georges Racinet authored
This makes the version number importable from Python code as `hgitaly.__version__`, with the single source of truth being the `hgitaly/VERSION` file.
-
Georges Racinet authored
-
- Mar 04, 2021
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
- Mar 30, 2021
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
It was recorded as "copy" instead of "rename" as we didn't pass the 'bar' to wrapper.commit() It didn't have any impact on response because response attrs won't really have any difference b/w rename and copy. But this change is to make sure that we have correct repo setup as explained by comments.
-
- Feb 28, 2021
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
This will be used by upcoming patches.
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
- Mar 26, 2021
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
- Feb 27, 2021
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
This will be used in forthcoming patches.
-
- Feb 17, 2021
-
-
Sushil Khanchi authored
This will be useful in next patch.
-
- Mar 28, 2021
-
-
Sushil Khanchi authored
-
- Feb 27, 2021
-
-
Sushil Khanchi authored
For clarity and non-confusing for upcoming patches.
-
- Feb 09, 2021
-
-
Sushil Khanchi authored
-
- Feb 27, 2021
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
- Mar 29, 2021
-
-
Georges Racinet authored
-
- Mar 14, 2021
-
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
Sushil Khanchi authored
-
- Mar 19, 2021
-
-
Georges Racinet authored
Since the stable branch will give us HGitaly 0.11, we have to bump to 0.12 in the default branch
-
Georges Racinet authored
Since we're about to add at least one new service method, next version on the stable branch will be 0.11
-
Georges Racinet authored
-
- Mar 12, 2021
-
-
Georges Racinet authored
Found out about this while testing with the Rails app. Of course, it is natural for symbolic refs, and doesn't sound very logical with normal refs, a result of under-specification ultimately due to the fact that Gitaly simply uses `git update-ref`. We keep refusing ref target revisions for keep-arounds because we are much surer that the Rails app will only use full SHAs as target revisions. Also, it swallows exceptions, avoiding failures if `WriteRef` refuses to create the keep-around (see `Gitlab::Git::KeepAround`). We should have a Gitaly comparison test for this, but we already have RSpec tests in the Rails app, so this can be in a follow-up.
-
Georges Racinet authored
The work to support special refs is well worth a minor version update.
- Mar 11, 2021
-
-
Georges Racinet authored
Usually, I would stand against wide exception catching, even with proper logging. But in this case, we're about (Heptapod 0.20.2) to have the Rails app repeat all special refs creations to HGitaly, and it should soon (Heptapod 0.21) even be the case for non-native Mercurial projects. Currently (HGitaly 0.9), all special refs creation do fail for native Mercurial projects, and that is no problem, with a major exception: Merge Requests refs are created by an actual Git fetch and are really needed.
-
Georges Racinet authored
reminder: all current projects handled with HGitaly have a Git repo.
-
Georges Racinet authored
Closes #52
-
Georges Racinet authored
Without an explicit return, it was giving a gRPC error
-
- Mar 09, 2021
-
-
Georges Racinet authored
-
- Mar 10, 2021
-
-
Georges Racinet authored
Closes #50
-