| Commit message (Collapse) | Author | Age |
| |
|
| |
|
|
|
|
| |
even if they have the lowest cost, we cannot use them
|
|
|
|
|
| |
mergeLocal always creates the local sync branch, so no need to check that
it exists later.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
mergeFrom is never called on branches that don't exist anymore
|
| |
|
|
|
|
| |
syncs those, in addition to any specified at the command line.
|
| |
|
|\ |
|
| | |
|
| | |
|
| |\ |
|
| | |
| | |
| | |
| | | |
Was getting SpecConstr warnings on Command.Find
|
| |\ \
| | | |
| | | |
| | | |
| | | | |
Conflicts:
debian/changelog
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
I was too heavy-handed in optimising away pushes
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Some changes to make automated syncing nicer. Merge from both the remote's
$branch and its synced/$branch; either could have new changes. Create
synced/$branch on the remote when pushing.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
and a nice error message if syncing is not set up yet
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This optimises away the need to run anything in some common cases.
It's particularly useful on push; no need to push if the tracking branch
we just pulled is the same as the branch we're going to push.
|
| | | | |
|
| | | | |
|
| | |/
| |/| |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The other uses of it can all be simplified using Git.Ref.base,
Git.Ref.under, and show.
In some cases, describe was being used to shorten the branch name
unnecessarily, and I instead pass the fully qualified name to git.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The describe function was only intended to generate a human-visible
description of a branch, but taking the base of a branch is a useful
operation to be able to do no matter the human-visible representation.
Converting a branch like refs/heads/master to refs/heads/origin/master
is also a useful operation, and under can do that.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
git-annex normally only runs the branch update once per run, for speed, but
since this fetches new remote git-annex tracking branches, they need to be
merged in after that fetch. An earlier call to Remote.byName was causing
the update to run before the fetch sometimes, but it could have been
anything. Just force the update to happen in the right place.
|
| | |
| | |
| | |
| | |
| | | |
This code is picked from my tweak-fetch branch, which already did the needed
refactoring.
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
base
Consider this git config --list case:
url.git+ssh://git@example.com/.insteadOf=gl
url.git+ssh://git@example.com/.insteadOf=shared
Since config is stored in a Map, only the last of the values for this key
was stored and available for use by the insteadOf code. But that
is wrong; git allows either "gl" or "shared" to be used in an url and
the insteadOf value to be substituted in.
To support this, it seems best to keep the existing config map as-is,
and add a second map that accumulates a list of multiple values for
config keys. This new fullconfig map can be used in the rare places where
multiple values for a key make sense, without needing to complicate
everything else.
Haskell's laziness and data sharing keep the overhead of adding
this second map low.
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
as described in the previous commit to the documentation. The loggin UI
is not great yet.
|
| | | |
|
| | | |
|
| | | |
|
| | |\ |
|
| | | | |
|
| |/ /
|/| | |
|