Stefan Beller <stefanbel...@googlemail.com> writes:
> Well if we make sure the whatchanged command can easily be reproduced
> with the log command, we could add the missing parameters to it, hence
> no change for the user. (git whatchanged == git log --raw --no-merges or
> git log --wc [to be done yet]).
>
> So I did not mean to introduce a change for users!
I certainly did *not* read that from between the lines of what you
wrote:
+ int cmd_whatchanged(int argc, const char **argv, const char *prefix)
+ {
+ return cmd_log(argc, argv, prefix)
+ }
In principle, I agree that it is a good idea to try to share enough
code, while keeping the flexiblity and clarity of the code for
maintainability.
In the extreme, you could rewrite these two functions like so:
static int cmd_lw_helper(
int argc, const char **argv,
const char *prefix,
int whoami)
{
struct rev_info rev;
struct setup_revision_opt opt;
init_grep_defaults();
git_config(git_log_config, NULL);
init_revisions(&rev, prefix);
if (whoami == 'l') { /* log */
rev.always_show_header = always_show_header;
} else { /* whatchanged */
rev.diff = diff;
rev.simplify_history = simplify_history;
}
memset(opt, 0, sizeof(opt));
opt.def = "HEAD";
opt.revarg_opt = REVARG_COMMITTISH;
cmd_log_init(argc, argv, prefix, &rev, &opt);
if (whoami == 'w') {
if (!rev.diffopt.output_format)
rev.diffopt.output_format = DIFF_FORMAT_RAW;
}
return cmd_log_walk(&rev);
}
int cmd_log(int argc, const char **argv, const char *prefix)
{
return cmd_lw_helper(argc, argv, prefix, 'l');
}
int cmd_whatchanged(int argc, const char **argv, const char *prefix)
{
return cmd_lw_helper(argc, argv, prefix, 'w');
}
but at that point, the cost you have to pay when you need to update
one of them but not the other becomes higher.
As whatchanged is kept primarily for people who learned Git by word
of mouth reading the kernel mailing list and are used to that
command. Its external interface and what it does is not likely to
drastically change. On the other hand, "log" is a primary Porcelain
and we would expect constant improvements.
Between the "share more code for reuse" and "keep the flexibility
and clarity for maintainability", it is a subtle balancing act.
Personally I think the current code strikes a good balance by not
going to the extreme, given that "change one (i.e. log) but not the
other" is a very likely pattern for the evolution of these two
commands.
--
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
