Every one of the projects in this repository is available at the canonical
URL git://git.madduck.net/madduck/pub/<projectpath> — see
each project's metadata for the exact URL.
All patches and comments are welcome. Please squash your changes to logical
commits before using git-format-patch and git-send-email to
patches@git.madduck.net.
If you'd read over the Git project's submission guidelines and adhered to them,
I'd be especially grateful.
This is the API for an optional branch selection for `vcsh clone`. It is
basically inspired by `git clone [-b|--branch <name>] <remote>`. I could
have used the long option `--branch` too but vcsh only uses short ones.
This will create and checkout a local branch named after the upstream
branch. It will also gracefully behave for the default `master' branch
and consistently show the same message:
Caleb Maclennan [Wed, 26 Feb 2014 14:32:07 +0000 (16:32 +0200)]
add install instructions for osx
There are other ways to do this, but this seems to be the most commonly
used and easiest way to get the job done. Alternate methods could be
added but at least having this one will alert folks that using this on
OSX is an option.
Caleb Maclennan [Wed, 26 Feb 2014 12:21:02 +0000 (14:21 +0200)]
refactor install instructions to include myrepos
Since myrepos is so strongly recommended, included it in the distro
specific install instructions. Refactor the Arch Linux instructions
to better reflect most common usage.
Caleb Maclennan [Wed, 26 Feb 2014 11:39:39 +0000 (13:39 +0200)]
update Arch install guide to use stable packages
Encourage the use of the stable packages per disro norms. The devel
packages can be used but they trigger full git clones in many AUR
helpers and are generally a pain if you don't specifically want them for
something. Mention the devel package but update the URLs to point to
the one that uses the normal packaging system.
Caleb Maclennan [Tue, 25 Feb 2014 19:29:27 +0000 (21:29 +0200)]
update readme to reflect upstream project change
The `mr` utilily is now called myrepos upstream and they have a new
website address. Update the links in the readme, reflect the new name
of the project where appropriate, and fix the copy surrounding its
introdiction. The actual command is still `mr`.
Caleb Maclennan [Sun, 20 Oct 2013 01:35:10 +0000 (19:35 -0600)]
add sample hooks that allow cloning over extant files
Cloning a repo over an existing set of files would usually
cause a merge conflict that aborts the process and requires
manual intervention. This pair of hooks handles that case
by manually moving the extant objects out of the way,
completing the checktout, then restoring them to their
original places. The resulting state is a set of unstaged
local changes.
Caleb Maclennan [Sun, 20 Oct 2013 01:11:52 +0000 (19:11 -0600)]
add hooks to enable auto handing of merge conflicts
These hooks before and after the actual checkout process
will enable a pair of hook scripts to automatically handle
conflicts and potentially allow the checkout of repositories
over existing file sets
Dato Simó [Mon, 23 Sep 2013 20:47:43 +0000 (21:47 +0100)]
vcsh: don't allow `clone` to choke on filenames with spaces
By replacing the "for" loop with a "while" loop, it is easy to read
line-oriented output without worrying about spaces. However, now the
loop executes in a subshell, and VCSH_CONFLICT won't be available in
the parent shell. In this case, a trivial, portable solution is to
have the comparison as the last command in the subshell.
Dato Simó [Mon, 23 Sep 2013 21:13:54 +0000 (22:13 +0100)]
vcsh: strip host part from GIT_REMOTE when inferring VCSH_REPO_NAME
`vcsh clone` does:
VCSH_REPO_NAME=$(basename "${GIT_REMOTE}" .git)
Typically, most remote paths will have a non-empty directory component,
so using basename works well in all common cases. However, when doing
something like:
% vcsh clone example.org:repo.git
VCSH_REPO_NAME will be set to "example.org:repo" instead of "repo". This
also happens when using url.<x>.insteadOf, à-la:
% vcsh clone v:repo
Stripping everything up to the first colon in the remote URL fixes the
issue.
N.B.: remote URLs with protocol (e.g. http://, git://, or ssh://) do
not exhibit this problem, and are unaffected by this change.
Turns out the shell implementation didn't account for trailing
slashes. While, arguably, a proper interactive shell should eat
them before execution anyway, this can also be called in script
context.