Re: [PATCH] log: add log.follow config option
Matthieu Moy matthieu@grenoble-inp.fr writes: David Turner dtur...@twopensource.com writes: Twitter's history is almost completely linear, so it's useful for us. Since it looks like the patch won't be useful outside of our context, I'll just rewrite it to check the pathspec count, and not upstream it until follow becomes more general. As long as it's an opt-in and that the documentation states the limitations clearly enough, I think it makes sense to me to have this upstream. Perhaps. But at least log -- 1 2 and log -- should not be broken for those that set the configuration. Unless you are counting these as also limitations, that is. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] log: add log.follow config option
David Turner dtur...@twopensource.com writes: Twitter's history is almost completely linear, so it's useful for us. Since it looks like the patch won't be useful outside of our context, I'll just rewrite it to check the pathspec count, and not upstream it until follow becomes more general. As long as it's an opt-in and that the documentation states the limitations clearly enough, I think it makes sense to me to have this upstream. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] log: add log.follow config option
On Wed, 2015-07-01 at 14:19 -0700, Junio C Hamano wrote: Matthieu Moy matthieu@grenoble-inp.fr writes: So activating --follow for all git log calls would prevent log from being used with several pathspecs. Or, do you have a preparation patch that allows --follow with multiple pathspecs? ;-) In any case, you have to test git log -- path1 path2 with the option activated. Or more commonly, just git log with no pathspec. I also think that it is a bad idea to force log --follow to people before it is made into a true feature; as it stands, it is merely a checkbox item. It has too severe limitation to be used seriously in real projects, unless your history is completely linear. cf. http://thread.gmane.org/gmane.comp.version-control.git/269357/focus=269433 Thanks. Twitter's history is almost completely linear, so it's useful for us. Since it looks like the patch won't be useful outside of our context, I'll just rewrite it to check the pathspec count, and not upstream it until follow becomes more general. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] log: add log.follow config option
Many users prefer to always use --follow with logs. Rather than
aliasing the command, an option might be more convenient for some.
Signed-off-by: David Turner dtur...@twopensource.com
---
Why not just alias log=log --follow?
At Twitter, we manage git config centrally, but we also allow users to
add their own aliases. We would like to turn log.follow on globally,
while not messing up any aliases users already have for log.
Also, some users might have different log aliases for different
repositories, but want to manage --follow globally.
And in the future, we might want to make log --follow the default (it
is what I usually want), so it would be nice to provide a way for
users to turn that off globally from a config option.
builtin/log.c | 7 +++
t/t4206-log-follow-harder-copies.sh | 23 +++
2 files changed, 30 insertions(+)
diff --git a/builtin/log.c b/builtin/log.c
index 8781049..11b8d82 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -31,6 +31,7 @@ static const char *default_date_mode = NULL;
static int default_abbrev_commit;
static int default_show_root = 1;
+static int default_follow = 0;
static int decoration_style;
static int decoration_given;
static int use_mailmap_config;
@@ -102,6 +103,8 @@ static void cmd_log_init_defaults(struct rev_info *rev)
{
if (fmt_pretty)
get_commit_format(fmt_pretty, rev);
+ if (default_follow)
+ DIFF_OPT_SET(rev-diffopt, FOLLOW_RENAMES);
rev-verbose_header = 1;
DIFF_OPT_SET(rev-diffopt, RECURSIVE);
rev-diffopt.stat_width = -1; /* use full terminal width */
@@ -390,6 +393,10 @@ static int git_log_config(const char *var, const char
*value, void *cb)
default_show_root = git_config_bool(var, value);
return 0;
}
+ if (!strcmp(var, log.follow)) {
+ default_follow = git_config_bool(var, value);
+ return 0;
+ }
if (skip_prefix(var, color.decorate., slot_name))
return parse_decorate_color_config(var, slot_name, value);
if (!strcmp(var, log.mailmap)) {
diff --git a/t/t4206-log-follow-harder-copies.sh
b/t/t4206-log-follow-harder-copies.sh
index ad29e65..6b2f3b9 100755
--- a/t/t4206-log-follow-harder-copies.sh
+++ b/t/t4206-log-follow-harder-copies.sh
@@ -53,4 +53,27 @@ test_expect_success \
'validate the output.' \
'compare_diff_patch current expected'
+test_expect_success \
+'git config log.follow works like --follow' \
+'test_config log.follow true
+ git log --name-status --pretty=format:%s path1 current'
+
+test_expect_success \
+'validate the output.' \
+'compare_diff_patch current expected'
+
+test_expect_success \
+'git config log.follow is overridden by --no-follow' \
+'test_config log.follow true
+ git log --no-follow --name-status --pretty=format:%s path1 current'
+
+cat expected \EOF
+Copy path1 from path0
+A path1
+EOF
+
+test_expect_success \
+'validate the output.' \
+'compare_diff_patch current expected'
+
test_done
--
2.0.5.499.g01f6352.dirty-twtrsrc
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] log: add log.follow config option
David Turner dtur...@twopensource.com writes:
diff --git a/builtin/log.c b/builtin/log.c
index 8781049..11b8d82 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -31,6 +31,7 @@ static const char *default_date_mode = NULL;
static int default_abbrev_commit;
static int default_show_root = 1;
+static int default_follow = 0;
static int decoration_style;
static int decoration_given;
static int use_mailmap_config;
@@ -102,6 +103,8 @@ static void cmd_log_init_defaults(struct rev_info *rev)
{
if (fmt_pretty)
get_commit_format(fmt_pretty, rev);
+ if (default_follow)
+ DIFF_OPT_SET(rev-diffopt, FOLLOW_RENAMES);
Doesn't it activate --follow all the time, including when the user
provides several paths?
In this case, you get this:
$ git log --follow *.c
fatal: --follow requires exactly one pathspec
So activating --follow for all git log calls would prevent log from
being used with several pathspecs.
Or, do you have a preparation patch that allows --follow with multiple
pathspecs? ;-)
In any case, you have to test git log -- path1 path2 with the option
activated.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] log: add log.follow config option
Matthieu Moy matthieu@grenoble-inp.fr writes: So activating --follow for all git log calls would prevent log from being used with several pathspecs. Or, do you have a preparation patch that allows --follow with multiple pathspecs? ;-) In any case, you have to test git log -- path1 path2 with the option activated. Or more commonly, just git log with no pathspec. I also think that it is a bad idea to force log --follow to people before it is made into a true feature; as it stands, it is merely a checkbox item. It has too severe limitation to be used seriously in real projects, unless your history is completely linear. cf. http://thread.gmane.org/gmane.comp.version-control.git/269357/focus=269433 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
