| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
no behavior changes
|
| |
|
|
|
|
|
|
|
| |
This has two benefits.
1. When a lot of refs are going to be received, get them via lower cost
connection when possible.
2. Allows ctrl-c of sync after the cheaper remotes have been pulled from
(or pushed to).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now changes are staged into the branch's index, but not committed,
which avoids growing a large journal. And sync and merge always
explicitly commit, ensuring that even when they do nothing else,
they commit the staged changes.
Added a flag file to indicate that the branch's journal contains
uncommitted changes. (Could use git ls-files, but don't want to run
that every time.)
In the future, this ability to have uncommitted changes staged in the
journal might be used on remotes after a series of oneshot commands.
|
| | |
|
| |
|
|
| |
This will speed up commands like move and drop.
|
| | |
|
| |
|
|
|
|
|
| |
With --fast, unavailable local remotes are filtered out of the fast set.
This way, if there are local remotes, --fast always acts only on them,
and if none are mounted, acts on nothing. This consistency is better
than --fast acting on different remotes depending on what's mounted.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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.
|
| |
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
as described in the previous commit to the documentation. The loggin UI
is not great yet.
|
| |
|
|
|
| |
Left a few Prelude.head's in where it was checked not null and too hard to
remove, etc.
|
| | |
|
| |
|
|
|
| |
Constructors and configuration make sense in separate modules.
A separate Git.Types is needed to avoid cycles.
|
| | |
|
|
|
by running git commit, pull, and push for you.
|
Joey Hess
Joachim Breitner