Re: Feature request: Provide porcelain to manage symbolic references as branch aliases

[Phil Sainty]

Updating the proof-of-concept script for this feature request.

(See attachment.)

I'm quoting the entire original message for reference, just because
it's been a while since I proposed this.

-Phil


On 30/04/14 00:51, Phil Sainty wrote:
> Most of the plumbing for having branch name aliases already exists
> in the form of symbolic references, and people do use them for this
> purpose; but I get the impression that it's not really supported
> officially, and I'm not aware of any porcelain features to
> facilitate this use-case.
>
> I'd like to propose that such porcelain be added. I feel that a new
> argument to 'git branch' would make the most sense:
>
> git branch --alias  []
>
> For reference/testing, I'm attaching a wrapper script I wrote to
> implement the same functionality (as a separate command). I did this
> primarily to provide the error-checking I felt was needed to make it
> practical to use branch aliases -- git symbolic-ref will happily
> trash your branch references if you make a mistake, whereas it's
> pretty difficult to mess anything up with my git-branch-alias script.
>
> Thus far it's worked nicely for me. Examples:
>
> $ git branch-alias   # create alias
> $ git branch-alias  # create alias for current branch
> $ git branch # view branches and branch aliases
> $ git log 
> $ git checkout 
> $ git push origin  # pushes the branch, not the alias/reference
> $ git branch-alias -d  # delete an alias safely
>
> n.b. For my proposed porcelain change, these examples would become:
> $ git branch --alias   # creates
alias
> $ git branch --alias  # create alias for current branch
> $ git branch --delete  # works since 1.8.0.1, but see below.
>
>
> Since using this script, the only thing I've spotted that I'd like
> to be different is the commit message if I "git merge ". The
> commit message indicates that I've merged  rather than the
>  that it points at. I'd prefer that it was dereferenced
> when the message was generated, so that the real branch name was
> printed instead.
>
>
> That niggle aside, significant things I noted along the way were:
>
> 1. Git 1.8.0.1 fixed the problem whereby git branch -d 
>used to dereference  and therefore delete the branch
>it pointed at, rather than the reference.
>
> 2. HOWEVER if you have  checked out at the time you
>delete it, you're in trouble -- git allows you to do it, and
>you're then left with an invalid HEAD reference.
>
>(I think this ought to be considered a current bug in git.)
>
> 3. I resolved that situation (2) by using "git symbolic-ref HEAD"
>to find the target ref, and setting HEAD to that target. Nothing
>changes for the user, but we can now delete the reference safely.
>
>HOWEVER, there's a problem with detecting that situation (2)
>in the first place:
>
> 4. Chains of references are de-referenced atomically -- the entire
>reference chain is followed to its end; and I could find no
>facility to obtain ONLY the "next link of the chain".
>
>This means we can't use "git symbolic-ref HEAD" to check whether
>it points to another reference. In my script I had to resort to
>inspecting HEAD manually, which obviously isn't desirable.
>
>I think a new argument is warranted here, perhaps something like:
>"git symbolic-ref --max-deref-count=1"
>
>I'll justify that on the assumption that (2) needs fixing in git
>regardless, either by:
>
>(i) Not allowing the user to delete the checked-out symref (which
>would be consistent with the behaviour if the user attempts to
>"git branch -d " (for an actual branch name) when that
>is the currently checked-out branch.
>
>or,
>(ii) Using the approach I've taken: silently setting HEAD to the
> branch to which the symref points before deleting that symref.
> (I couldn't see any reason not to use this approach.)
>
>But as in both cases we need to detect that HEAD is the symref
>being deleted, which means that we need the ability to explicitly
>dereference only a single step of a reference chain.
>
>
> -Phil
>

#!/bin/sh
# git branch-alias
# Author: Phil S.
# Version 1.11
version=1.11

# Creates branch aliases, so that you can refer to a long branch name
# by a convenient short alias.  This is particularly useful for branch
# names beginning with bug-tracker ID numbers (or similar), where the
# benefits of tab-completion are greatly reduced.

# This is mostly a "do what I mean" wrapper around "git symbolic-ref",
# with numerous safety measures included in order to eliminate the
# (otherwise considerable) risk of trashing a branch if you get your
# arguments wrong.

# Installation:
# Place this script somewhere in your PATH and name it "git-branch-alias"
# and you will be able to invoke it with "git branch-alias" as per the
# following examples.

# Examples:
# git branch-alias   # create alias
# git branch-alias  # create alias for current branch
# git branch # view branches and 

Re: Feature request: be able to pass arguments to difftool command

[Junio C Hamano]

David Aguilar  writes:

> While I do see the utility, it would be just as easy to configure a 2nd
> and 3rd variant of the same difftool and use those as needed instead.
>
> "git difftool -t ccdiff2" or "-t ccdiff3" is the simplest, and there's
> nothing stopping the user from creating aliases to shorten it further.
> ...
> We already have two mechanisms for controlling the inner command that's
> launched by difftool.  IMO we don't need more.

OK, fair enough.

Re: Feature request: be able to pass arguments to difftool command

[David Aguilar]

On Wed, Aug 29, 2018 at 09:18:38AM +0200, H.Merijn Brand wrote:
> On Tue, 28 Aug 2018 12:37:40 -0700, Junio C Hamano 
> wrote:
> 
> > "H.Merijn Brand"  writes:
> > 
> > > So, my wish would be to have an option, possibly using -- to pass
> > > additional command line arguments to git difftool, so that
> > >
> > >  $ git difftool $commit~1..$commit -- -m -v2
> > >
> > > would pass the arguments after -- transparantly to ccdiff (in my case)  
> > 
> > At the syntax level passing any option after "--" would be a no
> > starter, as I would imagine that "git difftool $revs -- $paths"
> > should still be supported.
> > 
> > At the concept level, however, I can see why such a feature would be
> > useful.  Perhaps
> > 
> > $ git difftool --backend-option=-m --backend-option=-v2 HEAD
> > $ git mergetool --backend-option=--foo
> 
> This would mean I can just pass remaining arguments, like this?
> 
> --8<--- ~/bin/git-ccdiff
> #!/usr/bin/env perl
> use 5.18.3;
> use warnings;
> 
> my $commit;
> 
> @ARGV && $ARGV[0] !~ m/^-/ and $commit = shift;
> 
> my @git = qw( git difftool );
> defined $commit and push @git, "$commit~1..$commit";
> system @git, @ARGV;
> -->8---
> 
> > with appropriate way(s) [*1*] to make it easier to type (and
> > implement) would be an acceptable avenue to pursue, I wonder?
> 
> I like it, as long as they are all separate options in the backend and
> not available in one single variable that needs to be split
> 
> I can envision a configure variable like
> 
>   backends.options.separator = U+2063
> 
> so the backend can safely split on that itself. But I also see this as
> overly complex en over-engineering


Personally, I think it'd be better to keep the tool simple.

While I do see the utility, it would be just as easy to configure a 2nd
and 3rd variant of the same difftool and use those as needed instead.

"git difftool -t ccdiff2" or "-t ccdiff3" is the simplest, and there's
nothing stopping the user from creating aliases to shorten it further.

We also already have, "git difftool -x / --extcmd"
for specifying a full-on external diff command.

>   git -c difftool.ccdiff.opts=-v2 -c difftool.ccdiff.opts=-m difftool

For example, this seems simpler as:

git difftool -x 'ccdiff -v2 -m'

We already have two mechanisms for controlling the inner command that's
launched by difftool.  IMO we don't need more.

My primary concerns with --backend-opts are as follows:

1. If we add a mechansim for passing -X/--backend-opts, then we
   need to specify a new variable that users will need to be aware
   of when creating custom commands.  (sorry for stating the obvious)

2. All of the built-in commands would need to change to honor that
   variable.

3. The documentation becomes more complex because someone that wants
   to configure a bog-standard custom external tool now needs to
   be aware of this extra external source of arguments.

#1 and #2 are primarily implementation concerns, but #3 suggests
to me that it's over-complicating things.

Furthermore, #2 is not really that simple.
What would the sciplet look like?

diff_cmd () {
"$merge_tool_path" $EXTRA_ARGS ...
}

That implies that we would need to shell quote stuff when
constructing $EXTRA_ARGS internally if we were to support multiple -X
arguments.  That just made it a bit more complex.

IMO we should be working to simpliify, not make things more complex for
rare use cases.  There's no reason the user can't just do:

V=2 git difftool
V=3 git difftool

... and let the inner script check for $V (or any other) variable.
While environment variables aren't great, this does seem like the right
place to use them.

Another option -- we already eval the configured command, so if the user
includes a variable ($ARGS) in their custom configuration then they can
specify extra flags today without needing to change the tool.  ex:

[difftool "ccdiff"]
cmd = ccdiff $ARGS \"$LOCAL\" \"$REMOTE\"

ARGS='-v2 -m' git difftool HEAD~1..HEAD


Are these alternatives short and simple enough?
-- 
David

Re: Feature request: hooks directory

[Wesley Schwengle]

Hello Christian,

2018-09-03 6:00 GMT+02:00 Christian Couder :
> Hi Wesley,
>
> On Sun, Sep 2, 2018 at 11:38 PM, Wesley Schwengle  wrote:
>> Hi all,
>>
>> I've made some progress with the hook.d implementation. It isn't
>> finished, as it is my first C project I'm still somewhat rocky with
>> how pointers and such work, but I'm getting somewhere. I haven't
>> broken any tests \o/.
>
> Great! Welcome to the Git community!

Thank you!

>>  You have a nice testsuite btw. Feel free to comment on the code.
>>
>> I've moved some of the hooks-code found in run-command.c to hooks.c
>>
>> You can see the progress on gitlab: https://gitlab.com/waterkip/git
>> or on github: https://github.com/waterkip/git
>> The output of format-patch is down below.
>
> It would be nicer if you could give links that let us see more
> directly the commits you made, for example:
> https://gitlab.com/waterkip/git/commits/multi-hooks

Yeah.. sorry about that. Let's just say I was excited to send my
progress to the list.

>> I have some questions regarding the following two functions in run-command.c:
>> * run_hook_le
>> * run_hook_ve
>>
>> What do the postfixes le and ve mean?
>
> It's about the arguments the function accepts, in a similar way to
> exec*() functions, see `man execve` and `man execle`.
> In short 'l' means list, 'v' means array of pointer to strings and 'e'
> means environment.

Thanks, I'll have a look at these functions later today.

>> format-patch:
>>
>> From 129d8aff8257b22210beadc155cdbcae99b0fc4b Mon Sep 17 00:00:00 2001
>> From: Wesley Schwengle 
>> Date: Sun, 2 Sep 2018 02:40:04 +0200
>> Subject: [PATCH] WIP: Add hook.d support in git
>
> This is not the best way to embed a patch in an email. There is
> Documentation/SubmittingPatches in the code base, that should explain
> better ways to send patches to the mailing list.

I saw that as well, after I've submitted the e-mail and was looking at
the travis documentation. I'll promise I'll do better for my next
patch submission. Sorry about this..

>> Add a generic mechanism to find and execute one or multiple hooks found
>> in $GIT_DIR/hooks/ and/or $GIT_DIR/hooks/.d/*
>>
>> [snip]
>>
>> * All the scripts are executed and fail on the first error
>
> Maybe the above documentation should be fully embedded as comments in
> "hooks.h" (or perhaps added to a new file in
> "Documentation/technical/", though it looks like we prefer to embed
> doc in header files these days).

I've added this to "hooks.h". If you guys want some documentation in
"Documentation/technical", I'm ok with adding a new file there as
well.

>> diff --git a/hooks.h b/hooks.h
>> new file mode 100644
>> index 0..278d63344
>> --- /dev/null
>> +++ b/hooks.h
>> @@ -0,0 +1,35 @@
>> +#ifndef HOOKS_H
>> +#define HOOKS_H
>> +
>> +#ifndef NO_PTHREADS
>> +#include 
>> +#endif
>> +/*
>> + * Returns all the hooks found in either
>> + * $GIT_DIR/hooks/$hook and/or $GIT_DIR/hooks/$hook.d/
>> + *
>> + * Note that this points to static storage that will be
>> + * overwritten by further calls to find_hooks and run_hook_*.
>> + */
>> +//extern const struct string_list *find_hooks(const char *name);
>
> The above comment is using "//" which we forbid and should probably be
> removed anyway.

Thanks, I have a "//" comment elsewhere, I'll change/remove it.

>> +extern const char *find_hooks(const char *name);
>> +
>> +/* Unsure what this does/is/etc */
>> +//LAST_ARG_MUST_BE_NULL
>
> This is to make it easier for tools like compilers to check that a
> function is used correctly. You should not remove such macros.

Check.

>> +/*
>> + * Run all the runnable hooks found in
>> + * $GIT_DIR/hooks/$hook and/or $GIT_DIR/hooks/$hook.d/
>> + *
>> + */
>> +//extern int run_hooks_le(const char *const *env, const char *name, ...);
>> +//extern int run_hooks_ve(const char *const *env, const char *name,
>> va_list args);
>
> Strange that these functions are commented out.

These two functions are still in "run-command.h" and I want to move
them to "hooks.h" and friends. But I first wanted to make sure
"find_hooks" worked as intended. This is still on my TODO for this
week.

>> +#endif
>> +
>> +/* Workings of hooks
>> + *
>> + * array_of_hooks  = find_hooks(name);
>> + * number_of_hooks_ran = run_hooks(array_of_hooks);
>> + *
>> + */
>
> This kind of documentation should probably be at the beginning of the
> file, see strbuf.h for example.

Since I added the better part of the commit message in "hooks.h" I
removed this bit.

An additional question:

In my patch I've added "hooks.multiHook", which I think I should
rename to "hooks.hooksd". It is wanted to change "core.hooksPath" to
the "hooks" namespace? Or should I rename my new config item to
"core.hooksd"?

Cheers,
Wesley

-- 
Wesley Schwengle, Developer
Mintlab B.V., https://www.zaaksysteem.nl
E: wes...@mintlab.nl
T:  +31 20 737 00 05

Re: Feature request: hooks directory

[Christian Couder]

Hi Wesley,

On Sun, Sep 2, 2018 at 11:38 PM, Wesley Schwengle  wrote:
> Hi all,
>
> I've made some progress with the hook.d implementation. It isn't
> finished, as it is my first C project I'm still somewhat rocky with
> how pointers and such work, but I'm getting somewhere. I haven't
> broken any tests \o/.

Great! Welcome to the Git community!

>  You have a nice testsuite btw. Feel free to comment on the code.
>
> I've moved some of the hooks-code found in run-command.c to hooks.c
>
> You can see the progress on gitlab: https://gitlab.com/waterkip/git
> or on github: https://github.com/waterkip/git
> The output of format-patch is down below.

It would be nicer if you could give links that let us see more
directly the commits you made, for example:
https://gitlab.com/waterkip/git/commits/multi-hooks

> I have some questions regarding the following two functions in run-command.c:
> * run_hook_le
> * run_hook_ve
>
> What do the postfixes le and ve mean?

It's about the arguments the function accepts, in a similar way to
exec*() functions, see `man execve` and `man execle`.
In short 'l' means list, 'v' means array of pointer to strings and 'e'
means environment.

> format-patch:
>
> From 129d8aff8257b22210beadc155cdbcae99b0fc4b Mon Sep 17 00:00:00 2001
> From: Wesley Schwengle 
> Date: Sun, 2 Sep 2018 02:40:04 +0200
> Subject: [PATCH] WIP: Add hook.d support in git

This is not the best way to embed a patch in an email. There is
Documentation/SubmittingPatches in the code base, that should explain
better ways to send patches to the mailing list.

> Add a generic mechanism to find and execute one or multiple hooks found
> in $GIT_DIR/hooks/ and/or $GIT_DIR/hooks/.d/*
>
> The API is as follows:
>
> #include "hooks.h"
>
> array hooks   = find_hooks('pre-receive');
> int hooks_ran = run_hooks(hooks);
>
> The implemented behaviour is:
>
> * If we find a hooks/.d directory and the hooks.multiHook flag isn't
>   set we make use of that directory.
>
> * If we find a hooks/.d and we also have hooks/ and the
>   hooks.multiHook isn't set or set to false we don't use the hook.d
>   directory. If the hook isn't set we issue a warning to the user
>   telling him/her that we support multiple hooks via the .d directory
>   structure
>
> * If the hooks.multiHook is set to true we use the hooks/ and all
>   the entries found in hooks/.d
>
> * All the scripts are executed and fail on the first error

Maybe the above documentation should be fully embedded as comments in
"hooks.h" (or perhaps added to a new file in
"Documentation/technical/", though it looks like we prefer to embed
doc in header files these days).

> diff --git a/hooks.h b/hooks.h
> new file mode 100644
> index 0..278d63344
> --- /dev/null
> +++ b/hooks.h
> @@ -0,0 +1,35 @@
> +#ifndef HOOKS_H
> +#define HOOKS_H
> +
> +#ifndef NO_PTHREADS
> +#include 
> +#endif
> +/*
> + * Returns all the hooks found in either
> + * $GIT_DIR/hooks/$hook and/or $GIT_DIR/hooks/$hook.d/
> + *
> + * Note that this points to static storage that will be
> + * overwritten by further calls to find_hooks and run_hook_*.
> + */
> +//extern const struct string_list *find_hooks(const char *name);

The above comment is using "//" which we forbid and should probably be
removed anyway.

> +extern const char *find_hooks(const char *name);
> +
> +/* Unsure what this does/is/etc */
> +//LAST_ARG_MUST_BE_NULL

This is to make it easier for tools like compilers to check that a
function is used correctly. You should not remove such macros.

> +/*
> + * Run all the runnable hooks found in
> + * $GIT_DIR/hooks/$hook and/or $GIT_DIR/hooks/$hook.d/
> + *
> + */
> +//extern int run_hooks_le(const char *const *env, const char *name, ...);
> +//extern int run_hooks_ve(const char *const *env, const char *name,
> va_list args);

Strange that these functions are commented out.

> +#endif
> +
> +/* Workings of hooks
> + *
> + * array_of_hooks  = find_hooks(name);
> + * number_of_hooks_ran = run_hooks(array_of_hooks);
> + *
> + */

This kind of documentation should probably be at the beginning of the
file, see strbuf.h for example.

Thanks,
Christian.

Re: Feature request: hooks directory

[Wesley Schwengle]

Hi all,

I've made some progress with the hook.d implementation. It isn't
finished, as it is my first C project I'm still somewhat rocky with
how pointers and such work, but I'm getting somewhere. I haven't
broken any tests \o/.
 You have a nice testsuite btw. Feel free to comment on the code.

I've moved some of the hooks-code found in run-command.c to hooks.c

You can see the progress on gitlab: https://gitlab.com/waterkip/git
or on github: https://github.com/waterkip/git
The output of format-patch is down below.

I have some questions regarding the following two functions in run-command.c:
* run_hook_le
* run_hook_ve

What do the postfixes le and ve mean?

Cheers,
Wesley

format-patch:

>From 129d8aff8257b22210beadc155cdbcae99b0fc4b Mon Sep 17 00:00:00 2001
From: Wesley Schwengle 
Date: Sun, 2 Sep 2018 02:40:04 +0200
Subject: [PATCH] WIP: Add hook.d support in git

