- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
This is an area where we have no choice but diverging from stock Mercurial, as Git does not allow anonymous heads. We can only push something that has either a bookmark or a tag. In order to lessen confusion for users, we output a message inspired by Mercurial's (ignoring %d secret commits) — which serves a similar purpose.
-
- Nov 03, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 09, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Feb 05, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
I think this was added in Mercurial 2.1, or something.
-
- Oct 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 06, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Oct 31, 2021
-
-
Dan Villiom Podlaski Christiansen authored
-
- Jul 09, 2021
-
-
Dan Villiom Podlaski Christiansen authored
By default, Mercurial shows the last 20 characters of the current item, but commits are usually shortened from the front.
-
Dan Villiom Podlaski Christiansen authored
-
Dan Villiom Podlaski Christiansen authored
Generally speaking, Mercurial refers to commits as “changesets”. And mention how many we're processing while at it.
-
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
-