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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html