git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Martin Langhoff <martin.langhoff@gmail.com>,
	Jeff King <peff@peff.net>, Steffen Prohaska <prohaska@zib.de>,
	Git Mailing List <git@vger.kernel.org>,
	Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [RFC] checkout to notice forks (Re: Minor annoyance with git push)
Date: Sat, 16 Feb 2008 20:11:35 -0800	[thread overview]
Message-ID: <7v4pc843yg.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.LNX.1.00.0802162202310.5496@iabervon.org> (Daniel Barkalow's message of "Sat, 16 Feb 2008 22:31:26 -0500 (EST)")

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.

>> +	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.

  reply	other threads:[~2008-02-17  4:12 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-08  4:44 Minor annoyance with git push Martin Langhoff
2008-02-08  4:50 ` Martin Langhoff
2008-02-08  7:48   ` Junio C Hamano
2008-02-09 11:22     ` Steffen Prohaska
2008-02-10  3:44       ` Junio C Hamano
2008-02-10 12:21         ` Johannes Schindelin
2008-02-08 11:52   ` Johannes Schindelin
2008-02-08 22:23     ` Martin Langhoff
2008-02-08 22:27       ` Mike Hommey
2008-02-08  5:38 ` Sean
2008-02-08  6:29   ` Steffen Prohaska
2008-02-08 11:50 ` Johannes Schindelin
2008-02-08 22:27   ` Martin Langhoff
2008-02-08 22:57     ` Johannes Schindelin
2008-02-09  2:46     ` Jeff King
2008-02-09  2:54       ` Jeff King
2008-02-09 13:04         ` Johannes Schindelin
2008-02-09 13:22           ` Jeff King
2008-02-09 11:22       ` Steffen Prohaska
2008-02-09  3:00 ` Jeff King
2008-02-09  3:24   ` Junio C Hamano
2008-02-09  3:55     ` Jeff King
2008-02-09 11:50     ` Martin Langhoff
2008-02-09 13:06       ` Johannes Schindelin
2008-02-10  2:24       ` Junio C Hamano
2008-02-10 10:13         ` Jeff King
2008-02-10 12:22           ` Johannes Schindelin
2008-02-17  1:08         ` [RFC] checkout to notice forks (Re: Minor annoyance with git push) Junio C Hamano
2008-02-17  3:31           ` Daniel Barkalow
2008-02-17  4:11             ` Junio C Hamano [this message]
2008-02-17  6:39               ` Daniel Barkalow
2008-02-17  7:37                 ` Junio C Hamano
2008-02-17 17:36                   ` Daniel Barkalow
2008-02-17 12:28           ` Jeff King
2008-02-20 16:01             ` Santi Béjar
2008-02-19 17:03           ` Martin Langhoff
2008-02-20 23:05             ` [PATCH] checkout: tone down the "forked status" diagnostic messages Junio C Hamano
2008-02-21  1:45               ` Jeff King
2008-02-21  3:42                 ` [PATCH] checkout: updates to tracking report Junio C Hamano
2008-02-21  5:27                   ` Jay Soffian
2008-02-21 17:02                   ` Daniel Barkalow
2008-02-21  2:56               ` [PATCH] checkout: tone down the "forked status" diagnostic messages Jay Soffian
2008-02-09 10:53   ` Minor annoyance with git push Steffen Prohaska
2008-02-09 13:10     ` Johannes Schindelin
2008-02-10  2:07       ` Junio C Hamano
2008-02-10  2:15         ` Johannes Schindelin
2008-02-10 10:17           ` Jeff King
2008-02-10 12:20             ` Johannes Schindelin
2008-02-10 12:23               ` Jeff King
2008-02-10 13:04                 ` Johannes Schindelin
2008-02-10 13:07                   ` Jeff King
2008-02-20  8:23                   ` Junio C Hamano
2008-02-20 13:06                     ` Johannes Schindelin
2008-02-20 15:20                       ` Jay Soffian
2008-02-20 15:38                         ` Johannes Schindelin
2008-02-21 22:35                           ` Steven Walter
2008-02-22  0:11                             ` Johannes Schindelin
2008-02-20 14:03                     ` Jeff King
2008-02-20 17:54                       ` Junio C Hamano
2008-02-20 18:15                         ` Jeff King
2008-02-20 18:17                           ` Jeff King
2008-02-20 18:19                           ` Junio C Hamano
2008-02-20 18:23                             ` Jeff King
2008-02-10 14:03           ` Wincent Colaiuta
2008-02-10 15:02             ` Steven Walter
2008-02-10 16:29               ` Johannes Schindelin
2008-02-10 16:26             ` Johannes Schindelin
2008-02-10 18:18               ` Wincent Colaiuta
2008-02-10 22:34                 ` Jeff King
2008-02-10 22:59                   ` Junio C Hamano
2008-02-10 23:29                     ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v4pc843yg.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=martin.langhoff@gmail.com \
    --cc=peff@peff.net \
    --cc=prohaska@zib.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).