Re: 'upstream' branches.

[David Woodhouse <dwmw2@infradead.org>]

On Sun, 2007-05-06 at 18:20 -0700, Junio C Hamano wrote:
> Of course not.  Why are you even _PUBLISHING_ what your
> upstreams' origins are to begin with? 

I have the master mtd-2.6.git tree on the server, of course. 
I have a bunch of clones of that, on various computers I might be
sitting in front of. On each of those, I might pull from the upstream
tree (directly or indirectly) and push to my server. On each of those, I
might pull from my server and then set about pushing stuff to linus,
which starts with 'git-diff linus..' to vet it for sanity and 'git-log
linus..' to create a pull request.

I don't _care_ how commits from Linus' tree get into my tree. I just
want to know which is the latest commit in my tree that came from
upstream. How it got there is an implementation detail.

The other thing it's used for is excluding upstream commits from being
sent to the MTD commits list. Anything in the 'linus' branch won't get
sent. I _do_ have a fallback which also excludes any commits in the
local mirror of upstream -- but that mirror is pulled by git:// and only
daily, while my merges are usually from ssh://master.kernel.org/... so
when I merge and push to the server, the 'linus' branch may be many
commits ahead of the local mirror of upstream.

> By this, you are effectively getting the origin as seen by other
> people, and taking the most advanced one as the union of the
> origins.
> 
> But step back and think about the reason why you would even want
> to know about the origin of each of your buddies 

I don't. Except when I've pulled from them, and they've pulled from
Linus since I did. When I prepare for a merge to Linus, I don't _care_
about the last time _I_ pulled from upstream. I just care about the
latest commit which came from upstream, by whatever route.

Likewise, when I'm working on the OLPC git tree and I want to see what
we've got outstanding from Linus' tree.

> ... On the other hand, the earlier "diff" now needs to be written like
> this:
> 
> 	$ git diff $(git merge-base linus A)..A
> 
> Because this is the right thing to do in regular cases anyway,
> we even have a short-hand for that in the "three dot" form:
> 
> 	$ git diff linus...A
> 
> I think you already know these two things: "git-log linus..A is
> the right way to ask what A did relative to Linus, even when
> 'linus' is ahead of what A based his work on" and "the three-dot
> notation linus...A is the right thing to use when 'linus' could
> be ahead of what A is based on". 

OK, that works for much of the local tracking stuff -- I wasn't
previously aware of the 'linus...A' notation.

So I can just 'git-fetch linus; git-log linus...' when preparing to
merge upstream, instead of trying to keep track of the merge-base across
many repositories. Thanks.

It doesn't solve the problem of what to exclude from the commits list. 
But it does at least reduce the scope of the problem -- I only need to
handle that on my own trees, and it _will_ only ever go forward (because
I only ever do 'git-pull linus' in my clone of the mtd tree if it's
going to be immediately followed by 'git-push origin'.

-- 
dwmw2