David Woodhouse [off-list ref] writes:
So that 'git-diff linus..' or 'git-log linus..' will show me what's
outstanding against the master('s) tree. And scripts feeding the commits
list can ignore those commits, etc.
quoted
On the other hand, I think it is perfectly reasonable thing to
want to track where the tip of Linus's tree is "from mtd tree's
point of view". Then diff between "mtd's idea of Linus's tip"
and "mtd's tip" would represent what mtd people did, regardless
of what Linus did in his tree, before mtd people had a chance to
sync again with Linus.
Right. That's what I'm trying to track. And that 'idea of Linus' tip'
needs to get updated whenever we pull from Linus' tree into our
mtd-2.6.git tree on the server -- by whatever route, even if it's
indirectly through another repo.
Ahh, I did not mean by "mtd's idea" _your_ repository, but I
meant whichever one that was overwriting your 'linus' tracking
branch you are using to track fetch from Linus's tree.
The cleanest way to view "what do we really have since the
latest of Linus, regardless of how and from whom we learned
where the tip of Linus is", would be not to let other trees to
disturb the tracking branch you use for Linus's tree with each
other.
[remote "a"] fetch = refs/heads/linus:refs/remotes/a/linus
[remote "b"] fetch = refs/heads/linus:refs/remotes/b/linus
[remote "c"] fetch = refs/heads/linus:refs/remotes/c/linus
...
Then
git log master --not remotes/a/linus remotes/b/linus remotes/c/linus
Is that possible? I'm fairly sure it used to be.
I doubt we had that bug. If you allowed overwriting with +, it
would not have prevented a rewind (i.e. pull from Linus and then
pull from somebody who pulled from Linus earlier than you did).
If you didn't, then it would have failed the fetch.
On Sun, 2007-05-06 at 01:00 -0700, Junio C Hamano wrote:
Ahh, I did not mean by "mtd's idea" _your_ repository, but I
meant whichever one that was overwriting your 'linus' tracking
branch you are using to track fetch from Linus's tree.
Ah, right.
The cleanest way to view "what do we really have since the
latest of Linus, regardless of how and from whom we learned
where the tip of Linus is", would be not to let other trees to
disturb the tracking branch you use for Linus's tree with each
other.
[remote "a"] fetch = refs/heads/linus:refs/remotes/a/linus
[remote "b"] fetch = refs/heads/linus:refs/remotes/b/linus
[remote "c"] fetch = refs/heads/linus:refs/remotes/c/linus
...
You're speaking from the point of view of the git implementation.
From the point of view of the _user_, I would violently disagree :)
Having pulled that into my local repository, how do I then set it up to
push the latest commit of refs/remotes/*/linus into the 'linus' branch
of the origin, when I push back to my public tree on the server? Or do
you expect _everyone_ who pulls from that public tree to also do stuff
like:
git log master --not remotes/a/linus remotes/b/linus remotes/c/linus
Can't I instruct it to _merge_ the 'linus' branch of each remote into my
own 'linus' branch? Of course that merge would only ever be a
fast-forward or a no-op, in practice.
--
dwmw2
Junio C Hamano, Sun, May 06, 2007 10:00:25 +0200:
quoted
Is that possible? I'm fairly sure it used to be.
I doubt we had that bug. If you allowed overwriting with +, it
would not have prevented a rewind (i.e. pull from Linus and then
pull from somebody who pulled from Linus earlier than you did).
If you didn't, then it would have failed the fetch.
Maybe we should not fail in the case the remote repo is older then
local, but just to try to fast-forward local reference after a fetch
and fail only if the fast-forward fails?
Or introduce a new syntax for the strict reference succession and make
fetch+fast-forward the default?
Or the other way around, use something like "-from:to" to ignore
fast-forwards failed because the "from" already has all the "to" has,
which has precedents: make and its "-include", which ignores errors
from non-existing files.
Let us the local repo being in history younger then the remote:
Whole history (anywhere) : A--B--C--D
Local has (branch Tracking) : A--B
Remote1 (where the Local is doing a fetch from): A--B--C
Normal case, fetch will just update its reference in Local. It is now
at C.
Now suppose we have another remote Remote2, which is on B still. If
Local does a fetch from that, usually the operation will fail. But if
we do, for example, a fetch from Remote2 and store its reference
locally somewhere and then try to merge Local with the stored
reference, it shall result in nothing: everything's already merged:
$ git branch
* master
Tracking
$ git fetch Remote1 master:Tracking
...reference Tracking updated
$ git fetch Remote2 master:tmp
$ git checkout Tracking
$ git merge tmp
Already up-to-date.
$ git branch -d tmp
$ git checkout master