On Tue, Dec 9, 2014 at 7:17 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
But the one place I do not agree is:
I think sequence.editor and core.editor are better because:
- they use the same syntax as the config variables, so they are easier
to remember and to
On Tue, Dec 09, 2014 at 10:17:13AM -0800, Junio C Hamano wrote:
It is a tangent, the current definition of git_editor helper reads
like this:
git_editor() {
if test -z ${GIT_EDITOR:+set}
then
GIT_EDITOR=$(git var GIT_EDITOR)
Jeff King p...@peff.net writes:
On Tue, Dec 09, 2014 at 10:17:13AM -0800, Junio C Hamano wrote:
This is another tangent that comes back to the original how to name
them? question, but I wonder if a convention like this would work.
* When asking for a feature (e.g. what editor to use), if
Jeff King p...@peff.net writes:
But the one place I do not agree is:
I think sequence.editor and core.editor are better because:
- they use the same syntax as the config variables, so they are easier
to remember and to discover, and
I really don't like using core.editor here, because it
On Fri, Dec 5, 2014 at 10:27 AM, Jeff King p...@peff.net wrote:
On Fri, Dec 05, 2014 at 03:27:17AM +0100, Christian Couder wrote:
I do not think git var --exec-path is a good idea, nor GIT_EXEC_PATH
for the environment-variable confusion you mentioned. I was thinking of
just creating a new
On Fri, Dec 05, 2014 at 03:27:17AM +0100, Christian Couder wrote:
For example, to chose the editor all the following could apply:
GIT_SEQUENCE_EDITOR env variable
sequence.editor config variable
GIT_EDITOR env variable
core.editor config variable
VISUAL env variable
EDITOR env variable
On Tue, Dec 02, 2014 at 09:26:00AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
There is also git var, which is a catch-all for printing some deduced
environmental defaults. I'd be just as happy to see it go away, though.
Having:
git --exec-path
git --toplevel
Jeff King p...@peff.net writes:
On Tue, Dec 02, 2014 at 09:26:00AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
There is also git var, which is a catch-all for printing some deduced
environmental defaults. I'd be just as happy to see it go away, though.
Having:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
Christian raised the issue of cluttering the git --option
namespace,
and I do agree that's a potential issue.
I am not sure if that is an issue at all. You will need the same
number of options to cover all the
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Jeff King p...@peff.net writes:
Christian raised the issue of cluttering the git --option
namespace,
and I do agree that's a potential issue.
I am not sure if that is an issue at all. You will
On Thu, Dec 04, 2014 at 11:02:37AM -0800, Junio C Hamano wrote:
Christian raised the issue of cluttering the git --option namespace,
and I do agree that's a potential issue.
I am not sure if that is an issue at all. You will need the same
number of options to cover all the necessary
Jeff King p...@peff.net writes:
... I was thinking of
just creating a new namespace, like:
git var exec-path
git var author-ident
and deprecating the 4 existing GIT_* variables.
I'm fine with that. As I wrote in my response to MMoy, I forgot
about other kinds of options the git potty
Jeff King p...@peff.net wrote:
Some of the discussion has involved mixing config options into this
kitchen sink, but that does not make any sense to me (and is why I
find git var -l so odd). Config options are fundamentally different, in
that they are set and retrieved, not computed (from
On Tue, Dec 2, 2014 at 8:04 AM, Jeff King p...@peff.net wrote:
On Mon, Dec 01, 2014 at 05:17:22AM +0100, Christian Couder wrote:
On Mon, Dec 1, 2014 at 4:04 AM, Junio C Hamano gits...@pobox.com wrote:
If I were redoing this today, I would probably nominate the git
potty as such a kitchen
Jeff King p...@peff.net writes:
There is also git var, which is a catch-all for printing some deduced
environmental defaults. I'd be just as happy to see it go away, though.
Having:
git --exec-path
git --toplevel
git --author-ident
all work would make sense to me (I often get
On Mon, Dec 01, 2014 at 05:17:22AM +0100, Christian Couder wrote:
On Mon, Dec 1, 2014 at 4:04 AM, Junio C Hamano gits...@pobox.com wrote:
If I were redoing this today, I would probably nominate the git
potty as such a kitchen synk command. We have --man-path that
shows the location of
Arjun Sreedharan arjun...@gmail.com writes:
On 30 November 2014 at 04:38, Philip Oakley philipoak...@iee.org wrote:
From: Arjun Sreedharan arjun...@gmail.com
This introduces `git root` which outputs the root directory
(the directory that contains .git).
The same can be accomplished by `git
Matthieu Moy matthieu@grenoble-inp.fr writes:
... git rev-parse --show-toplevel is not just long,
it's just not the place where people would look for (it's neither about
revision nor about parsing, so clearly, rev-parse is not a good place
to host the feature in the UI).
For the record,
On Mon, Dec 1, 2014 at 4:04 AM, Junio C Hamano gits...@pobox.com wrote:
If I were redoing this today, I would probably nominate the git
potty as such a kitchen synk command. We have --man-path that
shows the location of the manual pages, --exec-path[=path] that
either shows or allows us to
Christian Couder christian.cou...@gmail.com writes:
I wonder if we could reuse git config which is already a kitchen
synk command to get/set a lot of parameters.
I doubt it makes much sense.
* Things like toplevel and cdup are not even something you
configure. It is where you are, the
This introduces `git root` which outputs the root directory
(the directory that contains .git).
The same can be accomplished by `git rev-parse --show-toplevel`.
`git root` is much more intuitive and easy to remember.
All it does is set the arguments for rev-parse
Signed-off-by: Arjun Sreedharan
From: Arjun Sreedharan arjun...@gmail.com
This introduces `git root` which outputs the root directory
(the directory that contains .git).
The same can be accomplished by `git rev-parse --show-toplevel`.
`git root` is much more intuitive and easy to remember.
All it does is set the arguments for
On 30 November 2014 at 04:38, Philip Oakley philipoak...@iee.org wrote:
From: Arjun Sreedharan arjun...@gmail.com
This introduces `git root` which outputs the root directory
(the directory that contains .git).
The same can be accomplished by `git rev-parse --show-toplevel`.
`git root` is
23 matches
Mail list logo