Add a generic mechanism to find and execute one or multiple hooks found
in $GIT_DIR/hooks/ and/or $GIT_DIR/hooks/.d/*

The API is as follows:

#include "hooks.h"

array hooks   = find_hooks('pre-receive');
int hooks_ran = run_hooks(hooks);

The implemented behaviour is:

* If we find a hooks/.d directory and the hooks.multiHook flag isn't
  set we make use of that directory.

* If we find a hooks/.d and we also have hooks/ and the
  hooks.multiHook isn't set or set to false we don't use the hook.d
  directory. If the hook isn't set we issue a warning to the user
  telling him/her that we support multiple hooks via the .d directory
  structure

* If the hooks.multiHook is set to true we use the hooks/ and all
  the entries found in hooks/.d

* All the scripts are executed and fail on the first error
---
 Makefile   |   1 +
 TODO-hooks.md  |  38 
 builtin/am.c   |   4 +-
 builtin/commit.c   |   4 +-
 builtin/receive-pack.c |  10 +--
 builtin/worktree.c |   3 +-
 cache.h|   1 +
 config.c   |   5 ++
 environment.c  |   1 +
 hooks.c| 134 +
 hooks.h|  35 +++
 run-command.c  |  36 +--
 run-command.h  |   6 --
 sequencer.c|   7 ++-
 transport.c|   3 +-
 15 files changed, 237 insertions(+), 51 deletions(-)
 create mode 100644 TODO-hooks.md
 create mode 100644 hooks.c
 create mode 100644 hooks.h

diff --git a/Makefile b/Makefile
index 5a969f583..f5eddf1d7 100644
--- a/Makefile
+++ b/Makefile
@@ -810,6 +810,7 @@ LIB_H = $(shell $(FIND) . \
  -name Documentation -prune -o \
  -name '*.h' -print)

+LIB_OBJS += hooks.o
 LIB_OBJS += abspath.o
 LIB_OBJS += advice.o
 LIB_OBJS += alias.o
diff --git a/TODO-hooks.md b/TODO-hooks.md
new file mode 100644
index 0..13b15bffb
--- /dev/null
+++ b/TODO-hooks.md
@@ -0,0 +1,38 @@
+# All hooks
+# See Documentation/githooks.txt for more information about each and every hook
+# that git knows about
+commit-msg
+fsmoninor-watchman
+p4-pre-submit
+post-applypatch
+post-checkout
+post-commit
+post-merge
+post-receive
+post-rewrite
+post-update
+pre-applypatch
+pre-auto-gc
+pre-commit
+pre-push
+pre-rebase
+pre-receive
+prepare-commit-msg
+push-to-checkout
+sendemail-validate
+update
+
+# builtin/receive-pack.c
+feed_recieve_hook
+find_hook
+find_receive_hook
+push_to_checkout_hook
+receive_hook_feed_state
+run_and_feed_hook
+run_hook_le
+run_receive_hook
+run_update_hook
+
+
+# run-command.c
+find_hook
diff --git a/builtin/am.c b/builtin/am.c
index 9f7ecf6ec..d1276dd47 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -34,6 +34,8 @@
 #include "packfile.h"
 #include "repository.h"

+#include "hooks.h"
+
 /**
  * Returns 1 if the file is empty or does not exist, 0 otherwise.
  */
