Daniel Barkalow [off-list ref] writes:
I like this idea a lot. I'd actually also like it for commit, although (1)
and (3a) obviously don't happen there. It would help to combat my tendency
to forget to push when I mean to.
Thanks.
quoted
+/*
+ * We really should allow cb_data... Yuck
+ */
+static const char *branch_name;
+static int branch_name_len;
+static char *found_remote;
+static char *found_merge;
+static int read_branch_config(const char *var, const char *value)
+{
...
I think you want branch_get(), which handles all the config file stuff up
to approximately here:
Fixups are very much welcomed. This was more or less a proof of
concept.
quoted
+ if (show_log) {
+ const char *args[32];
+ int ac;
+
+ ac = 0;
+ args[ac++] = "log";
+ args[ac++] = "--pretty=oneline";
+ args[ac++] = "--abbrev-commit";
+ args[ac++] = "--left-right";
+ args[ac++] = "--boundary";
+ args[ac++] = symmetric;
+ args[ac++] = "--";
+ args[ac] = NULL;
+
+ run_command_v_opt(args, RUN_GIT_CMD);
We really should be able to do this in-process, although I'm not sure if
we really can.
The code runs in_merge_bases() twice, between our branch head
and the base, but if we really care about the performance, we
can have a single merge-base traversal and the resulting object
pool will have everything necessary to emit the log output
without a separate traversal.
Because I think that is reasonably easy, I just did not bother
to. This is not a performance critical piece of code anyway.
One thing I thought about was to limit the output to latest N
entries from both sides. That would also be easier to implement
if we do a single merge-base traversal and reuse the result.
On Sat, 16 Feb 2008, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
I like this idea a lot. I'd actually also like it for commit, although (1)
and (3a) obviously don't happen there. It would help to combat my tendency
to forget to push when I mean to.
Thanks.
quoted
quoted
+/*
+ * We really should allow cb_data... Yuck
+ */
+static const char *branch_name;
+static int branch_name_len;
+static char *found_remote;
+static char *found_merge;
+static int read_branch_config(const char *var, const char *value)
+{
...
I think you want branch_get(), which handles all the config file stuff up
to approximately here:
Fixups are very much welcomed. This was more or less a proof of
concept.
I'm also in part worried about the lack of publicity "struct branch" has
gotten; it would have saved you having to write 64 of 136 lines, so it's
worth you knowing about.
quoted
quoted
+ if (show_log) {
+ const char *args[32];
+ int ac;
+
+ ac = 0;
+ args[ac++] = "log";
+ args[ac++] = "--pretty=oneline";
+ args[ac++] = "--abbrev-commit";
+ args[ac++] = "--left-right";
+ args[ac++] = "--boundary";
+ args[ac++] = symmetric;
+ args[ac++] = "--";
+ args[ac] = NULL;
+
+ run_command_v_opt(args, RUN_GIT_CMD);
We really should be able to do this in-process, although I'm not sure if
we really can.
The code runs in_merge_bases() twice, between our branch head
and the base, but if we really care about the performance, we
can have a single merge-base traversal and the resulting object
pool will have everything necessary to emit the log output
without a separate traversal.
Because I think that is reasonably easy, I just did not bother
to. This is not a performance critical piece of code anyway.
One thing I thought about was to limit the output to latest N
entries from both sides. That would also be easier to implement
if we do a single merge-base traversal and reuse the result.
Yeah, the real advantage to doing it in-process is being able to give a
particularly useful overview. Also, I think spawning a pager for it is
distracting.
I've also got a change to make it do this report for "git checkout" and
"git checkout HEAD" so you can find out if the current branch needs
anything, but I want to look at it again while not so sleepy before
sending it, and also write some tests.
-Daniel
*This .sig left intentionally blank*