Re: [RFC] checkout to notice forks (Re: Minor annoyance with git push)
- From
Daniel Barkalow <barkalow@iabervon.org>
- Date
- Feb 17, 2008, 06:39 UTC
- Message-ID
- <alpine.LNX.1.00.0802170114440.5496@iabervon.org>
- In-Reply-To
- <7v4pc843yg.fsf@gitster.siamese.dyndns.org>
On Sat, 16 Feb 2008, Junio C Hamano wrote:
Show 25 quoted lines
> Daniel Barkalow <barkalow@iabervon.org> 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.
>
> >> +/*
> >> + * 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.
Show 31 quoted lines
> >> + 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*