@@ -509,7 +511,7 @@ static int run_applypatch_msg_hook(struct am_state *state)
 static int run_post_rewrite_hook(const struct am_state *state)
 {
  struct child_process cp = CHILD_PROCESS_INIT;
- const char *hook = find_hook("post-rewrite");
+ const char *hook = find_hooks("post-rewrite");
  int ret;

  if (!hook)
diff --git a/builtin/commit.c b/builtin/commit.c
index 0d9828e29..389224d66 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -34,6 +34,8 @@
 #include "mailmap.h"
 #include "help.h"

+#include "hooks.h"
+
 static const char * const builtin_commit_usage[] = {
  N_("git commit [] [--] ..."),
  NULL
@@ -932,7 +934,7 @@ static int prepare_to_commit(const char
*index_file, const char *prefix,
  return 0;
  }

- if (!no_verify && find_hook("pre-commit")) {
+ if (!no_verify && find_hooks("pre-commit")) {
  /*
  * Re-read the index as pre-commit hook could have updated it,
  * and write it out as a tree.  We must do this before we invoke
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index c17ce94e1..dd10ef4af 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -28,6 +28,8 @@
 #include "object-store.h"
 #include "protocol.h"

+#include "hooks.h"
+
 static const char * const receive_pack_usage[] = {
  

Re: Feature request: hooks directory

[Ævar Arnfjörð Bjarmason]

On Fri, Aug 31 2018, Wesley Schwengle wrote:

> Hop,
>
> 2018-08-30 16:45 GMT+02:00 Ævar Arnfjörð Bjarmason :
>
>>> Solution:
>>> We discussed this at work and we thought about making a .d directory
>>> for the hooks, eg.  $GIT_DIR/hooks/post-commit.d, where a user can put
>>> the post-commit hooks in. This allows us to provide post commit hooks
>>> and allows the user to add additional hooks him/herself. We could
>>> implement this in our own code base. But we were wondering if this
>>> approach could be shared with the git community and if this behavior
>>> is wanted in git itself.
>>
>> There is interest in this. This E-Mail of mine gives a good summary of
>> prior discussions about this:
>> https://public-inbox.org/git/877eqqnq22@evledraar.gmail.com/
>>
>> I.e. it's something I've personally been interested in doing in the
>> past, there's various bolt-on solutions to do it (basically local hook
>> runners) used by various projects.
>
> Thank you for the input. Do you by any chance still have that branch?
> Or would you advise me to start fresh, if so, do you have any pointers
> on where to look as I'm brand new to the git source code?

No, sorry. Start by grepping the hook names found in the githooks
manpage in the C code.

One of the things that's hard, well not hard, just tedious about this,
is that most of them are implementing their own ad-hoc way of doing
stuff. E.g. the *-receive hooks are in receive-pack.c in
run_receive_hook().

There is run_hook_le() and friends, but it's not used by everything.

So e.g. for the pre-receive hook in order to run 2 of them instead of 1
you need to untangle the state where we're feeding the hook with the
input (and potentially buffer it, not stream it), instead of doing it as
a one-off as we're doing now.

Then some hooks get nothing on stdin, some get stuff on stdin, some
produce output on stdout/stderr etc.

As a first approximation, just add a e.g. support for a pre-receive.2
hook, that gets run after pre-receive, to see what needs to be done to
run it twice.

> From the thread I've extracted three stories:
>
> 1) As a developer I want to have 'hooks.multiHooks' to enable
> multi-hook support in git
> Input is welcome for another name.

Yeah maybe we should have a setting, but FWIW I think we should just
stat() whether the hooks/$hook_name.d directory exist, and then use it,
although maybe we'll need stuff like hooks.multiHooks to give the likes
of GitLab (which already do that themselves) an upgrade path...

You can see their implementation here:
https://gitlab.com/gitlab-org/gitlab-shell/blob/master/lib/gitlab_custom_hook.rb

> 2) As a developer I want natural sort order executing for my githooks
> so I can predict executions
> See 
> https://public-inbox.org/git/CACBZZX6AYBYeb5S4nEBhYbx1r=icJ81JGYBx5=h4wacphhj...@mail.gmail.com/
> for more information

Yeah, any sane implementation of this will execute the hooks in
hooks/$hook_name.d in glob() order.

> 3) As a developer I want to run $GIT_DIR/hooks/ before
> $GIT_DIR/hooks/.d/*
> Reference: 
> https://public-inbox.org/git/cacbzzx6j6q2dun_z-pnent1u714dvnpfbrl_pieqylmczlu...@mail.gmail.com/

For e.g. GitLab the hook/pre-receive is a runner that'll run all
hook/pre-receive.d/*, so this probably makes sense to hide behind a
config setting. I think it's sensible as a default to move to to just
try to move away from hooks/ and use hook/.d/* instead.

> The following story would be.. nice to have I think. I'm not sure I
> would want to implement this from the get go as I don't have a use
> case for it.
> 4) As a developer I want a way to have a hook report an error and let
> another hook decide if we want to pass or not.
> Reference: 
> https://public-inbox.org/git/xmqq60v4don1@gitster.mtv.corp.google.com/

I think a default that makes more sense is a while ! ret = glob()
loop, i.e. a failure will do early exit. But yeah. Junio seemed to want
this to be configurable.

> 2018-08-31 5:16 GMT+02:00 Jonathan Nieder :
>> A few unrelated thoughts, to expand on this.
>>
>> Separately from that, in [1] I mentioned that I want to revamp how
>> hooks work somewhat, to avoid the attack described there (or the more
>> common attack also described there that involves a zip file).  Such a
>> revamp would be likely to also handle this multiple-hook use case.
>>
>> [1] 
>> https://public-inbox.org/git/20171002234517.gv19...@aiede.mtv.corp.google.com/
>
> The zip file attack vector doesn't change with adding a hook.d
> directory structure? If I have one file or multiple files, the attack
> stays the same?
> I think I'm asking if this would be a show stopper for the feature.

Yeah I don't see how what Jonathan's talking about there has any
relevance to whether we run 1 or 100 hooks.

Re: Feature request: hooks directory

[Wesley Schwengle]

Hop,

2018-08-30 16:45 GMT+02:00 Ævar Arnfjörð Bjarmason :

>> Solution:
>> We discussed this at work and we thought about making a .d directory
>> for the hooks, eg.  $GIT_DIR/hooks/post-commit.d, where a user can put
>> the post-commit hooks in. This allows us to provide post commit hooks
>> and allows the user to add additional hooks him/herself. We could
>> implement this in our own code base. But we were wondering if this
>> approach could be shared with the git community and if this behavior
>> is wanted in git itself.
>
> There is interest in this. This E-Mail of mine gives a good summary of
> prior discussions about this:
> https://public-inbox.org/git/877eqqnq22@evledraar.gmail.com/
>
> I.e. it's something I've personally been interested in doing in the
> past, there's various bolt-on solutions to do it (basically local hook
> runners) used by various projects.

Thank you for the input. Do you by any chance still have that branch?
Or would you advise me to start fresh, if so, do you have any pointers
on where to look as I'm brand new to the git source code?

>From the thread I've extracted three stories:

1) As a developer I want to have 'hooks.multiHooks' to enable
multi-hook support in git
Input is welcome for another name.

2) As a developer I want natural sort order executing for my githooks
so I can predict executions
See 
https://public-inbox.org/git/CACBZZX6AYBYeb5S4nEBhYbx1r=icJ81JGYBx5=h4wacphhj...@mail.gmail.com/
for more information

3) As a developer I want to run $GIT_DIR/hooks/ before
$GIT_DIR/hooks/.d/*
Reference: 
https://public-inbox.org/git/cacbzzx6j6q2dun_z-pnent1u714dvnpfbrl_pieqylmczlu...@mail.gmail.com/

The following story would be.. nice to have I think. I'm not sure I
would want to implement this from the get go as I don't have a use
case for it.
4) As a developer I want a way to have a hook report an error and let
another hook decide if we want to pass or not.
Reference: 
https://public-inbox.org/git/xmqq60v4don1@gitster.mtv.corp.google.com/


2018-08-31 5:16 GMT+02:00 Jonathan Nieder :
> A few unrelated thoughts, to expand on this.
>
> Separately from that, in [1] I mentioned that I want to revamp how
> hooks work somewhat, to avoid the attack described there (or the more
> common attack also described there that involves a zip file).  Such a
> revamp would be likely to also handle this multiple-hook use case.
>
> [1] 
> https://public-inbox.org/git/20171002234517.gv19...@aiede.mtv.corp.google.com/

The zip file attack vector doesn't change with adding a hook.d
directory structure? If I have one file or multiple files, the attack
stays the same?
I think I'm asking if this would be a show stopper for the feature.


Cheers,
Wesley

-- 
Wesley Schwengle, Developer
Mintlab B.V., https://www.zaaksysteem.nl
E: wes...@mintlab.nl
T:  +31 20 737 00 05

Re: Feature request: hooks directory

[Jonathan Nieder]

Ævar Arnfjörð Bjarmason wrote:

> There is interest in this. This E-Mail of mine gives a good summary of
> prior discussions about this:
> https://public-inbox.org/git/877eqqnq22@evledraar.gmail.com/
>
> I.e. it's something I've personally been interested in doing in the
> past, there's various bolt-on solutions to do it (basically local hook
> runners) used by various projects.

A few unrelated thoughts, to expand on this.

Reports of experience from using local hook runners would be very
welcome so we can benefit from their good ideas and avoid their bad
ones.  That was part of the motivation for not building this in for so
long: we want people to experiment so that the result can be something
that works well for a lot of people.

Separately from that, in [1] I mentioned that I want to revamp how
hooks work somewhat, to avoid the attack described there (or the more
common attack also described there that involves a zip file).  Such a
revamp would be likely to also handle this multiple-hook use case.

As a word of caution, today we support having multiple credential
helpers in use and it's a nightmare to support.  The layering model is
complicated and users don't understand it.  So we might want to try to
avoid whatever went wrong there. ;-)

Thanks,
Jonathan

[1] 
https://public-inbox.org/git/20171002234517.gv19...@aiede.mtv.corp.google.com/

Re: feature request: allow commit.email config setting

[Rasmus Villemoes]

On 2018-08-30 20:13, Eric Sunshine wrote:
> On Thu, Aug 30, 2018 at 7:26 AM Rasmus Villemoes  
> wrote:
>> I can set GIT_COMMITTER_EMAIL in the environment, but that is
>> rather inconvenient, since that means I have to remember to do that in
>> the shell I'm using for that particular project, and I can't use that
>> shell for other projects. So it would be really nice if I could set
>> commit.email = $private-email in the local .git/config for that
>> particular project.
> 
> Aside from modifying Git itself to support such a use-case, another
> (perhaps more pragmatic) approach would be to use a tool, such as
> direnv[1], which automatically sets environment variables for you
> depending upon your current working directory, or just use some ad-hoc
> shell programming to achieve the same (for instance, [2]).

Thanks for the hint! I've actually had "git" as a function in my .bashrc
for a long time, for implementing a ~/.githistory to help remember the
sometimes rather complex git invocations, and keeping track of the
context ($cwd, current branch, etc.) they were used in. It should be
trivial to hook the environment settings based on $cwd into that. The
only problem is that that gives me much less incentive to work on
implementing the config support in git, but if I'm the only one with a
use case, that's probably just as well.

Rasmus

Re: feature request: allow commit.email config setting

[Eric Sunshine]

On Thu, Aug 30, 2018 at 7:26 AM Rasmus Villemoes  
wrote:
> I can set GIT_COMMITTER_EMAIL in the environment, but that is
> rather inconvenient, since that means I have to remember to do that in
> the shell I'm using for that particular project, and I can't use that
> shell for other projects. So it would be really nice if I could set
> commit.email = $private-email in the local .git/config for that
> particular project.

Aside from modifying Git itself to support such a use-case, another
(perhaps more pragmatic) approach would be to use a tool, such as
direnv[1], which automatically sets environment variables for you
depending upon your current working directory, or just use some ad-hoc
shell programming to achieve the same (for instance, [2]).

[1]: https://direnv.net
[2]: 
https://stackoverflow.com/questions/14462591/set-environmental-variables-in-a-particular-directory

Re: feature request: allow commit.email config setting

[Junio C Hamano]

Rasmus Villemoes  writes:

> ... I can set GIT_COMMITTER_EMAIL in the environment, but that is
> rather inconvenient, since that means I have to remember to do that in
> the shell I'm using for that particular project, and I can't use that
> shell for other projects.

We only have user.email and user.name because nobody in the past 10+
years had such a requirement, but I find it it a perfectly sensible
thing to wish to say "tagger.email and tagger.name are used while
creating an annotated tag, committer.email and committer.name are
used on the 'committer' line and author.email and author.name are
used on the 'author' line in a newly created commit; by the way, if
any of these are not set, but user.email or user.name is set, then
they are used as fallback values." at the design level.

Re: Feature request: hooks directory

[Ævar Arnfjörð Bjarmason]

On Thu, Aug 30 2018, Wesley Schwengle wrote:

> Hello all,
>
> I would like to ask if it is worth my time looking into the following
> solution to a problem we have at work.
>
> Problem:
> We want to have some git-hooks and we want to provide them to the
> user. In a most recent example we have a post-checkout hook that deals
> with some Docker things. However, if we update that post-checkout hook
> my local overrides in that post-checkout hook are going to be
> overwritten.
>
> Solution:
> We discussed this at work and we thought about making a .d directory
> for the hooks, eg.  $GIT_DIR/hooks/post-commit.d, where a user can put
> the post-commit hooks in. This allows us to provide post commit hooks
> and allows the user to add additional hooks him/herself. We could
> implement this in our own code base. But we were wondering if this
> approach could be shared with the git community and if this behavior
> is wanted in git itself.

There is interest in this. This E-Mail of mine gives a good summary of
prior discussions about this:
https://public-inbox.org/git/877eqqnq22@evledraar.gmail.com/

I.e. it's something I've personally been interested in doing in the
past, there's various bolt-on solutions to do it (basically local hook
runners) used by various projects.

Re: Feature request: be able to pass arguments to difftool command

[H.Merijn Brand]

On Tue, 28 Aug 2018 12:37:40 -0700, Junio C Hamano 
wrote:

> "H.Merijn Brand"  writes:
> 
> > So, my wish would be to have an option, possibly using -- to pass
> > additional command line arguments to git difftool, so that
> >
> >  $ git difftool $commit~1..$commit -- -m -v2
> >
> > would pass the arguments after -- transparantly to ccdiff (in my case)  
> 
> At the syntax level passing any option after "--" would be a no
> starter, as I would imagine that "git difftool $revs -- $paths"
> should still be supported.
> 
> At the concept level, however, I can see why such a feature would be
> useful.  Perhaps
> 
> $ git difftool --backend-option=-m --backend-option=-v2 HEAD
> $ git mergetool --backend-option=--foo

This would mean I can just pass remaining arguments, like this?

--8<--- ~/bin/git-ccdiff
#!/usr/bin/env perl
use 5.18.3;
use warnings;

my $commit;

@ARGV && $ARGV[0] !~ m/^-/ and $commit = shift;

my @git = qw( git difftool );
defined $commit and push @git, "$commit~1..$commit";
system @git, @ARGV;
-->8---

> with appropriate way(s) [*1*] to make it easier to type (and
> implement) would be an acceptable avenue to pursue, I wonder?

I like it, as long as they are all separate options in the backend and
not available in one single variable that needs to be split

I can envision a configure variable like

  backends.options.separator = U+2063

so the backend can safely split on that itself. But I also see this as
overly complex en over-engineering

> [Footnote]
> 
> *1* There are various possible ways, not all of them are mutually
> incompatible.
> 
> a. Give a short-form synonym, e.g. -X, to "--backend-option";

I like it

> b. Assume that backend option always begins with a dash and add
>one when missing, e.g. -Xm becomes --backend-option=-m

I guess not: there might be tools that do not work like that, e.g.
xfreerdp changed all their rememberable and logic options to the weird
stupid syntax they use now, including mixing -, -- and +

 rdesktop -u user -p - -g 1280x1024 -a 16 -r clipboard:CLIPBOARD host

->

 xfreerdp -u user --from-stdin -g 1280x1024 -a 16 --plugin clipbrd host

->

 xfreerdp /u:user /from-stdin /size:1280x1024 /bpp:16 +clipboard /v:host

> c. Allow giving multiple backend options on a single option and
>split at whitespace, e.g. --backend-option="-m -v2"

That is the weak part in my workaround, as it will break on options like

  --backend-option='--config="/path/to/My Configuration/My Application"'

> d. Allow difftool.$toolname.opts configuration variable that is
>multi-valued, so you can say
> 
>   git -c difftool.ccdiff.opts=-v2 -c difftool.ccdiff.opts=-m difftool

Hmm, maybe harder to explain, but why not

>(of course, not necessarily from the command line but the
>point is you could configure it)
> 
> Some of these (e.g. b, c) may not be desirable, though.


-- 
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.29   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/


pgpNDoJZUsEJo.pgp
Description: OpenPGP digital signature

Re: Feature request: be able to pass arguments to difftool command

[Junio C Hamano]

"H.Merijn Brand"  writes:

> So, my wish would be to have an option, possibly using -- to pass
> additional command line arguments to git difftool, so that
>
>  $ git difftool $commit~1..$commit -- -m -v2
>
> would pass the arguments after -- transparantly to ccdiff (in my case)

At the syntax level passing any option after "--" would be a no
starter, as I would imagine that "git difftool $revs -- $paths"
should still be supported.

At the concept level, however, I can see why such a feature would be
useful.  Perhaps

$ git difftool --backend-option=-m --backend-option=-v2 HEAD
$ git mergetool --backend-option=--foo

with appropriate way(s) [*1*] to make it easier to type (and
implement) would be an acceptable avenue to pursue, I wonder?


[Footnote]

*1* There are various possible ways, not all of them are mutually
incompatible.

a. Give a short-form synonym, e.g. -X, to "--backend-option";

b. Assume that backend option always begins with a dash and add
   one when missing, e.g. -Xm becomes --backend-option=-m

c. Allow giving multiple backend options on a single option and
   split at whitespace, e.g. --backend-option="-m -v2"

d. Allow difftool.$toolname.opts configuration variable that is
   multi-valued, so you can say

git -c difftool.ccdiff.opts=-v2 -c difftool.ccdiff.opts=-m difftool

   (of course, not necessarily from the command line but the
   point is you could configure it)

Some of these (e.g. b, c) may not be desirable, though.

Re: Feature request : "git fsck" should show the percentage of completeness in step "Checking connectivity:"

[Jeff King]

On Sun, Jul 01, 2018 at 06:21:40PM +0200, Toralf Förster wrote:

> as "git fsck" does it already for "Checking objects:"
> 
> Is this a valid feature request?

It's actually hard to do accurately. We don't know how many objects are
reachable until we traverse the graph...which is exactly what the
"checking connectivity" operation is doing.

The operation is bounded by the total number of objects in the
repository. We may have duplicates (in multiple packs, or loose/packed),
and objects which aren't reachable at all. But we could make that a
guess, and just "jump" to 100% at the end.

The code might look something like the patch below. I'm not sure if it's
a good idea or not (I mostly copied the counting from
builtin/count-objects.c; it might be nice to factor that out).

-Peff

diff --git a/builtin/fsck.c b/builtin/fsck.c
index 3ad4f160f9..52e79aed76 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -192,17 +192,49 @@ static int traverse_one_object(struct object *obj)
return result;
 }
 
+static int count_loose(const struct object_id *oid, const char *path,
+  void *data)
+{
+   unsigned int *nr = data;
+   nr++;
+   return 0;
+}
+
+static unsigned object_max(void)
+{
+   unsigned max = 0;
+   struct packed_git *p;
+
+   for_each_loose_object(count_loose, , 0);
+
+   for (p = get_packed_git(the_repository); p; p = p->next) {
+   if (open_pack_index(p))
+   continue;
+   max += p->num_objects;
+   }
+
+   return max;
+}
+
 static int traverse_reachable(void)
 {
struct progress *progress = NULL;
unsigned int nr = 0;
int result = 0;
-   if (show_progress)
-   progress = start_delayed_progress(_("Checking connectivity"), 
0);
+   unsigned int max = 0;
+
+   if (show_progress) {
+   max = object_max();
+   progress = start_delayed_progress(_("Checking connectivity"),
+ max);
+   }
+
while (pending.nr) {
result |= traverse_one_object(object_array_pop());
display_progress(progress, ++nr);
}
+
+   display_progress(progress, max);
stop_progress();
return !!result;
 }

Re: Feature request : "git fsck" should show the percentage of completeness in step "Checking connectivity:"

[Stefan Beller]

On Sun, Jul 1, 2018 at 9:22 AM Toralf Förster  wrote:
>
> as "git fsck" does it already for "Checking objects:"
>
> Is this a valid feature request?

Yes it is. However it is most likely to have the feature incorporated if
it comes in form of a patch.

So clone one of the git.git repositories found at
https://git-blame.blogspot.com/p/git-public-repositories.html
and have a look builtin/fsck.c (Search for "Checking connectivity")
as well as how the progress.{h, c} for its API if needed.

I am not sure if this is an easy thing to add, as knowing the number
of objects before the walk might be hard. How does "Checking objects"
solve that issue?

See Documentation/SubmittingPatches once you have some code
that can be a starter of a discussion. :)

Thanks,
Stefan

Re: Feature Request: option for git difftool to show changes in submodule contents

[Stefan Beller]

Hi Oshaben!

On Mon, Apr 23, 2018 at 7:49 AM, Oshaben Nicholas
 wrote:
> Hello,
>
> A coworker of mine was trying to use git difftool in a repository with 
> submodules and we found that it only shows the change in the subproject 
> commit hash. The option to show the changes in the contents of the submodules 
> exists for git diff. Can this be added to difftool as well?

Yes, of course it can be added. Care to write a patch?

See lines 432-443 in builtin/difftool.c:
https://github.com/git/git/blob/master/builtin/difftool.c#L432

I'd think you'd want to compute some output
(Similar to the git-diff output? Then we could just
refactor the submodule diff stuff to be reusable here)
and put it into the strbuf there.

Feel free to ask away or read the docs Documentation/SubmittingPatches

Thanks,
Stefan

Re: Feature Request: Add diff.word-diff and perhaps diff.word-diff-regex configuration options to enable always using word-diffs in git diff

[Junio C Hamano]

Ævar Arnfjörð Bjarmason  writes:

> On Sat, Apr 14 2018, Doron Behar wrote:
>
>> I've just came across the wonderful command line option for `git diff`:
>> `--word-diff`. It could be great to have a configuration option that
>> will enable this feature by default when running `git diff`.
>
> Do you know you can do:
>
> git config --global alias.wdiff "diff --word-diff"

Correct, but it is a "you could instead do it this way" that is not
accompanied by a "you do not want to do what you said you want to
because.." answer.  Having the latter is often helpful to learn why
the suggestion is actually not a mere "you could" but is a "you are
better off doing it this way".

Even though it is discouraged, people script using the Porcelain
"git diff" command, and once users of such a configuration variable
is used in Doron's fork of Git, those scripts will break for them.

Using alias like you showed won't have such a problem.

Re: Feature Request: Add diff.word-diff and perhaps diff.word-diff-regex configuration options to enable always using word-diffs in git diff

[Ævar Arnfjörð Bjarmason]

On Sat, Apr 14 2018, Doron Behar wrote:

> I've just came across the wonderful command line option for `git diff`:
> `--word-diff`. It could be great to have a configuration option that
> will enable this feature by default when running `git diff`.

Do you know you can do:

git config --global alias.wdiff "diff --word-diff"

?

Re: feature-request: git "cp" like there is git mv.

[Junio C Hamano]

Stefan Moch  writes:

> Are such redundant checks in general a pattern worth searching
> for and cleaning up globally? Or is this rather in the category
> of cleaning up only when noticed?

A clean-up patch that is otherwise a no-op is still welcome as it
will improve the health of the codebase, but they become hindrances
if there are too many of them to consume the review bandwidth that
would otherwise be better spent on other non no-op topics, and/or if
they add too many merge conflicts with other non no-op topics in
flight.

The amount of such negative impact a no-op clean-up patch can have
on the project does not depend on how the issue was discovered, so
we do not even have to know if the issue was discovered by actively
hunting or by noticing while working on a near-by area.

It is possible that by actively looking for, you may end up
producing more of the no-op clean-up patches and can more easily
interfere with other topics, which we may need to discourge or at
least ask you to slow down.  On the other hand, issues discovered
while working on a near-by area would typically not increase
conflicts with other topics in flight over the conflicts that would
be caused by that real work you were doing in a near-by area
already, so in that sense, "only when noticed" is a practical way to
avoid the clean-up fatigue.

Re: feature-request: git "cp" like there is git mv.

[Stefan Moch]

* Junio C Hamano  [2018-02-07T11:49:39-0800]:
> Stefan Moch  writes:
> 
> > * Jonathan Nieder  [2017-12-15T17:31:30-0800]:  
> >> This sounds like a reasonable thing to add.  See builtin/mv.c for
> >> how "git mv" works if you're looking for inspiration.
> >> 
> >> cmd_mv in that file looks rather long, so I'd also be happy if
> >> someone interested refactors to break it into multiple
> >> self-contained pieces for easier reading (git mostly follows
> >> https://www.kernel.org/doc/html/latest/process/coding-style.html#functions).
> >>   
> >
> > I looked at builtin/mv.c and have a rough idea how to split it
> > up to support both mv and cp commands.
> >
> > But first I noticed and removed a redundant check in cmd_mv,
> > also added a test case to check if mv --dry-run does not move
> > the file.  
> 
> I guess these two patches went unnoticed when posted at the end of
> last year.  Reading them again, I think they are good changes.

Thanks.

Are such redundant checks in general a pattern worth searching
for and cleaning up globally? Or is this rather in the category
of cleaning up only when noticed?


> As a no-op clean-up of a127331c ("mv: allow moving nested
> submodules", 2016-04-19), the attached would also make sense, I
> would think.
> 
> Thanks.
> 
>  builtin/mv.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/builtin/mv.c b/builtin/mv.c
> index 9662804d23..9cb07990fd 100644
> --- a/builtin/mv.c
> +++ b/builtin/mv.c
> @@ -266,10 +266,11 @@ int cmd_mv(int argc, const char **argv, const
> char *prefix) const char *src = source[i], *dst = destination[i];
>   enum update_mode mode = modes[i];
>   int pos;
> - if (show_only || verbose)
> - printf(_("Renaming %s to %s\n"), src, dst);
> - if (show_only)
> + if (show_only) {
> + if (verbose)
> + printf(_("Renaming %s to %s\n"),
> src, dst); continue;
> + }
>   if (mode != INDEX && rename(src, dst) < 0) {
>   if (ignore_errors)
>   continue;
> 

As Stefan Beller already noted, this changes the printing
behavior:


See also the output of

git mv -n
git mv -n -v
git mv -v


without your patch:

$ git mv -n 1 2
Checking rename of '1' to '2'
Renaming 1 to 2
$ git mv -n -v 1 2
Checking rename of '1' to '2'
Renaming 1 to 2
$ git mv -v 1 2
Renaming 1 to 2


and with your patch:

$ git mv -n 1 2
Checking rename of '1' to '2'
$ git mv -n -v 1 2
Checking rename of '1' to '2'
Renaming 1 to 2
$ git mv -v 1 2


Having different outputs of “git mv -n” and “git mv -n -v” seems
odd, but not necessarily wrong. However, “git mv -v” with no
output at all, does not what the documentation says:

   -v, --verbose
   Report the names of files as they are moved.

Re: [Feature request] Add config option to gpgsign IFF key is present

[Joshua Nelson]

I like having machine-specific config in ~/.config/git, I think I'll do that. I 
didn't realize you could forward gpg-agent over a connection, I may look 
further into that.

Thanks for the help!

Joshua Nelson

On Sunday, March 11, 2018 17:21:42 EDT brian m. carlson wrote:
> On Sat, Mar 10, 2018 at 03:28:43PM +, NELSON, JOSHUA Y wrote:
> > Currently, `commit.gpgsign` allows you to give either 'true' or 'false' as
> > a value. If the key is not present, commits will fail:
> > 
> > ```sh
> > $ git commit -m "example"
> > error: gpg failed to sign the data
> > fatal: failed to write commit object
> > ```
> > 
> > I like to reuse my config file across several machines, some of which do
> > not have my GPG key. Would it be possible to add an option to sign the
> > commit only if the private key for `user.signingkey` is present? It could
> > be named something like `commit.gpgsign=default-yes`.
> Unfortunately, this isn't always possible.  You can forward the Unix
> socket for the agent over an SSH connection, at which point the remote
> machine has the ability to sign, but the gpg client doesn't list those
> as existing secret keys in its output (because technically, those keys
> don't exist on the remote system).  I use this technique at work, for
> example, to sign things on my development VM.
> 
> It might be possible to make the failure of the signing operation not be
> fatal in this case, although that could cause people to fail to sign due
> to transient failures even when the key is present on the system.
> 
> I usually handle this by storing my main configuration in ~/.gitconfig
> and on machines where I have a key, additionally having a
> ~/.config/git/config file that contains the commit.gpgsign entry.
> --
> brian m. carlson / brian with sandals: Houston, Texas, US
> https://www.crustytoothpaste.net/~bmc | My opinion only
> OpenPGP: https://keybase.io/bk2204


signature.asc
Description: This is a digitally signed message part.

Re: [Feature request] Add config option to gpgsign IFF key is present

[brian m. carlson]

On Sat, Mar 10, 2018 at 03:28:43PM +, NELSON, JOSHUA Y wrote:
> Currently, `commit.gpgsign` allows you to give either 'true' or 'false' as a 
> value. If the key is not present, commits will fail:
> 
> ```sh
> $ git commit -m "example"
> error: gpg failed to sign the data
> fatal: failed to write commit object
> ```
> 
> I like to reuse my config file across several machines, some of which do not 
> have my GPG key. Would it be possible to add an option to sign the commit 
> only if the private key for `user.signingkey` is present? It could be named 
> something like `commit.gpgsign=default-yes`.

Unfortunately, this isn't always possible.  You can forward the Unix
socket for the agent over an SSH connection, at which point the remote
machine has the ability to sign, but the gpg client doesn't list those
as existing secret keys in its output (because technically, those keys
don't exist on the remote system).  I use this technique at work, for
example, to sign things on my development VM.

It might be possible to make the failure of the signing operation not be
fatal in this case, although that could cause people to fail to sign due
to transient failures even when the key is present on the system.

I usually handle this by storing my main configuration in ~/.gitconfig
and on machines where I have a key, additionally having a
~/.config/git/config file that contains the commit.gpgsign entry.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Re: feature request: git-config: Add conditional include for gitbranch

[Duy Nguyen]

On Thu, Mar 08, 2018 at 07:23:00PM -0500, Jeremy Bicha wrote:
> Use Case
> ==
> Jeremy is a developer for Debian and Ubuntu. The same repository is
> used for both Debian and Ubuntu packaging but with different branches.
> For commits to the debian/master branch, Jeremy wants to use his
> @debian.org email address. For commits to the ubuntu/master branch,
> Jeremy wants to use his @ubuntu.com email.
> 
> Proposal
> ===
> The includeIf feature of git-config could be extended to offer a
> gitbranch conditional include in addition to the gitdir conditional
> include it already offers.

Interesting. It looks quite simple to do this. My prototype looks like
this.

-- 8< --
Subject: [PATCH] config: support conditional include by matching ref pattern

Signed-off-by: Nguyễn Thái Ngọc Duy 
---
 Documentation/config.txt  | 12 
 config.c  | 30 ++
 t/t1305-config-include.sh | 26 ++
 3 files changed, 68 insertions(+)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index ce9102cea8..4e8fb6d99c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -143,6 +143,18 @@ refer to linkgit:gitignore[5] for details. For convenience:
This is the same as `gitdir` except that matching is done
case-insensitively (e.g. on case-insensitive file sytems)
 
+`ref`::
+   The data that follows the keyword `ref:` is used as a glob
+   pattern that matches against the current branch. `*` in the
+   pattern does not match `/` and `**` matches multiple levels,
+   the same as .gitignore syntax. The branch is a full reference
+   (i.e. with `refs/heads/` prefix). If HEAD is detached, the
+   pattern will be matched against the value "HEAD".
+
+`ref/i`::
+   This is the same as `ref` except that matching is done
+   case-insensitively
+
 A few more notes on matching via `gitdir` and `gitdir/i`:
 
  * Symlinks in `$GIT_DIR` are not resolved before matching.
diff --git a/config.c b/config.c
index b0c20e6cb8..72ff2da667 100644
--- a/config.c
+++ b/config.c
@@ -16,6 +16,7 @@
 #include "string-list.h"
 #include "utf8.h"
 #include "dir.h"
+#include "refs.h"
 
 struct config_source {
struct config_source *prev;
@@ -202,6 +203,31 @@ static int prepare_include_condition_pattern(struct strbuf 
*pat)
return prefix;
 }
 
+static int include_by_ref(const struct config_options *opts,
+ const char *cond, size_t cond_len, int icase)
+{
+   struct strbuf pattern = STRBUF_INIT;
+   char *branch;
+   unsigned flags = WM_PATHNAME;
+   int ret;
+
+   if (!opts->git_dir)
+   return 0;
+
+   branch = resolve_refdup("HEAD", 0, NULL, NULL);
+   if (!branch)
+   return 0;
+
+   if (icase)
+   flags |= WM_CASEFOLD;
+   strbuf_add(,  cond, cond_len);
+   ret = !wildmatch(pattern.buf, branch, flags);
+
+   free(branch);
+   strbuf_release();
+   return ret;
+}
+
 static int include_by_gitdir(const struct config_options *opts,
 const char *cond, size_t cond_len, int icase)
 {
@@ -268,6 +294,10 @@ static int include_condition_is_true(const struct 
config_options *opts,
return include_by_gitdir(opts, cond, cond_len, 0);
else if (skip_prefix_mem(cond, cond_len, "gitdir/i:", , _len))
return include_by_gitdir(opts, cond, cond_len, 1);
+   else if (skip_prefix_mem(cond, cond_len, "ref:", , _len))
+   return include_by_ref(opts, cond, cond_len, 0);
+   else if (skip_prefix_mem(cond, cond_len, "ref/i:", , _len))
+   return include_by_ref(opts, cond, cond_len, 1);
 
/* unknown conditionals are always false */
return 0;
diff --git a/t/t1305-config-include.sh b/t/t1305-config-include.sh
index d9d2f545a4..27ecfc74b7 100755
--- a/t/t1305-config-include.sh
+++ b/t/t1305-config-include.sh
@@ -296,6 +296,32 @@ test_expect_success SYMLINKS 'conditional include, gitdir 
matching symlink, icas
)
 '
 
+test_expect_success 'conditional include by refs' '
+   git init inc-by-ref &&
+   (
+   check() {
+   echo "ref: $1" >.git/HEAD &&
+   echo "[includeIf \"ref:$2\"]path=bar8" >.git/config &&
+   git config test.var >actual &&
+   test_cmp expect actual
+   }
+   cd inc-by-ref &&
+   echo "[test]var=matched" >.git/bar8 &&
+   echo matched >expect &&
+
+   check refs/heads/foo refs/heads/foo &&
+   check refs/heads/foo "refs/heads/*" &&
+   check refs/heads/foo "refs/heads/f*" &&
+   check refs/heads/deep/in/foo "refs/heads/**/foo" &&
+
+   test_commit one &&
+   git checkout --detach &&
+   echo "[includeIf \"ref:HEAD\"]path=bar8" 

Re: feature-request: git "cp" like there is git mv.

[Stefan Beller]

On Wed, Feb 7, 2018 at 11:49 AM, Junio C Hamano  wrote:
> Stefan Moch  writes:
>
>> * Jonathan Nieder  [2017-12-15T17:31:30-0800]:
>>> This sounds like a reasonable thing to add.  See builtin/mv.c for how
>>> "git mv" works if you're looking for inspiration.
>>>
>>> cmd_mv in that file looks rather long, so I'd also be happy if someone
>>> interested refactors to break it into multiple self-contained pieces
>>> for easier reading (git mostly follows
>>> https://www.kernel.org/doc/html/latest/process/coding-style.html#functions).
>>
>> I looked at builtin/mv.c and have a rough idea how to split it
>> up to support both mv and cp commands.
>>
>> But first I noticed and removed a redundant check in cmd_mv,
>> also added a test case to check if mv --dry-run does not move
>> the file.
>
> I guess these two patches went unnoticed when posted at the end of
> last year.  Reading them again, I think they are good changes.
>
> As a no-op clean-up of a127331c ("mv: allow moving nested
> submodules", 2016-04-19), the attached would also make sense, I
> would think.
>
> Thanks.
>
>  builtin/mv.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/builtin/mv.c b/builtin/mv.c
> index 9662804d23..9cb07990fd 100644
> --- a/builtin/mv.c
> +++ b/builtin/mv.c
> @@ -266,10 +266,11 @@ int cmd_mv(int argc, const char **argv, const char 
> *prefix)
> const char *src = source[i], *dst = destination[i];
> enum update_mode mode = modes[i];
> int pos;
> -   if (show_only || verbose)
> -   printf(_("Renaming %s to %s\n"), src, dst);
> -   if (show_only)
> +   if (show_only) {
> +   if (verbose)
> +   printf(_("Renaming %s to %s\n"), src, dst);
> continue;
> +   }

This is actually changing behavior to

if (show_only && verbose)
print(...)

if show_only
continue

The second part is already there as is, only the printing behavior
actually changes.

So I might be missing the obvious here for the claim of no-op?

Looking up further we have (line 177):

if (show_only)
printf(_("Checking rename of '%s' to '%s'\n"), src, dst);

which prints regardless of verbosity.

Re: feature-request: git "cp" like there is git mv.

[Junio C Hamano]

Stefan Moch  writes:

> * Jonathan Nieder  [2017-12-15T17:31:30-0800]:
>> This sounds like a reasonable thing to add.  See builtin/mv.c for how
>> "git mv" works if you're looking for inspiration.
>> 
>> cmd_mv in that file looks rather long, so I'd also be happy if someone
>> interested refactors to break it into multiple self-contained pieces
>> for easier reading (git mostly follows
>> https://www.kernel.org/doc/html/latest/process/coding-style.html#functions).
>
> I looked at builtin/mv.c and have a rough idea how to split it
> up to support both mv and cp commands.
>
> But first I noticed and removed a redundant check in cmd_mv,
> also added a test case to check if mv --dry-run does not move
> the file.

I guess these two patches went unnoticed when posted at the end of
last year.  Reading them again, I think they are good changes.

As a no-op clean-up of a127331c ("mv: allow moving nested
submodules", 2016-04-19), the attached would also make sense, I
would think.

Thanks.

 builtin/mv.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/builtin/mv.c b/builtin/mv.c
index 9662804d23..9cb07990fd 100644
--- a/builtin/mv.c
+++ b/builtin/mv.c
@@ -266,10 +266,11 @@ int cmd_mv(int argc, const char **argv, const char 
*prefix)
const char *src = source[i], *dst = destination[i];
enum update_mode mode = modes[i];
int pos;
-   if (show_only || verbose)
-   printf(_("Renaming %s to %s\n"), src, dst);
-   if (show_only)
+   if (show_only) {
+   if (verbose)
+   printf(_("Renaming %s to %s\n"), src, dst);
continue;
+   }
if (mode != INDEX && rename(src, dst) < 0) {
if (ignore_errors)
continue;

Re: Feature request: Improve diff algorithm

[Stefan Beller]

On Sat, Jan 27, 2018 at 5:08 AM, KES  wrote:
> One yet more:
>
> @@ -43,22 +44,25 @@ sub tariff_title {
>  1;
>
>  __DATA__
> -@@ control/tariff.css
> -* {
> -margin: 0;
> -padding: 0;
> -border: 0;
> --webkit-box-sizing: border-box;
> -box-sizing: border-box; }
> -html {
> -background-color: #121212;
> -color: white;
> -font-family: 'Roboto', 'Arial',  sans-serif;
> -font-size: 16px; }
> -a {
> -cursor: pointer; }
>
>
> +@@ control/tariff_about_old.html.ep
> +
> +  
> +
> +<%= $title %>
> +  
> +  
> +<%== $option1 %><%= stash->{ comment1 }? " (" .stash->{ 
> comment1 }.")": '' %> +
> +  
> +  
> +
> +<%== $option2 %><%= stash->{ comment2 }? " (" .stash->{ 
> comment2 }.")": '' %> +  
> +
> +
> +@@ control/tariff.css
>  /*  BASE BUTTON FOR TARIFF CARD  */
>  .button {
>display: -webkit-box;
>
> But it would be better if `@@ control/tariff.css` were untouched:
>
> @@ -43,22 +44,25 @@ sub tariff_title {
>  1;
>
>  __DATA__
> +
> +
> +@@ control/tariff_about_old.html.ep
> +
> +  
> +
> +<%= $title %>
> +  
> +  
> +<%== $option1 %><%= stash->{ comment1 }? " (" .stash->{ 
> comment1 }.")": '' %> +
> +  
> +  
> +
> +<%== $option2 %><%= stash->{ comment2 }? " (" .stash->{ 
> comment2 }.")": '' %> +  
> +
> +
>  @@ control/tariff.css
> -* {
> -margin: 0;
> -padding: 0;
> -border: 0;
> --webkit-box-sizing: border-box;
> -box-sizing: border-box; }
> -html {
> -background-color: #121212;
> -color: white;
> -font-family: 'Roboto', 'Arial',  sans-serif;
> -font-size: 16px; }
> -a {
> -cursor: pointer; }
> -
> -
>  /*  BASE BUTTON FOR TARIFF CARD  */
>  .button {
>display: -webkit-box;
>

Try the new option that Jonathan Tan implemented:

  git diff --anchor="@@ control/tariff.css"

to produce the second diff.

I wonder if we want to have a permanent store for these
lines in given diffs, such that you only have to figure it out once.
(And eventually the community will have a corpus of data to
figure out how to improve the diff for real)

Re: Feature request: Improve diff algorithm

[KES]

One yet more:

@@ -43,22 +44,25 @@ sub tariff_title {
 1;
 
 __DATA__
-@@ control/tariff.css
-* {
-margin: 0;
-padding: 0;
-border: 0;
--webkit-box-sizing: border-box;
-box-sizing: border-box; }
-html {
-background-color: #121212;
-color: white;
-font-family: 'Roboto', 'Arial',  sans-serif;
-font-size: 16px; }
-a {
-cursor: pointer; }
 
 
+@@ control/tariff_about_old.html.ep
+
+  
+
+<%= $title %>
+  
+  
+<%== $option1 %><%= stash->{ comment1 }? " (" .stash->{ comment1 
}.")": '' %>
+  
+  
+
+<%== $option2 %><%= stash->{ comment2 }? " (" .stash->{ comment2 
}.")": '' %>
+
+
+@@ control/tariff.css
 /*  BASE BUTTON FOR TARIFF CARD  */
 .button {
   display: -webkit-box;

But it would be better if `@@ control/tariff.css` were untouched:

@@ -43,22 +44,25 @@ sub tariff_title {
 1;
 
 __DATA__
+
+
+@@ control/tariff_about_old.html.ep
+
+  
+
+<%= $title %>
+  
+  
+<%== $option1 %><%= stash->{ comment1 }? " (" .stash->{ comment1 
}.")": '' %>
+  
+  
+
+<%== $option2 %><%= stash->{ comment2 }? " (" .stash->{ comment2 
}.")": '' %>
+
+
 @@ control/tariff.css
-* {
-margin: 0;
-padding: 0;
-border: 0;
--webkit-box-sizing: border-box;
-box-sizing: border-box; }
-html {
-background-color: #121212;
-color: white;
-font-family: 'Roboto', 'Arial',  sans-serif;
-font-size: 16px; }
-a {
-cursor: pointer; }
-
-
 /*  BASE BUTTON FOR TARIFF CARD  */
 .button {
   display: -webkit-box;

Re: Feature request: Improve diff algorithm

[Stefan Beller]

On Wed, Jan 24, 2018 at 8:43 AM, KES  wrote:
> Here is another place where diff can be improved:
> @@ -141,8 +140,9 @@ My_runops(pTHX)
> // Do not trace variables in DB:: module
> if( SvOK( inDB ) ) continue;
>
> -   sv_inc_nomg( inDB );
>
> +   // save_item( inDB );
> +   sv_inc_nomg( inDB );
> dSP; SINFO; SAVETMPS;
>
> // printf( "SWITCH\n" );
>
>

(Manually reconstructing), the before:

 // Do not trace variables in DB:: module
 if( SvOK( inDB ) ) continue;

 sv_inc_nomg( inDB );

 dSP; SINFO; SAVETMPS;

 // printf( "SWITCH\n" );

and after:

 // Do not trace variables in DB:: module
 if( SvOK( inDB ) ) continue;


  // save_item( inDB );
  sv_inc_nomg( inDB );
 dSP; SINFO; SAVETMPS;

 // printf( "SWITCH\n" );



> This would be better it the patch looks like:
> ( this patch is manually created just to light the idea. It may contain 
> errors)
> @@ -140,6 +140,7 @@ My_runops(pTHX)
>  // Do not trace variables in DB:: module
>  if( SvOK( inDB ) ) continue;
>
> +
> +// save_item( inDB );
>  sv_inc_nomg( inDB );
> -
>  dSP; SINFO; SAVETMPS;

Before:

  // Do not trace variables in DB:: module
  if( SvOK( inDB ) ) continue;

  sv_inc_nomg( inDB );

  dSP; SINFO; SAVETMPS;

after:

  if( SvOK( inDB ) ) continue;


  // save_item( inDB );
  sv_inc_nomg( inDB );
  dSP; SINFO; SAVETMPS;

Seems like the diff is the same.
I agree that we'd rather want to remove/add empty lines
instead of moving full lines. Maybe we can add a penalty for that
in the diff code. Currently each line costs the same, as diff algorithm
optimizes for number of lines to be minimal, which both these diffs
satisfy.


>
> As we can see, here the `sv_inc_nomg( inDB );` line is unchanged and `// 
> save_item( inDB );` is added.
> Here we just add/remove empty lines and patch looks more better.
>
> I think (and this is my assumption), the the diff algorithm should take into 
> account the string length.
> This is more better to add/remove more short lines

Yup. Thanks for giving an example.

Re: Feature request: Improve diff algorithm

[SZEDER Gábor]

On Thu, Jan 25, 2018 at 9:12 PM, SZEDER Gábor  wrote:
>> One yet more:
>>
>> @@ -141,5 +86,9 @@
>>   // }
>>
>>
>> - OP* o;

Oops, when trying to reproduce I overlooked that here the * is stuck
after OP ...

>> + SV *tvs =  newSVpvs( "ScalarHistory" );
>> + SV *tva =  newSVpvs( "ArrayHistory"  );
>> + SV *tvh =  newSVpvs( "HashHistory"   );
>> +
>> + OP *o;

... but here it's stuck to o.

With that adjusted I do get the same diff as you, and I think that's the
right output in this case.

Re: Feature request: Improve diff algorithm

[Junio C Hamano]

KES  writes:

> One yet more:
>
> @@ -141,5 +86,9 @@
>   // }
>  
>  
> - OP* o;
> + SV *tvs =  newSVpvs( "ScalarHistory" );
> + SV *tva =  newSVpvs( "ArrayHistory"  );
> + SV *tvh =  newSVpvs( "HashHistory"   );
> +
> + OP *o;
>   while( PL_op ) {

Huh?

If the asterisk between type OP and var o did not change, then
inserting the three new lines before o's definition may make sense,
but otherwise...

Re: Feature request: Improve diff algorithm

[SZEDER Gábor]

> One yet more:
> 
> @@ -141,5 +86,9 @@
>   // }
>  
>  
> - OP* o;
> + SV *tvs =  newSVpvs( "ScalarHistory" );
> + SV *tva =  newSVpvs( "ArrayHistory"  );
> + SV *tvh =  newSVpvs( "HashHistory"   );
> +
> + OP *o;
>   while( PL_op ) {

What version of Git are you using?

The current version gives me this:

diff --git a/f b/f
index 30a292bbd..fa1e98292 100644
--- a/f
+++ b/f
@@ -1,5 +1,9 @@
// }
 
 
+   SV *tvs =  newSVpvs( "ScalarHistory" );
+   SV *tva =  newSVpvs( "ArrayHistory"  );
+   SV *tvh =  newSVpvs( "HashHistory"   );
+
OP* o;
while( PL_op ) {

Re: Feature request: Improve diff algorithm

[KES]

One yet more:

@@ -141,5 +86,9 @@
// }
 
 
-   OP* o;
+   SV *tvs =  newSVpvs( "ScalarHistory" );
+   SV *tva =  newSVpvs( "ArrayHistory"  );
+   SV *tvh =  newSVpvs( "HashHistory"   );
+
+   OP *o;
while( PL_op ) {

Re: Feature request: Improve diff algorithm

[Jacob Keller]

On Wed, Jan 24, 2018 at 8:43 AM, KES  wrote:
> Here is another place where diff can be improved:
> @@ -141,8 +140,9 @@ My_runops(pTHX)
> // Do not trace variables in DB:: module
> if( SvOK( inDB ) ) continue;
>
> -   sv_inc_nomg( inDB );
>
> +   // save_item( inDB );
> +   sv_inc_nomg( inDB );
> dSP; SINFO; SAVETMPS;
>
> // printf( "SWITCH\n" );
>
>
> This would be better it the patch looks like:
> ( this patch is manually created just to light the idea. It may contain 
> errors)
> @@ -140,6 +140,7 @@ My_runops(pTHX)
>  // Do not trace variables in DB:: module
>  if( SvOK( inDB ) ) continue;
>
> +
> +// save_item( inDB );
>  sv_inc_nomg( inDB );
> -
>  dSP; SINFO; SAVETMPS;
>
> As we can see, here the `sv_inc_nomg( inDB );` line is unchanged and `// 
> save_item( inDB );` is added.
> Here we just add/remove empty lines and patch looks more better.
>
> I think (and this is my assumption), the the diff algorithm should take into 
> account the string length.
> This is more better to add/remove more short lines
>

Hi,

Can you check if this is already handled by --indent-heuristic option
of diff? I think it might help this one already.

Thanks,
Jake

Re: Feature request: Improve diff algorithm

[KES]

Here is another place where diff can be improved:
@@ -141,8 +140,9 @@ My_runops(pTHX)
// Do not trace variables in DB:: module
if( SvOK( inDB ) ) continue;
 
-   sv_inc_nomg( inDB );
 
+   // save_item( inDB );
+   sv_inc_nomg( inDB );
dSP; SINFO; SAVETMPS;
 
// printf( "SWITCH\n" );


This would be better it the patch looks like:
( this patch is manually created just to light the idea. It may contain errors)
@@ -140,6 +140,7 @@ My_runops(pTHX)
 // Do not trace variables in DB:: module
 if( SvOK( inDB ) ) continue;

+ 
+// save_item( inDB );
 sv_inc_nomg( inDB );
- 
 dSP; SINFO; SAVETMPS;

As we can see, here the `sv_inc_nomg( inDB );` line is unchanged and `// 
save_item( inDB );` is added.
Here we just add/remove empty lines and patch looks more better.

I think (and this is my assumption), the the diff algorithm should take into 
account the string length.
This is more better to add/remove more short lines

21.11.2016, 20:55, "Jacob Keller" :
> On Mon, Nov 21, 2016 at 10:17 AM, Stefan Beller  wrote:
>>  On Mon, Nov 21, 2016 at 8:56 AM, Jacob Keller  
>> wrote:
>>>  On Mon, Nov 21, 2016 at 12:11 AM, KES  wrote:
  Hi.
>>>
>>>  Hi,
>>>
  I have some question about how diff works then give proposal:

  it will be very useful for each "symbol" store additional meta info as 
 source line length. So in this case when git counter two equal sequence of 
 commands it will do further comparison: Adds 23 chars deletes none VS adds 
 75 chars deletes 46

  Actually I got this:

  @@ -129,8 +132,9 @@ sub _preprocess_message {
   sub _process_message {
   my ($self, $message) = @_;

  - my $method = ref($message) eq 'HASH' ? $message->{method} : undef;
  + my $time = [ gettimeofday ];

  + my $method = ref($message) eq 'HASH' ? $message->{method} : undef;
   return $self->send_error(ERROR_REQUEST_INVALID)
   unless defined($method);

  Instead of expected:
  @@ -129,6 +132,8 @@ sub _preprocess_message {
   sub _process_message {
   my ($self, $message) = @_;

  + my $time = [ gettimeofday ];
  +
   my $method = ref($message) eq 'HASH' ? $message->{method} : undef;
  -
   return $self->send_error(ERROR_REQUEST_INVALID)
>>>
>>>  Have you tried the various options for git to search for smaller
>>>  diffs? Or using the other diff algorithms such as histogram instead of
>>>  patience?
>>
>>  The newest version of Git comes with a flag to move around the diff
>>  better, based on the work at https://github.com/mhagger/diff-slider-tools
>
> Unfortunately in this case, I'm not convinced that it will improve the
> diff. It's worth a try as well though.
>
> Thanks,
> Jake

Re: feature-request: git "cp" like there is git mv.

[Stefan Moch]

* Jonathan Nieder  [2017-12-15T17:31:30-0800]:
> This sounds like a reasonable thing to add.  See builtin/mv.c for how
> "git mv" works if you're looking for inspiration.
> 
> cmd_mv in that file looks rather long, so I'd also be happy if someone
> interested refactors to break it into multiple self-contained pieces
> for easier reading (git mostly follows
> https://www.kernel.org/doc/html/latest/process/coding-style.html#functions).

I looked at builtin/mv.c and have a rough idea how to split it
up to support both mv and cp commands.

But first I noticed and removed a redundant check in cmd_mv,
also added a test case to check if mv --dry-run does not move
the file.


Stefan

Re: feature-request: git "cp" like there is git mv.

[Igor Djordjevic]

Hi Simon,

On 12/12/2017 11:53, Simon Doodkin wrote:
> 
> please develop a new feature, git "cp" like there is git mv 
> tomovefile1 tofile2 (to save space).
> 
> there is a solution in https://stackoverflow.com/a/44036771/466363
> however, it is not single easy command.

While having `git cp` alongside `git mv` would make sense, I`m afraid 
that is not what you are really after, nor it would help in your case.

Looking at referenced "Stack Overflow" post[1], it tries to address 
`git blame` not following "file copy", where it does "file rename".

Proposed steps seem to be "solution" from your perspective, and while 
that may be absolutely valid and acceptable for your specific case, I 
would argue it`s the wrong approach in general - because `git blame` 
already supports what you want (just not by default), and making 
three additional, unneeded and possibly confusing commits (one being 
a merge), just to "bend" `git blame` to fit your (out of line?) usage 
expectations doesn`t seem right.

I would say a better direction might be using `git blame` "-C[]" 
option[2], where desired effect is achieved without any artificial 
history fiddling.

Example being worth more than plain words, I`m providing a script[3] 
that demonstrates what I`m talking about :)

Regards, Buga

[1] https://stackoverflow.com/a/44036771/466363
[2] https://git-scm.com/docs/git-blame#git-blame--Cltnumgt
[3] Demo script showing how using (multiple) "-C" option(s), with 
specified numeric value, can make `git blame` provide desired 
information, recognizing "file copy" operation (line copy, actually, 
but that is what we are really interested in, using `git blame`):
--- >8 ---
git init

echo a >A
echo b >>A
echo c >>A

git add A
git commit -m "create file A"

git mv A B
git commit -m "rename file A -> B"

# ---
# (A) regular flow
cp B C
git add C
git commit -m "copy file B -> C"
# ---

# ---
# (B) proposed "solution", https://stackoverflow.com/a/44036771/466363
# git mv B C
# git commit -n -m "rename file B -> C"
# SAVED=`git rev-parse HEAD`
# git reset --hard HEAD^
# git mv B B-temp
# git commit -n -m "rename file B -> B-temp"
# git merge $SAVED # This will generate conflicts
# git commit -a -n --no-edit # Trivially resolved like this
# git mv B-temp B
# git commit -n -m "rename file B-temp -> B"
# ---

echo
echo '(1) blames B back to A, as expected:'
git blame -- B
# git blame shows that file B has a history (back to file A)...

echo
echo '(2) blames C only, missing B and A:'
git blame -- C
# ... while file C doesn't have a history

echo
echo '(3) blames C back to A, as expected:'
git blame -C -C3 -- C
# git blame shows that file C has a history (back to file A)

Re: feature-request: git "cp" like there is git mv.

[Jonathan Nieder]

Hi Simon,

Simon Doodkin wrote:

> please develop a new feature, git "cp" like there is git mv tomovefile1 
> tofile2
> (to save space).
>
> there is a solution in https://stackoverflow.com/a/44036771/466363
> however, it is not single easy command.

This sounds like a reasonable thing to add.  See builtin/mv.c for how
"git mv" works if you're looking for inspiration.

cmd_mv in that file looks rather long, so I'd also be happy if someone
interested refactors to break it into multiple self-contained pieces
for easier reading (git mostly follows
https://www.kernel.org/doc/html/latest/process/coding-style.html#functions).

Thanks,
Jonathan

RE: feature-request: git "cp" like there is git mv.

[Randall S. Becker]

-Original Message-
On December 13, 2017 11:40 AM Johannes Schindelin wrote:
>On Tue, 12 Dec 2017, Simon Doodkin wrote:
>> please develop a new feature, git "cp" like there is git mv 
>> tomovefile1 tofile2 (to save space).
>> there is a solution in https://stackoverflow.com/a/44036771/466363
>> however, it is not single easy command.
>This is not how this project works. The idea is that it is Open Source, so
that you can develop this feature yourself, and contribute a patch.

Agree with Johannes. Let's help though, to quantify the requirements so that
Simon can get this right. I'm putting my tyrannical repository manager hat
on here rather than developer so...

Are you looking to have git cp copy the entire history of tomovefile1 to
tofile2 or just copy the content of tomovefile1 to tofile2 and add and/or
commit the file?

In the latter, I see the convenience of this capability. Even so, a simple
cp would copy the content and then you can commit it fairly easily. In the
former, copying the entire history of a file inside the repository is going
to potentially cause tofile2 to appear in old commits where prior to the git
cp command the file was not present? In this situation, you are actually
rewriting history and potentially impacting signed commits (which would no
longer pass a signature check, I hope). Stitching repositories is sometimes
done when repairs or reorganization is required, but I'm concerned that this
is opening up a can of worms that breaks the atomicity of commits
(particularly signed ones). What I don't want, for my own teams, is for
members to think that git cp would be a harmless (unless it actually is)
command, rather than a repair/reorg mechanism used for splitting apart a
repository, or copying a file to a new project then splitting selectively.
So, I'm obviously a bit confused about the goal.

Simon: the stackoverflow post provides a few options on this command. Can
you clarify which particular direction you are interest it?

Cheers,
Randall

-- Brief whoami: NonStop developer since approximately
UNIX(421664400)/NonStop(2112884442) 
-- In my real life, I talk too much.

Re: feature-request: git "cp" like there is git mv.

[Johannes Schindelin]

Hi Simon,

On Tue, 12 Dec 2017, Simon Doodkin wrote:

> please develop a new feature, git "cp" like there is git mv tomovefile1
> tofile2 (to save space).
> 
> there is a solution in https://stackoverflow.com/a/44036771/466363
> however, it is not single easy command.

This is not how this project works. The idea is that it is Open Source, so
that you can develop this feature yourself, and contribute a patch.

Ciao,
Johannes

Re: Feature request: Reduce amount of diff in patch

[Junio C Hamano]

Stefan Beller  writes:

> On Tue, Nov 28, 2017 at 8:09 AM, KES  wrote:
> ...
>> May you please fix the git to generate minimized patches?
>
> You can use a different diff algorithm.
> ...
> Soon we'll have another diff algorithm "anchor" that tries to
> keep a given line out of the +/- but rather move other lines around
> the line to give equal results.

While all of the above is correct, my understanding is that none of
them would produce a patch that KES wants to see.

And we shouldn't ;-)  The two changes KES shows in the message are
not equivalent.

Re: Feature request: Reduce amount of diff in patch

[Stefan Beller]

On Tue, Nov 28, 2017 at 8:09 AM, KES  wrote:
> Hi.
>
> I get often patches which can be minimized:
>
> @@ -60,11 +64,8 @@ sub _get_filter {
>  address=>  { -like => \[ '?',  "%$search%" ] },
>  company=>  { -like => \[ '?',  "%$search%" ] },
>  country_code =>  { '=' => \[ 'UPPER(?)' => $search ] },
> -]);
>
> -$users =  $users->search( $filter, {
> -prefetch => { Packages => { Ips => { Subnet => { Server => 
> 'Locality' ,
> -});
> +]);
>
>
>  return $users;
>
> This patch can be minimized to:
>
> @@ -60,11 +64,8 @@ sub _get_filter {
>  address=>  { -like => \[ '?',  "%$search%" ] },
>  company=>  { -like => \[ '?',  "%$search%" ] },
>  country_code =>  { '=' => \[ 'UPPER(?)' => $search ] },
>  ]);
>
> -$users =  $users->search( $filter, {
> -prefetch => { Packages => { Ips => { Subnet => { Server => 
> 'Locality' ,
> -});
>
>
>  return $users;
>
> May you please fix the git to generate minimized patches?

You can use a different diff algorithm.

   --diff-algorithm={patience|minimal|histogram|myers}
   Choose a diff algorithm. The variants are as follows:

   default, myers
   The basic greedy diff algorithm. Currently, this is the
   default.

   minimal
   Spend extra time to make sure the smallest possible diff is
   produced.

   patience
   Use "patience diff" algorithm when generating patches.

   histogram
   This algorithm extends the patience algorithm to "support
   low-occurrence common elements".

   For instance, if you configured diff.algorithm variable to a
   non-default value and want to use the default one, then you have to
   use --diff-algorithm=default option.

Soon we'll have another diff algorithm "anchor" that tries to
keep a given line out of the +/- but rather move other lines around
the line to give equal results.

Re: Feature request: Reduce amount of diff in patch

[Kaartic Sivaraam]

On Tue, 2017-11-28 at 18:09 +0200, KES wrote:
> Hi.
> 
> I get often patches which can be minimized:
> 

I guess the one below can't be (see below).


> @@ -60,11 +64,8 @@ sub _get_filter {
>  address=>  { -like => \[ '?',  "%$search%" ] },
>  company=>  { -like => \[ '?',  "%$search%" ] },
>  country_code =>  { '=' => \[ 'UPPER(?)' => $search ] },
> -]);
>  
> -$users =  $users->search( $filter, {
> -prefetch => { Packages => { Ips => { Subnet => { Server => 
> 'Locality' ,
> -});
> +]);
>  
>  
>  return $users;
> 
> This patch can be minimized to:
> 
> @@ -60,11 +64,8 @@ sub _get_filter {
>  address=>  { -like => \[ '?',  "%$search%" ] },
>  company=>  { -like => \[ '?',  "%$search%" ] },
>  country_code =>  { '=' => \[ 'UPPER(?)' => $search ] },
>  ]);
>  
> -$users =  $users->search( $filter, {
> -prefetch => { Packages => { Ips => { Subnet => { Server => 
> 'Locality' ,
> -});
> 
>  
>  return $users;
> 
> May you please fix the git to generate minimized patches?
> 

You seemed to have overlooked the empty line above the ']);' in the
original patch. So, your minimized version isn't actually equivalent to
the original one. Further, when trying to recreate your patch I get the
following,

diff --git a/diff-test b/diff-test
index 1d5dc1b..f3ec38f 100644
--- a/diff-test
+++ b/diff-test
@@ -1,10 +1,8 @@
 address=>  { -like => \[ '?',  "%$search%" ] },
 company=>  { -like => \[ '?',  "%$search%" ] },
 country_code =>  { '=' => \[ 'UPPER(?)' => $search ] },
+
 ]);
 
-$users =  $users->search( $filter, {
-prefetch => { Packages => { Ips => { Subnet => { Server => 'Locality' 
,
-});
 
 return $users;

I use git built from the source (2.15.0.531.g2ccb3012c)

-- 
Kaartic

RE: [Feature- Request] Option to commit after checking out branch command is made

[Ninivaggi Mattia]

I like the --autostash flag. 
But actually you just could write an alias co="git stash && git checkout" and 
use co dev for the same purpose, rendering the change irrelevant.

-Original Message-
From: Junio C Hamano [mailto:gits...@pobox.com] 
Sent: Thursday, November 16, 2017 1:20 AM
To: Ninivaggi Mattia
Cc: git@vger.kernel.org
Subject: Re: [Feature- Request] Option to commit after checking out branch 
command is made

Ninivaggi Mattia <mattia.niniva...@helsana.ch> writes:

> 1. I checkout a branch, without having commited first
> > git checkout dev
> 2. I get this error message:
> > error: Your local changes to the following files would be overwritten 
> by checkout:
> > // List of files
> > // ..
> > //
> > Please commit your changes or stash them before you switch branches.
>
> But I would rather prefer a scenario like this:
> ...
> 1. I checkout a branch, without having commited first
> > git checkout dev
> 2. I get a message like this:
> > Your local changes to the following files would be overwritten by 
> checkout:
> > // List of files
> > // ..
> > //
> > Would you want to commit first? (y/n))
>
> IF y --> prompt for commit message and commit automatically

I do not think you want to do this for a few reasons.

 * The "please commit or stash" is merely a suggestion whose primary
   purpose is to silence clueless newbies who would have complained
   "Git said 'error: ... overwritten by checkout' and I do not know
   what to do next; the error message is so unhelpful" otherwise.
   Majority of the time when I see this message, it is because I
   forgot that I was in the middle of doing something (meaning: I am
   far from finished with the changes I was working on), and I would
   not be ready to commit.  I'd rather keep working to get the work
   into a more reasonable shape before committing, or stash the
   changes first if the task I wanted to do on that "dev" branch is
   more urgent and what I was in the middle of doing is lower
   priority.  

   Because of this, I would expect many users (including the ones
   who are right now newbies but will have gained experience to
   become experts in the future) to appreciate "stash before switch"
   a lot more than "commit first before switch".

 * People write scripts that use "git checkout" to switch branches,
   and they rely on the command to fail in this situation, instead
   of going interactive and gets stuck waiting for an input (which
   may never come).  Because of this, the updated behaviour you
   propose must never be the default, and at least must be protected
   behind a flag, something like "git checkout --autostash dev" (or
   "--autocommit", if you insist).  With that, you could do

[alias]
co = checkout --autostash

   and train your fingers to say "git co dev".

Of course, you can have a "git-co" script on your $PATH, which runs "git 
checkout $1", lets it fail just like it does now, and then does "git commit", 
if you really want the behaviour.  Again, you can then use "git co dev" and you 
do not have to worry about breaking people's scripts that depends on "git 
checkout" to fail without going interactive.

Re: [Feature- Request] Option to commit after checking out branch command is made

[Junio C Hamano]

Ninivaggi Mattia  writes:

> 1. I checkout a branch, without having commited first
> > git checkout dev
> 2. I get this error message:
> > error: Your local changes to the following files would be overwritten 
> by checkout:
> > // List of files
> > // ..
> > //
> > Please commit your changes or stash them before you switch branches.
>
> But I would rather prefer a scenario like this:
> ...
> 1. I checkout a branch, without having commited first
> > git checkout dev
> 2. I get a message like this:
> > Your local changes to the following files would be overwritten by 
> checkout:
> > // List of files
> > // ..
> > //
> > Would you want to commit first? (y/n))
>
> IF y --> prompt for commit message and commit automatically

I do not think you want to do this for a few reasons.

 * The "please commit or stash" is merely a suggestion whose primary
   purpose is to silence clueless newbies who would have complained
   "Git said 'error: ... overwritten by checkout' and I do not know
   what to do next; the error message is so unhelpful" otherwise.
   Majority of the time when I see this message, it is because I
   forgot that I was in the middle of doing something (meaning: I am
   far from finished with the changes I was working on), and I would
   not be ready to commit.  I'd rather keep working to get the work
   into a more reasonable shape before committing, or stash the
   changes first if the task I wanted to do on that "dev" branch is
   more urgent and what I was in the middle of doing is lower
   priority.  

   Because of this, I would expect many users (including the ones
   who are right now newbies but will have gained experience to
   become experts in the future) to appreciate "stash before switch"
   a lot more than "commit first before switch".

 * People write scripts that use "git checkout" to switch branches,
   and they rely on the command to fail in this situation, instead
   of going interactive and gets stuck waiting for an input (which
   may never come).  Because of this, the updated behaviour you
   propose must never be the default, and at least must be protected
   behind a flag, something like "git checkout --autostash dev" (or
   "--autocommit", if you insist).  With that, you could do

[alias]
co = checkout --autostash

   and train your fingers to say "git co dev".

Of course, you can have a "git-co" script on your $PATH, which runs
"git checkout $1", lets it fail just like it does now, and then does
"git commit", if you really want the behaviour.  Again, you can then
use "git co dev" and you do not have to worry about breaking
people's scripts that depends on "git checkout" to fail without
going interactive.

Re: Feature Request: Show status of the stash in git status command

[Junio C Hamano]

liam Beguin  writes:

>> The fact a stash entry is a merge commit of two synthetic commits is an
>> implementation detail.  It can be very useful at times for power users,
>> but regular Git users need not be concerned with this.
>> 
>> Another fact worth reiterating that what the UI displays to the user is
>> better to match what the user reads in the docs. ;-)
>
> I'll make changes as suggested by Junio. I slightly prefer
> "Your stash has %d entry/entries" over "You have %d stash/stashes" 
> but I'll go with what's used elsewhere in the documentation. 

Yup, I agree that I would definitely call them "stash entries" if I
were writing the documentation today, but lets match the new message
to the existing lingo first and think about renaming "a stash" to "a
stash entry" as a separate step.  The latter would become a larger
change (we'd also need to add an entry to glossary-contents.txt).

Thanks.

Re: Feature Request: Show status of the stash in git status command

[liam Beguin]

Hi, 

On 13/06/17 02:42 AM, Konstantin Khomoutov wrote:
> On Mon, Jun 12, 2017 at 11:42:44PM -0400, liam Beguin wrote:
> 
> [...]
>>> Conceptually, the contents of the stash are *not* commits, even
>>> though the implementation happens to use a commit to represent each
>>> stash entry.  Perhaps "has %d entry/entries" is an improvement, but
>>> a quick scanning of an early part of "git stash --help" tells me
>>> that
>>
>> what's different between a stash and a commit? 
> 
> The same that exists between an interface and a concrete implementation
> in a programming language.

Makes sense, I thought there was a more fundamental difference.

> 
> "A stash entry" is a concept which is defined to keep explicitly
> recorded untracked files and which can be applied, shown and deleted
> from the stash bag (well, you can create a branch off it as well).

I've noticed this but I don't understand when it can be used.
I'll try to find out more on this.

> 
> The fact a stash entry is a merge commit of two synthetic commits is an
> implementation detail.  It can be very useful at times for power users,
> but regular Git users need not be concerned with this.
> 
> Another fact worth reiterating that what the UI displays to the user is
> better to match what the user reads in the docs. ;-)
> 

I'll make changes as suggested by Junio. I slightly prefer
"Your stash has %d entry/entries" over "You have %d stash/stashes" 
but I'll go with what's used elsewhere in the documentation. 

Thanks,

 - Liam

Re: Feature Request: Show status of the stash in git status command

[Konstantin Khomoutov]

On Mon, Jun 12, 2017 at 11:42:44PM -0400, liam Beguin wrote:

[...]
>> Conceptually, the contents of the stash are *not* commits, even
>> though the implementation happens to use a commit to represent each
>> stash entry.  Perhaps "has %d entry/entries" is an improvement, but
>> a quick scanning of an early part of "git stash --help" tells me
>> that
> 
> what's different between a stash and a commit? 

The same that exists between an interface and a concrete implementation
in a programming language.

"A stash entry" is a concept which is defined to keep explicitly
recorded untracked files and which can be applied, shown and deleted
from the stash bag (well, you can create a branch off it as well).

The fact a stash entry is a merge commit of two synthetic commits is an
implementation detail.  It can be very useful at times for power users,
but regular Git users need not be concerned with this.

Another fact worth reiterating that what the UI displays to the user is
better to match what the user reads in the docs. ;-)

Re: Feature Request: Show status of the stash in git status command

[liam Beguin]

Hi, 

Thanks for the feedback. I'll be sending a patch with the updates shortly!

On 12/06/17 11:35 AM, Junio C Hamano wrote:
> liam Beguin  writes:
> 
>> +static int stash_count_refs(struct object_id *ooid, struct object_id *noid,
>> +const char *email, timestamp_t timestamp, int tz,
>> +const char *message, void *cb_data)
>> +{
>> +int *c = cb_data;
>> +(*c)++;
>> +return 0;
>> +}
> 
> Count up, and tell the caller to keep going by returning 0.  That
> sounds sane.
> 
>> +static void wt_longstatus_print_stash_summary(struct wt_status *s)
>> +{
>> +int stash_count = 0;
>> +
>> +for_each_reflog_ent("refs/stash", stash_count_refs, _count);
> 
> And do so with a counter initialized to 0.  Also sane.
> 
>> +if (stash_count > 0)
>> +status_printf_ln(s, GIT_COLOR_NORMAL,
>> + Q_("Your stash currently has %d commit",
>> +"Your stash currently has %d commits", 
>> stash_count),
>> + stash_count);
> 
> Conceptually, the contents of the stash are *not* commits, even
> though the implementation happens to use a commit to represent each
> stash entry.  Perhaps "has %d entry/entries" is an improvement, but
> a quick scanning of an early part of "git stash --help" tells me
> that

what's different between a stash and a commit? 

> 
>   You have 1 stash / You have 4 stashes
> 
> would be the best, as the documentation calls each entry "a stash".
> E.g. "list" is explained to list "the stashes", and "show "
> is explained to show the changes recorded in "the stash".
> 
>> +}
>> +
>>  static void wt_longstatus_print_submodule_summary(struct wt_status *s, int 
>> uncommitted)
>>  {
>>  struct child_process sm_summary = CHILD_PROCESS_INIT;
>> @@ -1536,6 +1557,7 @@ static void wt_longstatus_print(struct wt_status *s)
>>  const char *branch_color = color(WT_STATUS_ONBRANCH, s);
>>  const char *branch_status_color = color(WT_STATUS_HEADER, s);
>>  struct wt_status_state state;
>> +int show_stash = 0;
>>  
>>  memset(, 0, sizeof(state));
>>  wt_status_get_state(,
>> @@ -1641,6 +1663,8 @@ static void wt_longstatus_print(struct wt_status *s)
>>  } else
>>  printf(_("nothing to commit, working tree clean\n"));
>>  }
>> +if (!git_config_get_bool("status.showStash", _stash) && show_stash)
>> +wt_longstatus_print_stash_summary(s);
>>  }
> 
> Try to get "status.showstash" as a boolean, and only when it
> succeeds and the value is true, give this extra info (i.e. when the
> variable does not exist, do not complain and do not show).  Sounds
> sensible.
> 
> Overall the logic looks good to me; just the phrasing is
> questionable, relative to the existing documentation.
> 
> Thanks.
> 

Thanks,

 - Liam 

Re: Feature Request: Show status of the stash in git status command

[Junio C Hamano]

liam Beguin  writes:

> +static int stash_count_refs(struct object_id *ooid, struct object_id *noid,
> + const char *email, timestamp_t timestamp, int tz,
> + const char *message, void *cb_data)
> +{
> + int *c = cb_data;
> + (*c)++;
> + return 0;
> +}

Count up, and tell the caller to keep going by returning 0.  That
sounds sane.

> +static void wt_longstatus_print_stash_summary(struct wt_status *s)
> +{
> + int stash_count = 0;
> +
> + for_each_reflog_ent("refs/stash", stash_count_refs, _count);

And do so with a counter initialized to 0.  Also sane.

> + if (stash_count > 0)
> + status_printf_ln(s, GIT_COLOR_NORMAL,
> +  Q_("Your stash currently has %d commit",
> + "Your stash currently has %d commits", 
> stash_count),
> +  stash_count);

Conceptually, the contents of the stash are *not* commits, even
though the implementation happens to use a commit to represent each
stash entry.  Perhaps "has %d entry/entries" is an improvement, but
a quick scanning of an early part of "git stash --help" tells me
that

You have 1 stash / You have 4 stashes

would be the best, as the documentation calls each entry "a stash".
E.g. "list" is explained to list "the stashes", and "show "
is explained to show the changes recorded in "the stash".

> +}
> +
>  static void wt_longstatus_print_submodule_summary(struct wt_status *s, int 
> uncommitted)
>  {
>   struct child_process sm_summary = CHILD_PROCESS_INIT;
> @@ -1536,6 +1557,7 @@ static void wt_longstatus_print(struct wt_status *s)
>   const char *branch_color = color(WT_STATUS_ONBRANCH, s);
>   const char *branch_status_color = color(WT_STATUS_HEADER, s);
>   struct wt_status_state state;
> + int show_stash = 0;
>  
>   memset(, 0, sizeof(state));
>   wt_status_get_state(,
> @@ -1641,6 +1663,8 @@ static void wt_longstatus_print(struct wt_status *s)
>   } else
>   printf(_("nothing to commit, working tree clean\n"));
>   }
> + if (!git_config_get_bool("status.showStash", _stash) && show_stash)
> + wt_longstatus_print_stash_summary(s);
>  }

Try to get "status.showstash" as a boolean, and only when it
succeeds and the value is true, give this extra info (i.e. when the
variable does not exist, do not complain and do not show).  Sounds
sensible.

Overall the logic looks good to me; just the phrasing is
questionable, relative to the existing documentation.

Thanks.

RE: Feature Request: Show status of the stash in git status command

[Randall S. Becker]

On June 11, 2017 2:19 PM  Igor Djordjevic wrote: 
>On 11/06/2017 19:57, Randall S. Becker wrote:
>> Random thought: what if a stash id could be used in the same way as 
>> any other ref, so diff stash[0] stash[1] would be possible - although 
>> I can see this being problematic for a merge or rebase.
>Not sure if I`m misunderstanding you, but at least `git diff stash@{0} 
>stash@{1}` seems to already work as expected - I remember using it in the 
>past, >and I`ve tried it again now[1], and it still works.

I'm sorry for not checking first before posting. Thanks 

Randall

Re: Feature Request: Show status of the stash in git status command

[Igor Djordjevic]

Hi Randall,

On 11/06/2017 19:57, Randall S. Becker wrote:
> Random thought: what if a stash id could be used in the same way as 
> any other ref, so diff stash[0] stash[1] would be possible - 
> although I can see this being problematic for a merge or rebase.

Not sure if I`m misunderstanding you, but at least `git diff 
stash@{0} stash@{1}` seems to already work as expected - I remember 
using it in the past, and I`ve tried it again now[1], and it still 
works.

[1] git version 2.13.0.windows.1

Regards,
Buga

RE: Feature Request: Show status of the stash in git status command

[Randall S. Becker]

On June 11, 2017 1:07 PM liam Beguin wrote:
>There is one thing I've noticed though. When using 'git stash pop', it shows 
>the the number of stashes before dropping the commit and I'm not quite ?>sure 
>how to address this.

On 10/06/17 06:22 AM, Jeff King wrote:
> On Sat, Jun 10, 2017 at 06:12:28AM -0400, Samuel Lijin wrote:
>> On Sat, Jun 10, 2017 at 4:25 AM, Jeff King  wrote:
>>> On Wed, Jun 07, 2017 at 06:46:18PM -0400, Houston Fortney wrote:
>>>
 I sometimes forget about something that I stashed. It would be nice 
 if the git status command would just say "There are x entries in 
 the stash." It can say nothing if there is nothing stashed so it is 
 usually not adding clutter.
>>>
>>> I think the clutter issue would depend on your workflow around stash.
>>>
>>> Some people carry tidbits in their stash for days or weeks. E.g., I 
>>> sometimes start on an idea and decide it's not worth pursuing (or 
>>> more likely, I post a snippet of a patch as a "how about this" to 
>>> the mailing list but don't plan on taking it further). Rather than 
>>> run "git reset --hard", I usually "git stash" the result. That means 
>>> if I really do decide I want it back, I can prowl through the stash list 
>>> and find it.
>>>
>>> All of which is to say that if we had such a feature, it should 
>>> probably be optional. For some people it would be very useful, and 
>>> for others it would be a nuisance.
>>
>> Perhaps there should be a flag for this if it is implemented, say 
>> status.showStash?

Random thought: what if a stash id could be used in the same way as any other 
ref, so diff stash[0] stash[1] would be possible - although I can see this 
being problematic for a merge or rebase.

Cheers,
Randall

Re: Feature Request: Show status of the stash in git status command

[liam Beguin]

Hi,

As it looks like something easy enough for a beginner, I though I could
give it a try. Here is what it looks like. If it's good enough, I'll 
add a few lines to document 'status.showStash' and send a patch.

There is one thing I've noticed though. When using 'git stash pop', it
shows the the number of stashes before dropping the commit and I'm not
quite sure how to address this.

--

diff --git a/wt-status.c b/wt-status.c
index 25aafc35c833..fab66d4cd72e 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -801,6 +801,27 @@ static void wt_longstatus_print_changed(struct wt_status 
*s)
wt_longstatus_print_trailer(s);
 }
 
+static int stash_count_refs(struct object_id *ooid, struct object_id *noid,
+   const char *email, timestamp_t timestamp, int tz,
+   const char *message, void *cb_data)
+{
+   int *c = cb_data;
+   (*c)++;
+   return 0;
+}
+
+static void wt_longstatus_print_stash_summary(struct wt_status *s)
+{
+   int stash_count = 0;
+
+   for_each_reflog_ent("refs/stash", stash_count_refs, _count);
+   if (stash_count > 0)
+   status_printf_ln(s, GIT_COLOR_NORMAL,
+Q_("Your stash currently has %d commit",
+   "Your stash currently has %d commits", 
stash_count),
+stash_count);
+}
+
 static void wt_longstatus_print_submodule_summary(struct wt_status *s, int 
uncommitted)
 {
struct child_process sm_summary = CHILD_PROCESS_INIT;
@@ -1536,6 +1557,7 @@ static void wt_longstatus_print(struct wt_status *s)
const char *branch_color = color(WT_STATUS_ONBRANCH, s);
const char *branch_status_color = color(WT_STATUS_HEADER, s);
struct wt_status_state state;
+   int show_stash = 0;
 
memset(, 0, sizeof(state));
wt_status_get_state(,
@@ -1641,6 +1663,8 @@ static void wt_longstatus_print(struct wt_status *s)
} else
printf(_("nothing to commit, working tree clean\n"));
}
+   if (!git_config_get_bool("status.showStash", _stash) && show_stash)
+   wt_longstatus_print_stash_summary(s);
 }
 
 static void wt_shortstatus_unmerged(struct string_list_item *it,




On 10/06/17 06:22 AM, Jeff King wrote:
> On Sat, Jun 10, 2017 at 06:12:28AM -0400, Samuel Lijin wrote:
> 
>> On Sat, Jun 10, 2017 at 4:25 AM, Jeff King  wrote:
>>> On Wed, Jun 07, 2017 at 06:46:18PM -0400, Houston Fortney wrote:
>>>
 I sometimes forget about something that I stashed. It would be nice if
 the git status command would just say "There are x entries in the
 stash." It can say nothing if there is nothing stashed so it is
 usually not adding clutter.
>>>
>>> I think the clutter issue would depend on your workflow around stash.
>>>
>>> Some people carry tidbits in their stash for days or weeks. E.g., I
>>> sometimes start on an idea and decide it's not worth pursuing (or more
>>> likely, I post a snippet of a patch as a "how about this" to the mailing
>>> list but don't plan on taking it further). Rather than run "git reset
>>> --hard", I usually "git stash" the result. That means if I really do
>>> decide I want it back, I can prowl through the stash list and find it.
>>>
>>> All of which is to say that if we had such a feature, it should probably
>>> be optional. For some people it would be very useful, and for others it
>>> would be a nuisance.
>>
>> Perhaps there should be a flag for this if it is implemented, say
>> status.showStash?
> 
> Yes, that was what I was thinking.
> 
> -Peff
> 

 - Liam

Re: Feature Request: Show status of the stash in git status command

[Jeff King]

On Sat, Jun 10, 2017 at 06:12:28AM -0400, Samuel Lijin wrote:

> On Sat, Jun 10, 2017 at 4:25 AM, Jeff King  wrote:
> > On Wed, Jun 07, 2017 at 06:46:18PM -0400, Houston Fortney wrote:
> >
> >> I sometimes forget about something that I stashed. It would be nice if
> >> the git status command would just say "There are x entries in the
> >> stash." It can say nothing if there is nothing stashed so it is
> >> usually not adding clutter.
> >
> > I think the clutter issue would depend on your workflow around stash.
> >
> > Some people carry tidbits in their stash for days or weeks. E.g., I
> > sometimes start on an idea and decide it's not worth pursuing (or more
> > likely, I post a snippet of a patch as a "how about this" to the mailing
> > list but don't plan on taking it further). Rather than run "git reset
> > --hard", I usually "git stash" the result. That means if I really do
> > decide I want it back, I can prowl through the stash list and find it.
> >
> > All of which is to say that if we had such a feature, it should probably
> > be optional. For some people it would be very useful, and for others it
> > would be a nuisance.
> 
> Perhaps there should be a flag for this if it is implemented, say
> status.showStash?

Yes, that was what I was thinking.

-Peff

Re: Feature Request: Show status of the stash in git status command

[Samuel Lijin]

On Sat, Jun 10, 2017 at 4:25 AM, Jeff King  wrote:
> On Wed, Jun 07, 2017 at 06:46:18PM -0400, Houston Fortney wrote:
>
>> I sometimes forget about something that I stashed. It would be nice if
>> the git status command would just say "There are x entries in the
>> stash." It can say nothing if there is nothing stashed so it is
>> usually not adding clutter.
>
> I think the clutter issue would depend on your workflow around stash.
>
> Some people carry tidbits in their stash for days or weeks. E.g., I
> sometimes start on an idea and decide it's not worth pursuing (or more
> likely, I post a snippet of a patch as a "how about this" to the mailing
> list but don't plan on taking it further). Rather than run "git reset
> --hard", I usually "git stash" the result. That means if I really do
> decide I want it back, I can prowl through the stash list and find it.
>
> All of which is to say that if we had such a feature, it should probably
> be optional. For some people it would be very useful, and for others it
> would be a nuisance.

Perhaps there should be a flag for this if it is implemented, say
status.showStash?

> Do you want to try a patch? I think you'd need to find the right spot in
> wt-status.c to show the output, and then call for_each_reflog_ent() on
> "refs/stash" and count the number of entries you see.
>
> -Peff

Re: Feature Request: Show status of the stash in git status command

[Jeff King]

On Wed, Jun 07, 2017 at 06:46:18PM -0400, Houston Fortney wrote:

> I sometimes forget about something that I stashed. It would be nice if
> the git status command would just say "There are x entries in the
> stash." It can say nothing if there is nothing stashed so it is
> usually not adding clutter.

I think the clutter issue would depend on your workflow around stash.

Some people carry tidbits in their stash for days or weeks. E.g., I
sometimes start on an idea and decide it's not worth pursuing (or more
likely, I post a snippet of a patch as a "how about this" to the mailing
list but don't plan on taking it further). Rather than run "git reset
--hard", I usually "git stash" the result. That means if I really do
decide I want it back, I can prowl through the stash list and find it.

All of which is to say that if we had such a feature, it should probably
be optional. For some people it would be very useful, and for others it
would be a nuisance.

Do you want to try a patch? I think you'd need to find the right spot in
wt-status.c to show the output, and then call for_each_reflog_ent() on
"refs/stash" and count the number of entries you see.

-Peff

Re: Feature request: Please add support to stash specific files

[rajdeep mondal]

Thanks Mike.

On Tue, Jun 6, 2017 at 5:03 PM, Mike Hommey  wrote:
> On Tue, Jun 06, 2017 at 02:38:08PM -0400, rajdeep mondal wrote:
>> Hi Randall,
>>
>> I completely agree to what you are saying, but sometimes it just so
>> happens that in the middle of a change, i feel like if some portion of
>> the changes are fine I can commit them.  Stashing some of the files
>> and being able to check the compile/tests at this point would be a
>> really awesome change.
>>
>> Stash supports a -p option to deal with this, it becomes cumbersome
>> when the number of files are many.  Maybe it is something which would
>> be a good to have feature. People need not use it if they dont want
>> to.
>
> Git 2.13.0 has that already.
>
> git stash -- file1 file2
>
> Mike



-- 
==
Rajdeep
==

Re: Feature request: Please add support to stash specific files

[Mike Hommey]

On Tue, Jun 06, 2017 at 02:38:08PM -0400, rajdeep mondal wrote:
> Hi Randall,
> 
> I completely agree to what you are saying, but sometimes it just so
> happens that in the middle of a change, i feel like if some portion of
> the changes are fine I can commit them.  Stashing some of the files
> and being able to check the compile/tests at this point would be a
> really awesome change.
> 
> Stash supports a -p option to deal with this, it becomes cumbersome
> when the number of files are many.  Maybe it is something which would
> be a good to have feature. People need not use it if they dont want
> to.

Git 2.13.0 has that already.

git stash -- file1 file2

Mike

Re: Feature request: Please add support to stash specific files

[rajdeep mondal]

Hi Randall,

I completely agree to what you are saying, but sometimes it just so
happens that in the middle of a change, i feel like if some portion of
the changes are fine I can commit them.  Stashing some of the files
and being able to check the compile/tests at this point would be a
really awesome change.

Stash supports a -p option to deal with this, it becomes cumbersome
when the number of files are many.  Maybe it is something which would
be a good to have feature. People need not use it if they dont want
to.

Thanks
Rajdeep

On Tue, Jun 6, 2017 at 9:31 AM, Randall S. Becker
 wrote:
> -Original Message-
> On June 6, 2017 9:23 AM, rajdeep mondal wrote:
>>Work around found in:
>>https://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git
>>Workaround is not very optimal. Please add this support to git.
>
> Instead of using stash as part of your normal process, consider using topic 
> branches instead. Before working, switch to a new topic branch. If you 
> forget, stash, switch, apply, then go forth. While on the topic branch, you 
> can use add and commit on a hunk or file basis to satisfy what appears to be 
> the requirement here. You can then merge the desired commits from your topic 
> branch into wherever you want to merge them either preserving the commit or 
> by squashing commits together.
>
> In my shop, stash is only used for the "I forgot to switch to a topic branch, 
> oops" process. I try to encourage people not to use it. I also discourage 
> squashed commits, but that's because I like knowing what's in my sausages 
>
> Cheers,
> Randall
>
>



-- 
==
Rajdeep
==

Re: Feature request: Please add support to stash specific files

[Christian Neukirchen]

rajdeep mondal  writes:

> git version 2.6.3
> OS: RHEL 6
>
> Work around found in:
> https://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git
>
> Workaround is not very optimal. Please add this support to git.

This has been implemented in Git 2.13:

> * "git stash push" takes a pathspec so that the local changes can be
>   stashed away only partially.

-- 
Christian Neukirchen    http://chneukirchen.org

RE: Feature request: Please add support to stash specific files

[Randall S. Becker]

-Original Message-
On June 6, 2017 9:23 AM, rajdeep mondal wrote:
>Work around found in:
>https://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git
>Workaround is not very optimal. Please add this support to git.

Instead of using stash as part of your normal process, consider using topic 
branches instead. Before working, switch to a new topic branch. If you forget, 
stash, switch, apply, then go forth. While on the topic branch, you can use add 
and commit on a hunk or file basis to satisfy what appears to be the 
requirement here. You can then merge the desired commits from your topic branch 
into wherever you want to merge them either preserving the commit or by 
squashing commits together.

In my shop, stash is only used for the "I forgot to switch to a topic branch, 
oops" process. I try to encourage people not to use it. I also discourage 
squashed commits, but that's because I like knowing what's in my sausages 

Cheers,
Randall

Re: Feature request: "git status" highlights files that are larger than 500kb.

[Ævar Arnfjörð Bjarmason]

On Fri, May 26, 2017 at 2:24 AM, Zhomart Mukhamejanov
 wrote:
> So it will be easy to track that we don't accidentally commit huge files.

Isn't doing this via a pre-commit or pre-receive hook both more
reliable & actually a 1=1 mapping to what you really care about?

Re: Feature request: --format=json

[shawn wilson]

On Mon, Apr 24, 2017 at 5:28 AM, Duy Nguyen  wrote:
> On Mon, Apr 24, 2017 at 3:33 PM, shawn wilson  wrote:
>> Late to the party, but I too would also like json format output (mainly so I
>> could pipe stuff to jq instead of looking at the man page for which %thing
>> I'm looking for). That said, it's not at the PR level of want for me.
>>
>> OTOH, format=xml would be even more handy IMHO... Which I see has hit both
>> SO and this ml in the past. Either way /some/ machine output would be a good
>> thing :)
>
> Personally I'd rather avoid linking to another library just for
> json/xml formatting. libgit2 would be a great place to have
> functionality like this and it looks like you don't even have to touch
> C [1] to do that.
>
> [1] https://gist.github.com/m1el/42472327b4be382b02eb


Heh, well, I guess if it's like that (simple), I don't really care :)
I was under the impression (no idea why) that it was limited to C or
java (and friends). Given this means I don't have to figure out
someone's json structure or refer to an xsd, I'll live w/ this.

Re: Feature request: --format=json

[Duy Nguyen]

On Mon, Apr 24, 2017 at 3:33 PM, shawn wilson  wrote:
> Late to the party, but I too would also like json format output (mainly so I
> could pipe stuff to jq instead of looking at the man page for which %thing
> I'm looking for). That said, it's not at the PR level of want for me.
>
> OTOH, format=xml would be even more handy IMHO... Which I see has hit both
> SO and this ml in the past. Either way /some/ machine output would be a good
> thing :)

Personally I'd rather avoid linking to another library just for
json/xml formatting. libgit2 would be a great place to have
functionality like this and it looks like you don't even have to touch
C [1] to do that.

[1] https://gist.github.com/m1el/42472327b4be382b02eb
-- 
Duy

Re: Feature request: --format=json

[demerphq]

On 18 April 2017 at 10:44, Fred .Flintstone  wrote:
> Well the easiest way to work with that would be JSON.
> So the best would be if Git could output the data I want in JSON format.
> Then it would be easy for me to work with data.
>
> With git rev-list and git-cat file, its not so easy to reliably parse
> that output.

Doesn't seem too hard to work with rev-list to me. As far as I can
tell the following produces what  you want. You need perl installed
obviously, and the JSON::PP module is required, but should come
bundled with recent perls.

git rev-list master --pretty=raw | perl -MJSON::PP=encode_json
-ane'if(/^(\w+) (.*)/) { if ($1 eq "commit") { push @objs, $o if $o;
$o={}; } $o->{$1} = $2; } else { $o->{text} .= $_; } END{ push @objs,
$o if $o; for $o (@objs) { s/^//mg, s/^\n// for $o->{text};
($o->{message},$o->{long_message})= split /\n\n/, delete $o->{text}; }
print JSON::PP->new->pretty->encode(\@objs);}'

You might consider an alternative approach than stating that working
with JSON is "the easiest", especially to people who clearly are
making do without it. :-)

A better argument might be that exposing data through a well defined
and widely used and simple data format would trivially expand the
range of projects that might interoperate with git or enhance the git
ecosystem. For instance you could argue that having clean JSON output
would make it easier to integrate into search engines and other
indexing tools that already know how to speak JSON. Maybe a regular
contributor on this list might agree with your arguments and make it
happen.

Until then you can parse rev-list like the rest of us. :-)

cheers,
Yves

Re: Feature request: --format=json

[Fred .Flintstone]

But a repository or branch can have thousands of commits, so running
`git commit-file ` seems maybe not be a wide idea.
But parsing `git cat-file --batch` is difficult, because there seems
to be no reliable way to discern when a commit starts and ends.

I don't code in C though. A JSON formatter option would need a JSON library.
But maybe there should be raised a discussion about JSON in Git if
there are other people interested in this?

On Tue, Apr 18, 2017 at 11:39 AM, Samuel Lijin  wrote:
> If for some reason your use case is so performance intensive that you
> can't just `git cat-file commit` every entry in `git rev-list --all`
> individually, then you can also pipe input into `git cat-file --batch`
> and read output as you pipe input in, which will give you a very
> simple mechanism for delimiting the cat-file output.
>
> In any case, as developers, it's rare to have our job done for us.
> That's why we write code.
>
> I'm sure people would be happy to help if you submitted patches to
> support --format=json.
>
> On Tue, Apr 18, 2017 at 3:44 AM, Fred .Flintstone  wrote:
>> Well the easiest way to work with that would be JSON.
>> So the best would be if Git could output the data I want in JSON format.
>> Then it would be easy for me to work with data.
>>
>> With git rev-list and git-cat file, its not so easy to reliably parse
>> that output.
>>
>> On Tue, Apr 18, 2017 at 2:38 AM, Junio C Hamano  wrote:
>>> "Fred .Flintstone"  writes:
>>>
 So I would either have to do:
 git rev-list --all
 Then iterate over each line and do git-cat-file commit .

 Or do:
 git rev-list --all | git cat-file --batch

 If I do it in a batch, then it will be tricky to reliably parse since
 I don't know when the message body ends and when the next commit
 starts.

 JSON output would have been very handy.
>>>
>>> I am somewhat puzzled.  I thought that you were trying to come up
>>> with a way to produce JSON output and people are trying to help you
>>> by pointing out tools that you can use for that.

Re: Feature request: --format=json

[Samuel Lijin]

If for some reason your use case is so performance intensive that you
can't just `git cat-file commit` every entry in `git rev-list --all`
individually, then you can also pipe input into `git cat-file --batch`
and read output as you pipe input in, which will give you a very
simple mechanism for delimiting the cat-file output.

In any case, as developers, it's rare to have our job done for us.
That's why we write code.

I'm sure people would be happy to help if you submitted patches to
support --format=json.

On Tue, Apr 18, 2017 at 3:44 AM, Fred .Flintstone  wrote:
> Well the easiest way to work with that would be JSON.
> So the best would be if Git could output the data I want in JSON format.
> Then it would be easy for me to work with data.
>
> With git rev-list and git-cat file, its not so easy to reliably parse
> that output.
>
> On Tue, Apr 18, 2017 at 2:38 AM, Junio C Hamano  wrote:
>> "Fred .Flintstone"  writes:
>>
>>> So I would either have to do:
>>> git rev-list --all
>>> Then iterate over each line and do git-cat-file commit .
>>>
>>> Or do:
>>> git rev-list --all | git cat-file --batch
>>>
>>> If I do it in a batch, then it will be tricky to reliably parse since
>>> I don't know when the message body ends and when the next commit
>>> starts.
>>>
>>> JSON output would have been very handy.
>>
>> I am somewhat puzzled.  I thought that you were trying to come up
>> with a way to produce JSON output and people are trying to help you
>> by pointing out tools that you can use for that.

Re: Feature request: --format=json

[Fred .Flintstone]

Well the easiest way to work with that would be JSON.
So the best would be if Git could output the data I want in JSON format.
Then it would be easy for me to work with data.

With git rev-list and git-cat file, its not so easy to reliably parse
that output.

On Tue, Apr 18, 2017 at 2:38 AM, Junio C Hamano  wrote:
> "Fred .Flintstone"  writes:
>
>> So I would either have to do:
>> git rev-list --all
>> Then iterate over each line and do git-cat-file commit .
>>
>> Or do:
>> git rev-list --all | git cat-file --batch
>>
>> If I do it in a batch, then it will be tricky to reliably parse since
>> I don't know when the message body ends and when the next commit
>> starts.
>>
>> JSON output would have been very handy.
>
> I am somewhat puzzled.  I thought that you were trying to come up
> with a way to produce JSON output and people are trying to help you
> by pointing out tools that you can use for that.

Re: Feature request: --format=json

[Junio C Hamano]

"Fred .Flintstone"  writes:

> So I would either have to do:
> git rev-list --all
> Then iterate over each line and do git-cat-file commit .
>
> Or do:
> git rev-list --all | git cat-file --batch
>
> If I do it in a batch, then it will be tricky to reliably parse since
> I don't know when the message body ends and when the next commit
> starts.
>
> JSON output would have been very handy.

I am somewhat puzzled.  I thought that you were trying to come up
with a way to produce JSON output and people are trying to help you
by pointing out tools that you can use for that.

Re: Feature request: --format=json

[Sebastian Schuberth]

On 2017-04-17 14:44, Fred .Flintstone wrote:


However, if I want something more suitable for machine parsing, is
there any way to get that output?


Instead of machine parsing, why not directly get what you want via 
libgit2 (or one of its language bindings), or jgit?


[1] https://github.com/libgit2/libgit2
[2] https://github.com/eclipse/jgit

--
Sebastian Schuberth

Re: Feature request: --format=json

[Fred .Flintstone]

So I would either have to do:
git rev-list --all
Then iterate over each line and do git-cat-file commit .

Or do:
git rev-list --all | git cat-file --batch

If I do it in a batch, then it will be tricky to reliably parse since
I don't know when the message body ends and when the next commit
starts.

JSON output would have been very handy.

On Mon, Apr 17, 2017 at 2:59 PM, Duy Nguyen  wrote:
> On Mon, Apr 17, 2017 at 7:44 PM, Fred .Flintstone  wrote:
>> So I did "git rev-list --all --pretty" and it looks like "git log".
>> Which outputs a human-readable format.
>>
>> However, if I want something more suitable for machine parsing, is
>> there any way to get that output?
>>
>> Example maybe I want another date format like ISO dates, or maybe a
>> serializable format like JSON or CSV or something. Maybe I want more
>> data than commit, auhor, date, subject and body?
>
> "git cat-file commit " should give you a machine-readable
> format of everything (it's the same thing that git-log parses and
> shows you; not counting options like --diff, --stat...). 
> is from rev-list output (without --pretty, that's not for machine
> processing). You probably can use "git cat-file --batch" too, just
> pipe the whole rev-list output through it. You don't get to choose a
> convenient format this way though.
> --
> Duy

Re: Feature request: --format=json

[Duy Nguyen]

On Mon, Apr 17, 2017 at 7:44 PM, Fred .Flintstone  wrote:
> So I did "git rev-list --all --pretty" and it looks like "git log".
> Which outputs a human-readable format.
>
> However, if I want something more suitable for machine parsing, is
> there any way to get that output?
>
> Example maybe I want another date format like ISO dates, or maybe a
> serializable format like JSON or CSV or something. Maybe I want more
> data than commit, auhor, date, subject and body?

"git cat-file commit " should give you a machine-readable
format of everything (it's the same thing that git-log parses and
shows you; not counting options like --diff, --stat...). 
is from rev-list output (without --pretty, that's not for machine
processing). You probably can use "git cat-file --batch" too, just
pipe the whole rev-list output through it. You don't get to choose a
convenient format this way though.
-- 
Duy

Re: Feature request: --format=json

[Fred .Flintstone]

So I did "git rev-list --all --pretty" and it looks like "git log".
Which outputs a human-readable format.

However, if I want something more suitable for machine parsing, is
there any way to get that output?

Example maybe I want another date format like ISO dates, or maybe a
serializable format like JSON or CSV or something. Maybe I want more
data than commit, auhor, date, subject and body?

On Mon, Apr 17, 2017 at 2:38 AM, Junio C Hamano  wrote:
> Ævar Arnfjörð Bjarmason  writes:
>
>> On Sat, Apr 8, 2017 at 6:07 PM, Fred .Flintstone  wrote:
>>> $ git log --format=json
>>> [{
>>> "commit": "64eabf050e315a4c7a11e0c05ca163be7cf9075e",
>>> "tree": "b1e977800f40bbf6de906b1fe4f2de4b4b14f0fd",
>>> "author": "Tux  1490981516 +0200",
>>> "committer": "Tux  1490981516 +0200",
>>> "message": "This is a test commit",
>>> "long_message": "This explains in more details the commit"
>>> }]
>>>
>>> This would make it easy to parse the output.
>>
>> The git-log command isn't plumbing that's meant for machines, but the
>> git-for-each-ref command is what you're most likely looking for.
>
> They are apples and oranges.  log is about traversing the history.
> "for-each-ref" is about listing the tips of refs.  It doesn't and it
> shouldn't traverse the history.
>
> The plumbing to use when you want to reimplement "git log" lookalike
> is "rev-list".

Re: Feature request: --format=json

[Junio C Hamano]

Ævar Arnfjörð Bjarmason  writes:

> On Sat, Apr 8, 2017 at 6:07 PM, Fred .Flintstone  wrote:
>> $ git log --format=json
>> [{
>> "commit": "64eabf050e315a4c7a11e0c05ca163be7cf9075e",
>> "tree": "b1e977800f40bbf6de906b1fe4f2de4b4b14f0fd",
>> "author": "Tux  1490981516 +0200",
>> "committer": "Tux  1490981516 +0200",
>> "message": "This is a test commit",
>> "long_message": "This explains in more details the commit"
>> }]
>>
>> This would make it easy to parse the output.
>
> The git-log command isn't plumbing that's meant for machines, but the
> git-for-each-ref command is what you're most likely looking for.

They are apples and oranges.  log is about traversing the history.
"for-each-ref" is about listing the tips of refs.  It doesn't and it
shouldn't traverse the history.

The plumbing to use when you want to reimplement "git log" lookalike
is "rev-list".

Re: Feature request: Configurable branch colors in git status --short --branch

[Jeff King]

On Sat, Apr 15, 2017 at 01:00:51PM -0700, Stephen Kent wrote:

> It would be nice if the branch, remote tracking branch, and branch commit
> comparison count colors in git status --short --branch were configurable
> like the other git status colors.

That seems like a reasonable thing to want.

I think the infrastructure is all there, and it would just need an
update to builtin/commit.c:parse_status_slot() to map the color.status.*
names into the {LOCAL,REMOTE}_BRANCH enum values.

Want to try your hand at a patch?

-Peff

Re: Feature request: --format=json

[Ævar Arnfjörð Bjarmason]

On Sat, Apr 8, 2017 at 6:07 PM, Fred .Flintstone  wrote:
> $ git log --format=json
> [{
> "commit": "64eabf050e315a4c7a11e0c05ca163be7cf9075e",
> "tree": "b1e977800f40bbf6de906b1fe4f2de4b4b14f0fd",
> "author": "Tux  1490981516 +0200",
> "committer": "Tux  1490981516 +0200",
> "message": "This is a test commit",
> "long_message": "This explains in more details the commit"
> }]
>
> This would make it easy to parse the output.

The git-log command isn't plumbing that's meant for machines, but the
git-for-each-ref command is what you're most likely looking for.

It doesn't have JSON output, but you can make e.g. --format emit
something even more easily parsable, e.g. a version of what you have
with each field delimited by a custom delimiter, and then split on
that.

It does have --perl, --tcl etc. options to make it easy to quote the
fields, however there's no logic to manage the state machine JSON
would need to omit trailing commas, whereas emitting output for
languages like Perl where trailing commas don't matter is much easier.

Fwd: Re: feature request: user email config per domain

[Igor Djordjevic]

Forwarding a message that ended on my end only, probably by accident.

 Forwarded Message 
Subject: Re: feature request: user email config per domain
Date: Thu, 23 Feb 2017 13:32:56 +0530
From: Tushar Kapila <tgkp...@gmail.com>
To: Igor Djordjevic BugA <igor.d.djordje...@gmail.com>

Hello All,
> I'd much rather see something based on the working tree path, like
Duy's conditional config includes. Then you write something in your
~/.gitconfig

> This would allow you to have two root directories, one for your work
projects and one for open source projects (for example).

I guess this can be extended for any number of root directories. Like,
when a consultant has multiple employer email ids.

This sounds great and it would enforce at commit time, which as
pointed out, is the correct time to do it. If for some reason it is
not adopted I at least hope that we have a simple global config which
specifies that user must set email for each repo and to ignore any
global config.

Am sure this can be done via hooks, but I would like something that is
really simple for newbies and companies to enforce with minimal
instruction.

* Will try what Igor and Grant Humphries suggests.

* Thank you all for your replies, and a big thank you for git - its a
great tool. I used to dream of something like it when I was stuck with
svn (pre 2010 I was introduced to git late.)


[1] http://stackoverflow.com/a/42354282
[2] http://stackoverflow.com/users/2167004

Re: feature request: user email config per domain

[Igor Djordjevic BugA]

Hi Tushar,

On 22/02/2017 14:12, Tushar Kapila  wrote:
> So when remote URL has github.com push as tgkp...@search.com but for
> testing.abc.doman:8080 use tgkp...@test.xyz.com ?

I`m not sure if this is sensible, as authorship information is baked
into the commit at the time of committing, which (usually ;) happens
before you get to 'git push' to the other repo.

If possible, changing this info after the fact, on 'git push', would
influence the existing commit you`re trying to send over, so your
'git-push' would have a surprising consequence of not actually
pushing your desired commit at all, but creating a totally new commit
inside the other repo -- this new commit would be exactly the same
patch-wise (in regards to differences introduced), but because of the
changed user info it would be considered a different commit
nonetheless (different hash).

> ... I know I can over ride it per repository, but sometimes
> forget to do that. And even if I unset it, it inadvertantly gets set
> elsewhere when I make a repo and the site 'helps' me by showing me the
> commands to init and clone my new repo.

Otherwise, as you already stated that you find the current local (per
repo) user settings override logic inconvenient (error-prone), you
might be interested in approach described in this[1] Stack Overflow
post.

In short, it uses a template-injected 'post-checkout' hook (triggered
on 'git clone' as well) alongside '.gitconfig' (global) settings to
achieve what seems to be pretty similar to what you asked for (but
might be a bit more sensible), where you may fine-tune it further to
better suit your needs.

On 20/02/2017 21:12, Grant Humphries[2] wrote[1]:
> This answer is partially inspired by the post by @Saucier, but I was
> looking for an automated way to set user.name and user.email on a per
> repo basis, based on the remote, that was a little more light weight
> than the git-passport package that he developed. Also h/t to @John
> for the useConfigOnly setting. Here is my solution:
>
> .gitconfig changes:
>
>   [github]
>   name = 
>   email = 
>   [gitlab]
>   name = 
>   email = 
>   [init]
>   templatedir = ~/.git-templates
>   [user]
>   useConfigOnly = true
>
> post-checkout hook which should be saved to the following path:
> ~/.git-templates/hooks/post-checkout:
>
>   #!/usr/bin/env bash
>   
>   # make regex matching below case insensitive
>   shopt -s nocasematch
>   
>   # values in the services array should have a corresponding section in
>   # .gitconfig where the 'name' and 'email' for that service are specified
>   remote_url="$( git config --get --local remote.origin.url )"
>   services=(
>   'github'
>   'gitlab'
>   )
>   
>   set_local_user_config() {
>   local service="${1}"
>   local config="${2}"
>   local service_config="$( git config --get ${service}.${config} 
> )"
>   local local_config="$( git config --get --local user.${config} 
> )"
>   
>   if [[ "${local_config}" != "${service_config}" ]]; then
>   git config --local "user.${config}" "${service_config}"
>   echo "repo 'user.${config}' has been set to 
> '${service_config}'"
>   fi
>   }
>   
>   # if remote_url doesn't contain the any of the values in the services
>   # array the user name and email will remain unset and the
>   # user.useConfigOnly = true setting in .gitconfig will prompt for those
>   # credentials and prevent commits until they are defined
>   for s in "${services[@]}"; do
>   if [[ "${remote_url}" =~ "${s}" ]]; then
>   set_local_user_config "${s}" 'name'
>   set_local_user_config "${s}" 'email'
>   break
>   fi
>   done
>
> I use different credentials for github and gitlab, but those
> references in the code above could be replaced or augmented with any
> service that you use. In order to have the post-checkout hook
> automatically set the user name and email locally for a repo after a
> checkout make sure the service name appears in the remote url, add it
> to the services array in the post-checkout script and create a
> section for it in your .gitconfig that contains your user name and
> email for that service.
>
> If none of the service names appear in the remote url or the repo
> doesn't have a remote the user name and email will not be set
> locally. In these cases the user.useConfigOnly setting will be in
> play which will not allow you to make commits until the user name and
> email are set at the repo level, and will prompt the user to
> configure that information.

Regards,
Buga

*P.S.* For the purpose of completeness and archiving I copied the
Stack Overflow post[1] here as well, but all the credits 

Re: feature request: user email config per domain

[Jeff King]

On Wed, Feb 22, 2017 at 06:42:02PM +0530, Tushar Kapila wrote:

> Feature request :  can we have a config for email per repo domain ?
> Something like:
> 
> git config --global domain.user.email tgkp...@test.xyz.com
> testing.abc.doman:8080
> 
> git config --global domain.user.email tgkp...@xyz.com abc.doman:80
> 
> git config --global domain.user.email tgkp...@search.com github.com
> 
> So when remote URL has github.com push as tgkp...@search.com but for
> testing.abc.doman:8080 use tgkp...@test.xyz.com ?

The idea of "the domain for this repo" doesn't really match Git's
distributed model. A repo may have no remotes at all, or multiple
remotes with different domains (or even remotes which do not have a
domain associated with them, like local files, or remote helpers which
obscure the domain name).

It sounds like you're assuming that the domain would come from looking
at remote.origin.url. Which I agree would work in the common case of
"git clone https://example.com;, but I'm not comfortable with the number
of corner cases the feature has.

I'd much rather see something based on the working tree path, like Duy's
conditional config includes. Then you write something in your
~/.gitconfig like:

  [include "gitdir:/home/peff/work/"]
  path = .gitconfig-work

  [include "gitdir:/home/peff/play/"]
  path = .gitconfig-play

and set user.email as appropriate in each.

You may also set user.useConfigOnly in your ~/.gitconfig. Then you'd
have to set user.email in each individual repository, but at least Git
would complain and remind you when you forget to do so, rather than
silently using the wrong email.

-Peff

Re: feature request: user email config per domain

[Andrew Ardill]

On 23 February 2017 at 00:12, Tushar Kapila  wrote:
> I can set my email via:
> git config --global user.email tgkp...@xyz.dom
>
> this is dangerous when I use this my office or in a multi repository
> provider environment where my email is different for a few (like
> tgkp...@search.com for github and tus...@mycompany.com for my company
> private repo).

There has been a large discussion around this idea before, see this
thread for example [0].

The proposed idea was to have something set in your global config that
would only be turned on if you were within a given directory. This
would allow you to have two root directories, one for your work
projects and one for open source projects (for example) and any git
repositories within those folders would each would have their own
config options automatically applied based on their location.

There was a patch suggested, and it worked quite well, but nothing
further has been done to my knowledge.

[0] http://public-inbox.org/git/7vvc3d1o01@alter.siamese.dyndns.org/

Regards,

Andrew Ardill

Re: feature request: user email config per domain

[Pranit Bauva]

Hey Tushar,

When you run `git config --global user.email a...@xyz.com` it writes
out this setting in ~/.gitconfig which is then considered to be
"global" ie. this same email will be used for every repo, but ...

You can always override this. Let's say there is a repo named "foo" in
which you want the email "x...@abc.com", then you go inside that folder
and type `git config user.email x...@abc.com`. Note: the option
`--global` is skipped here. This creates a file `.gitconfig` in the
folder "foo" and now whenever you commit, the .gitconfig file inside
the repo will get the first preference and then the global
~/.gitconfig.

This will work for you assuming that you have different repos for your
company and for your open source work. Will this solve your problem?

Regards,
Pranit Bauva

Re: Feature request: flagging “volatile” branches for integration/development

[Junio C Hamano]

"Herbert, Marc"  writes:

>> The hard part may be policy (e.g. what if the user does not want a branch
>> to be treated volatile by various commands even if it receives such
>> flag from a git server).
>
> There would be instant, human-readable value in such a new "volatile"
> flag. Machine use and policies can be discussed later. These will be
> easier to prototype, experiment and refine once the flag exists.

We tend to avoid adding random cruft to the system whose semantics
is not well defined, so that we can avoid having to support an ill
defined feature forever.

> ... Now I bet this on the other hand must have been
> discussed (and rejected?) before, any pointer?

I suspect that people may have expressed vague wish from time to
time, but I do not think we saw a proposal that outlines the design
at a concrete enough level to let us rejecting in the past ;-)

Let me list some things that needs to be designed that comes to my
mind offhand:

 * How would a user mark a ref as "volatile"?  I am assuming that
   anybody do so in her own local repository, but how does one mark
   a ref as "volatile" at a hosting site, and who is allowed to do
   so (one possibile design is "new option to 'git push' will do so,
   and anybody who can push to the ref is allowed to", and I am fine
   with that design, but you have to spell that out in a proposal)?

 * How would a user learn if a ref is "volatile"?  Does "ls-remote"
   show that information?

 * Does volatile-ness of a ref at the remote site propagate to your
   remote-tracking ref that corresponds to it?  What does it mean
   that refs/remotes/origin/pu is marked as volatile in your local
   repository?  You cannot "checkout -b" based on it?  Does "branch"
   based on it need to be forbidden as well?

 * Can a local ref be "volatile"?  What does it mean (the same
   subquestions as above)?

 * If your local branch myA is set to build on a remote-tracking
   branch A and push back to branch A at the remote, i.e.

$ git checkout -t -b myA refs/remotes/origin/A
$ ... work work work ...
$ git push

   is set to result in their branch A updated with what you built in
   myA, and if the branch A at the remote is marked as "volatile",
   does it make your "myA" also "volatile"?  How is the volatile-ness 
   inherited?  From their A to your remotes/origin/A and then to
   your myA?  Any other useful rule that defines the propagation?

 * Do we only care about "volatile"?  If we are extending the system
   to allow setting and propagating this new bit per ref (I am
   blindly assuming that you do not have a strong reason to limit
   this to branches), we may as well just design this extension to
   allow the projects to assign arbitrary set of bits to refs.  Some
   projects may want to have different degree of volatile-ness and
   have "volatile" refs, "unstable" refs and "iffy" refs, for
   example.

   Side note: even if we were to go with "any random label can be
   assigned and the meaning for the labels can be defined by the
   project convention" approach, it does not necessarily mean we are
   adding a random cruft whose semantics is ill-defined.  "Git does
   not do anything special to a ref based on what labels it has--it
   just remembers what labels the user told it to attach to the ref,
   and shows what labels the ref has when asked" can be very well
   defined semantics.

Re: Feature request: flagging “volatile” branches for integration/development

[Herbert, Marc]

[apologies for the accidental "smart" quotes and the resulting UTF8
encoding of the subject]

On 04/02/2017 06:01, Duy Nguyen wrote:
> 
> But that would be local information only. We don't have ways to
> transfer branch metadata (and we definitely don't want to just share
> .git/config file with everybody). I suppose extending git protocol for
> this is not hard (e.g. appending metadata in the "have" lines).

Thanks Duy. So did you mean:

[ X ] send (big!) patches ?

> The hard part may be policy (e.g. what if the user does not want a branch
> to be treated volatile by various commands even if it receives such
> flag from a git server).

There would be instant, human-readable value in such a new "volatile"
flag. Machine use and policies can be discussed later. These will be
easier to prototype, experiment and refine once the flag exists.

  

Interestingly, it was pointed to me (thanks Calvin) that GitLab has
implemented this volatile flag exactly. It's called... "work in progress":
https://docs.gitlab.com/ee/user/project/merge_requests/work_in_progress_merge_requests.html

I'm not familiar with GitHub, however browsing its documentation the
(in)existence of a pull request seems equivalent to a (non-)volatile
flag. Just like a pull request by email without the need to find and search
a mailing-list.

I'm familiar with Gerrit and there's no strict equivalent to a volatile
flag, however it's:
- totally obvious when the commit has been accepted and merged - hence
  its SHA1 final.
- usually fairly clear whether the code is still WIP or near the
  "pull request" stage based on: how the code review is going, approvals
  and other metadata.

Long story short: to integrate code reviews and source control these
systems overload git with a ton of metadata so it's no surprise to
always find in them something that more or less looks like a "volatile"
flag. I guess this leads to the more general question of core git possibly
implementing some generic metadata/property system (key,value pairs?
everything is a ref?) to better support code review and other
git-based software... Now I bet this on the other hand must have been
discussed (and rejected?) before, any pointer?


Marc

Re: feature request: add -q to "git branch"

[Kevin Layer]

I think I got my git versions (old and new) mixed up.  Sorry for the noise.

On Sat, Feb 4, 2017 at 1:17 PM, Pranit Bauva  wrote:
> Hey Kevin,
>
> Sorry for the previous message.
>
> On Sun, Feb 5, 2017 at 2:47 AM, Pranit Bauva  wrote:
>> Hey Kevin,
>>
>> On Fri, Feb 3, 2017 at 11:59 PM, Kevin Layer  wrote:
>>> It should be possible to quietly create a branch.
>
> I think `git branch` is already quiet. Are you seeing something else?
>
> Regards,
> Pranit Bauva

Re: feature request: add -q to "git branch"

[Pranit Bauva]

Hey Kevin,

Sorry for the previous message.

On Sun, Feb 5, 2017 at 2:47 AM, Pranit Bauva  wrote:
> Hey Kevin,
>
> On Fri, Feb 3, 2017 at 11:59 PM, Kevin Layer  wrote:
>> It should be possible to quietly create a branch.

I think `git branch` is already quiet. Are you seeing something else?

Regards,
Pranit Bauva

Re: feature request: add -q to "git branch"

[Pranit Bauva]

Hey Kevin,

On Fri, Feb 3, 2017 at 11:59 PM, Kevin Layer  wrote:
> It should be possible to quietly create a branch.
>
> Thanks.
>
> Kevin

Re: Feature request: flagging “volatile” branches for integration/development

[Duy Nguyen]

On Wed, Feb 1, 2017 at 12:12 AM, Herbert, Marc  wrote:
> (Thanks to Josh Triplett[*] for contributing to this message)
>
> Hi,
>
> We often work with development/integration branches that regularly
> rebase, in addition to stable branches that do not. Git is used to share
> two different types of branches:
>   1. Pull requests and merged code with final SHA1s
>   2. Work in progress with volatile SHA1s.
>
> We’d like to have a consistent way to distinguish these two types by
> advertising a branch as “volatile”.

I don't think we have branch metadata (besides reflog). The closet one
is probably config variable branch..description, which can be
picked up by format-patch to create cover letters. We could do
something similar, e.g. new config branch..volatile. The
commands can learn about it and apply special treatments if wanted.

But that would be local information only. We don't have ways to
transfer branch metadata (and we definitely don't want to just share
.git/config file with everybody). I suppose extending git protocol for
this is not hard (e.g. appending metadata in the "have" lines). The
hard part may be policy (e.g. what if the user does not want a branch
to be treated volatile by various commands even if it receives such
flag from a git server).
-- 
Duy

Re: feature request: allow to stash changed files

[Thomas Gummerer]

On 01/15, KES wrote:
> http://stackoverflow.com/questions/3040833/stash-only-one-file-out-of-multiple-files-that-have-changed-with-git#comment32451416_3040833
> 
> Sometimes poople are forced to save stash for changed files. But there is no 
> such option (

You may just be lucky.  I've been wishing for something like that for
a while now as well, and finally got around to write a patch this
weekend.

Re: Feature request: git rebase --no-edit --continue

[Daniel Chumak]

Uff, I forgot about the CC of my last reply.


Why not

git commit -C HEAD && git rebase --continue

?

Ciao,
Johannes
Thanks this is a cleaner solution. I guess because I was too fixed upon 
knowing of the existence of the no-edit option from other git commands 
that I forget about this, even though I am using it quite often.

Re: Feature request: git rebase --no-edit --continue

[Johannes Schindelin]

Hi Daniel,

On Thu, 22 Dec 2016, Daniel Chumak wrote:

> Is there a reason why there is no '--no-edit' option for git rebase? I would
> like to use this option after editing a commit and continuing the current
> interactive rebase without having to change the commit message.

Why not

git commit -C HEAD && git rebase --continue

?

Ciao,
Johannes

Re: Feature request: git rebase --no-edit --continue

[Stefan Beller]

On Thu, Dec 22, 2016 at 2:35 PM, Daniel Chumak
 wrote:
> Is there a reason why there is no '--no-edit' option for git rebase?

Nobody added it so far.

> I would
> like to use this option after editing a commit and continuing the current
> interactive rebase without having to change the commit message.
>

You're welcome to write a patch for it. :)

On the other hand you could just use
EDITOR=true git rebase --continue

Re: Feature request: read git config from parent directory

[Dominique Dumont]

On Friday, 9 December 2016 19:38:05 CET Duy Nguyen wrote:
> >> Sounds like the same problem I have (and the reason I came up with
> >> conditional include [1]). Would that work for you (check out the
> >> example part in that patch)?
> > 
> > If I understand correcly, I would need to set up config include in each
> > git
> > repository. This is as much work as setting up user.email in the same
> > place.
> 
> Well, no. You set this up in ~/.gitconfig. If you need to add some
> settings in /abc/def/.gitconfig and expect repositories in this path
> to reach it via the parent chain, then you could write something like
> 
> [include "gitdir:/abc/def/"]
> file = your-config-file
> 
> in ~/.gitconfig and achieve the same effect, because all repos will
> read ~/.gitconfig, and if it finds out the repo's location is inside
> /abc/def, your-config-file will be loaded. It could contain email
> settings or whatever.
> 
> So, instead of spreading .gitconfig files around and relying on
> parent-chain to reach them, you write a few filter rules in
> ~/.gitconfig to tell all the repos what to load.

oh... yes, that would solve my problem and have no impact on other user who 
don't need this feature. 

I do hope that the improvement you proposed will be merged.

Thanks for the explanation.

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Re: Feature request: read git config from parent directory

[Duy Nguyen]

On Fri, Dec 9, 2016 at 2:49 AM, Dominique Dumont  wrote:
> Hello
>
> I use the same machine for work and open-source contribution. In both cases, I
> deal with a lot of repositories. Depending on whether I commit for work or
> open-source activities, I must use a different mail address. I used to setup
> work address for each work repo in git local config, but this is no longer
> practical.

Sounds like the same problem I have (and the reason I came up with
conditional include [1]). Would that work for you (check out the
example part in that patch)?

It's not supported yet. I'll need to address a few comments in the
future reroll.

[1] http://public-inbox.org/git/20160712164216.24072-1-pclo...@gmail.com/

> Since I use different directories for work and open-source, would it be
> possible for git to read irs config also from parent directories ? I.e. setup
> git to read config from ./.git/config then ../.gitconfig, ../../gitconfig 
> until
> global ~/.gitconfig.
-- 
Duy

Re: Re: Feature request: Set git svn options in .git/config file

[Juergen Kosel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hello,

Am 05.12.2016 um 23:54 schrieb Eric Wong:
> So, can you confirm that svn.addAuthorFrom and svn.useLogAuthor 
> config keys work and can be documented?

yes, I can confirm, that adding this configuration keys works with git
2.1.4 work.
I have added the config keys as follows:

git config --add --bool svn.useLogAuthor true
git config --add --bool svn.addAuthorFrom true

> 
> Even better would be for you to provide a patch to the 
> documentation :) Otherwise, I can write one up sometime this week.

My English is not that well. So I prefer, if you update the
documentation :-)


Greetings
Juergen


-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iD8DBQFYRvRhYZbcPghIM9IRAjtHAJ0QaqbUxcgoPXmidIg9WALXmg1JAQCfTHFj
wgPLKXK5Ny0bP/K9vpE9KzY=
=A+Yy
-END PGP SIGNATURE-

Re: Feature request: Set git svn options in .git/config file

[Eric Wong]

Juergen Kosel  wrote:
> Therefore I believe, that it would be the best solution to store the
> settings of --add-author-from, --use-log-author and maybe
> --authors-prog in the .git/config file.

Actually, "svn.authorsProg" is already documented as a config
option for --authors-prog.

It's been a while since I looked at this, but in git-svn,
all the "--xxx-yyy" command-line options should be available
under the appropriate "svn.xxxYyy" config key.

So, can you confirm that svn.addAuthorFrom and svn.useLogAuthor
config keys work and can be documented?

Even better would be for you to provide a patch to the
documentation :)
Otherwise, I can write one up sometime this week.

Thanks.

Re: [feature request] Make "commit --only" work with new files

[Junio C Hamano]

Luis Ressel  writes:

> currently "git commit --only " only works if  is already
> checked into the repo, but not with newly created and still untracked
> files (builtin/commit.c:list_path() throws the error "error: pathspec
> '' did not match any file(s) known to git.")

The fact that pathspec on the command line of "commit" does not let
you add new files is true with or without "--only".  Yes, "--only"
is the default so with or without it it means the same thing, but
even with "--include" that says "I am happy with what is in the
index, but please take further changes to these paths, too" does not
affect files that are not so far tracked.

> I don't think this limitation is intented. 

This actually was intended.  Back when "commit [--opts] "
was invented, out tools were designed to avoid adding unwanted files
by mistake (e.g. "update-index" without an explicit "--add" work
only on paths already known to Git), and the behaviour is in line
with that design.  It partly was because back then we didn't even
have ".gitignore" mechanism, I would say.  So it was not only
intended, but was a sensible design decision back then.

I suspect that an argument could be made that it is about time we
shift the design philosophy and allow adding new paths with pathspec
given to "git commit".  If I were designing Git without any existing
users, with all the other goodies we already have, and "git commit"
in my version of Git lacked pathspec support now, I might allow it
to add untracked files with the pathspec [*1*].

There however are backward compatibility worries.  People who are
used to the designed behaviour for the past 10 years still expect
and rely on that

$ git commit 

to take _only_ changes to the files that are already tracked in the
 since the last "git add" they did to them, and other
files in the same  that are not yet ready (and they
deliberately left un-added) will not be in the commit.


[Footnote]

*1* I might decide not to, after thinking long enough, though. The
point is that times changed and the trade off between safetly of
not adding at the point of commit and convenience of adding has
shifted. I haven't thought enough to decide that the shift is
big enough to warrant the change in behaviour, but at least it
is now worth considering.

Re: [feature request] Make "commit --only" work with new files

[Johannes Schindelin]

Hi Luis,

On Fri, 25 Nov 2016, Luis Ressel wrote:

> currently "git commit --only " only works if  is already
> checked into the repo, but not with newly created and still untracked
> files (builtin/commit.c:list_path() throws the error "error: pathspec
> '' did not match any file(s) known to git.")
> 
> I don't think this limitation is intented. I've had a look at the
> relevant part of builtin/commit.c, but unfortunately it wasn't obvious
> to me how to fix this.

The best way to go about it is probably to define the desired behavior
first, in the form of a patch to the test suite. Personally, I would
extend t/t7509-commit.sh with a new test case.

Then, once you have that test case (that should be marked with
test_expect_failure, because it fails for now), you can use a debugger
such as gdb to single-step into the relevant function (I guess
"prepare_index()" is a good candidate) to find out why the files are not
added.

>From there, it should be easier to figure out what to patch, and how.

Good hunting!
Johannes

Re: Feature request: Improve diff algorithm

[Jacob Keller]

On Mon, Nov 21, 2016 at 10:17 AM, Stefan Beller  wrote:
> On Mon, Nov 21, 2016 at 8:56 AM, Jacob Keller  wrote:
>> On Mon, Nov 21, 2016 at 12:11 AM, KES  wrote:
>>> Hi.
>>>
>>
>> Hi,
>>
>>> I have some question about how diff works then give proposal:
>>>
>>> it will be very useful for each "symbol" store additional meta info as 
>>> source line length. So in this case when git counter two equal sequence of 
>>> commands it will do further comparison: Adds 23 chars deletes none VS adds 
>>> 75 chars deletes 46
>>>
>>> Actually I got this:
>>>
>>> @@ -129,8 +132,9 @@ sub _preprocess_message {
>>>  sub _process_message {
>>>  my ($self, $message) = @_;
>>>
>>> -my $method = ref($message) eq 'HASH' ? $message->{method} : undef;
>>> +my $time =  [ gettimeofday ];
>>>
>>> +my $method = ref($message) eq 'HASH' ? $message->{method} : undef;
>>>  return $self->send_error(ERROR_REQUEST_INVALID)
>>>  unless defined($method);
>>>
>>> Instead of expected:
>>> @@ -129,6 +132,8 @@ sub _preprocess_message {
>>>  sub _process_message {
>>>  my ($self, $message) = @_;
>>>
>>> +my $time =  [ gettimeofday ];
>>> +
>>>  my $method = ref($message) eq 'HASH' ? $message->{method} : undef;
>>> -
>>>  return $self->send_error(ERROR_REQUEST_INVALID)
>>>
>>
>> Have you tried the various options for git to search for smaller
>> diffs? Or using the other diff algorithms such as histogram instead of
>> patience?
>>
>
> The newest version of Git comes with a flag to move around the diff
> better, based on the work at https://github.com/mhagger/diff-slider-tools

Unfortunately in this case, I'm not convinced that it will improve the
diff. It's worth a try as well though.

Thanks,
Jake