- Jul 09, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Rather than mentioning Git objects, tell the user how many commits will be processed; it says the same, but is more useful.
-
- Aug 01, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
If multple paths point to the same URL, we should create remote references for all of them. At least considering that we don't know _which_ one the user specified…
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
for some reason or other, we didn't use the regular progress logic for push, swallowing some output
-
Dan Villiom Podlaski Christiansen authored
Dulwich silently changed its API some time ago.
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Oct 22, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This ensures that we'll add any tags or branches as soon as possible. The main downside is that this doesn't affect phases, currently.
-
Dan Villiom Podlaski Christiansen authored
We need this for bookmarks manipulation, sadly.
-
Dan Villiom Podlaski Christiansen authored
This makes it so that we only activate a bookmark on clone iff either: * -r/--rev was not specified and the remote HEAD points to a branch, or * the first -r/--rev specifies a bookmark
-
Dan Villiom Podlaski Christiansen authored
Previously, we would simply invent a master bookmark when this occurred, but in the specific case where the remote is empty. I believe that's actually unhelpful in the long run: Should a user not know about bookmarks, the first push will succeed, and subsequent pushes then not do anything. How did that bookmark get there? Instead, we should trigger a hard error for this case; that way, we'll hopefully cause the user to take a step back and find out how the command really works.
-
- Feb 05, 2021
-
-
Dan Villiom Podlaski Christiansen authored
As far as I can tell, this was previously used to "detect" an initial clone. Unfortunately, that logic is incorrect: like Mercurial, hg-git should consider pulling into an empty repository distinct from cloning. As an apparent aside, it also kind-of-sort-of handled the case where you pulled from a local Git repository into a location that happened to be default. To fix this, we do two things: 1) Expand relative local paths before comparing them to other paths. 2) Detect clone from the source of the default `default` path. The end result is: 1) You can pull from e.g. `../repo` to update remotes, with an equivalent path specified in the configuration 2) Pulls from entirely foreign remotes are no longer saved. 3) We always activate the desired bookmarks on clone. Although the two changes might seem unrelated, their effect is combined, and either alone would break the tests.
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Previously, we'd only write that when pushing to a named remote, rather than directly to its path or URL, which seems weirdly inconsistent.
-
- May 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Feb 05, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This code was quite hard to read.
-
- Jun 24, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Aug 01, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
This is handled by testutil these days; having it in each test is pointless clutter.
-
Dan Villiom Podlaski Christiansen authored
We currently imply a default path when pushing to unknown Git remotes, and add corresponding git-remote tags. Only one of our tests relies on this. To document the differences, run it with and without a path.
-
- Feb 05, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This makes it easier to see what's going on.
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 24, 2021
-
-
Dan Villiom Podlaski Christiansen authored
(it does not)
-
- Jun 18, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This is a premature optimisation, since Dulwich does a lot caching internally anyway. I have been unable to demonstrate any benefit from this; a bit of profiling shows that this stage of an incoming command takes ~12 seconds, even with more than 100k commits. Generally speaking, the actual conversion will take significantly longer time than caching these objects. In fact, the cache might actually be harmful for very long-running conversions, as they tend to run into memory constraints.
-
- Jul 07, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Dulwich has the add_thin_pack() function for adding a pack to the repository which may be thin, i.e. refer to objects outside the pack. We can avoid that on an initial clone, however, as we know that we just created the Git repository, meaning that the pack is never thin. The overhead is negligible on smaller repositories, but can be comparable to network transfer on a fast connection. The only downside is that it just might break something if the user specifies a preexisting Git repository in the configuration, but that seems a bit esoteric.
-
Dan Villiom Podlaski Christiansen authored
-
- Jun 21, 2021
-
-
Dan Villiom Podlaski Christiansen authored
Previously, we'd just load fetched data into memory, but that seems a bit wasteful. After all, some repositories can be quite large. Use a spooled temporary file instead when fetching repositories, and allow the customising the buffer size.
-
- Jul 09, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
This allows us to check progress more thoroughly.
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 07, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Oct 23, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-