From: Santi Béjar <sbejar@gmail.com>
Date: Wed, 20 Feb 2008 16:01:15 GMT
Subject: Re: [RFC] checkout to notice forks (Re: Minor annoyance with git push)
Message-ID: <8aa486160802200801p28b74755xd1242a74c0e417a8@mail.gmail.com>
In-Reply-To: <20080217122815.GA26031@sigill.intra.peff.net>

On Sun, Feb 17, 2008 at 1:28 PM, Jeff King <peff@peff.net> wrote:
> On Sat, Feb 16, 2008 at 05:08:22PM -0800, Junio C Hamano wrote:
>
>  > and you say "git checkout next", then after we switch the branch
>  > we check the upstream (in this case, refs/remotes/linus/next)
>  > and our branch, and:
>  >
>  >     (1) if they match, nothing happens;
>  >
>  >     (2) if you are ahead (i.e. the upstream is a strict ancestor
>  >         of you), one line message tells you so;
>  >
>  >     (3) otherwise, you are either behind or you and the upstream
>  >         have forked.  One line message will tell you which and
>  >         then you will see a "log --pretty=oneline --left-right".
>
>  Overall I think this is a sensible idea. For (3), it probably makes
>  sense to limit the output in some cases. If I checkout a topic branch
>  that I haven't looked at in a few days or even weeks, I am going to get
>  spammed with hundreds of commits.
>
>  Most of the time what I really want to know is "I am not up to date and
>  should merge or rebase." Automatically showing _which_ commits diverge
>  is a convenience that makes sense if there are a handful of them. For
>  larger cases, the user can easily run "git log upstream...branch".

I prefer to always have a summary as:

The tracking branch is ahead:
 $branchsha1..$upstreamsha1 (<n> commits)

and

Branch and tracking branch have diverged:
 $branchsha1...$upstreamsha1 (<n>|<m> commits)

or something like that.

Additionally, the text send to stderr (Switched to... Your branch can
be fast...) is hidden when the pager run.

Santi