* git-feature: add configurable branch separator
Closes#1069
This allows the use of a separator other than `/` for feature or other
alias branches. While a command-line option has been provided (`-s` or
`--separator`), this will most often be used via
`git-extras.feature.separator`.
* Significant update to bin/git-feature
- Changed option parsing so that `--alias` requires an argument and will
fail with an error unless provided. Applied the same logic to
`--separator`.
- Changed `finish` parsing to capture it as a variable flag during
argument parsing.
This could be extended so that if `finish` is already true, a second
`finish` results in the word being added to the argument list.
```console
$ git feature -- finish remote
$ git feature finish finish remote
```
This has not been done because it is a bit of an inconsistent handling
for documentation purposes.
- Add handling of `--` to permit options or `finish` to be made part of
the feature branch name.
- Since `finish` is now a variable flag, simplify the name-building
logic to always use `concatargs "${argv[@]}"`. This means that
`git feature finish ...` and `git feature ...` behave the same in
terms of feature branch name building.
- Basically rewrote the man page to include better descriptions of the
options as well as adding a GIT CONFIG section and additional EXAMPLES
for the new features/behaviour.
Closes#1067
This makes the base ARCHIVE_NAME for `git-archive-file` to be the name
of the repo root directory instead of the name of the current directory.
* I have made two improvements to the git-bulk:
1. Previously, if the "repository.txt" file did not end with a blank line, only three out of four repositories were cloned. This limitation has been fixed.
2. Now, there is support for cloning repositories into custom folder names when using the "repository.txt" file.
* Corrected the code indentation.
* removed the extra condition to check is the line was empty or not.
* Updated the comment for the new changes in the code.
---------
Co-authored-by: Jobin Kurian <jobin.kurian@netcorecloud.com>
We could think of the following use cases:
1. User installs git-extras from official port/pkg. man/man* structure
is quite common among different systems, but location of man/ itself can
be different. FreeBSD Ports framework setups MANPREFIX to PREFIX by
default, i.e. it's /usr/local. The idea is that software may provide
different man/man* sections, with final path being /usr/local/man/man*.
In contrast, git-extras' Makefile process simplifies the things due to
it works with section 1 only, and expects MANPREFIX to be set down to
man/man1 path. For this reason, installation via FreeBSD Ports requires
unconditional man path configuration like this:
ifeq ($(OS), FreeBSD)
MANPREFIX = "$(PREFIX)/man/man1"
Otherwise, the path will be incorrect. And this is how official FreeBSD
port of git-extras has been fixing this difference for many years.
2. End user installs git-extras manually. There are two sub-cases:
2.a. User explicitly defines custom MANPREFIX. Okay, it's user's
decision -- nothing to do here, just follow as is.
2.b. User does not define custom paths, i.e. it's expected to be
installed according to FreeBSD defaults. And default values in
git-extras' Makefile forms the expected correct path.
This change supports all the cases above, with the goal to avoid wrong
man path for the most of the situations. As long as official git-extras
make process tries to support FreeBSD, this change allows to omit extra
patching for FreeBSD Ports framework.
