From: Marco Costalba Date: Sun, 10 Sep 2006 04:23:11 GMT Subject: Re: Change set based shallow clone Message-ID: In-Reply-To: <7vpse4uzos.fsf@assigned-by-dhcp.cox.net> On 9/10/06, Junio C Hamano wrote: > "Marco Costalba" writes: > > > On 9/9/06, Linus Torvalds wrote: > >> > >> The example is > >> > >> A <--- tip of branch > >> / \ > >> B E > >> | | > >> | F > >> | / > >> C > >> | > >> D > >> ... > >> > > > > Ok now it' clear, thanks. But anyhow I think that it should be > > possible to avoid the check and reordering on the receiver side. > > > > Suppose for a moment to split the graph drawing from the sequence > > reordering problem, suppose for a moment that receiver does do not > > draw the graph immediately. > > > > As you described, in our case git-rev-list sends the following sequence: > > A, B, C, D, E, F > > > > instead git-rev-list --topo-order would have sent something like > > A, E, F, B, C, D > > > > Now I ask, is it possible to have a sequence (without latency) like > > A, B, C, D, (-3)E, (-3)F > > > > where, in case of not topological correct revisions, git-rev-list > > gives the hint on the correct position in sequence (3 revs before in > > our case) where the revision would have been if the sequence would > > have been --topo-order ? > > When rev-list is writing E out, it does not know it is a > descendant of something it already emitted (i.e. C) because it > hasn't looked at F nor checked its parent yet. So asking for > (-3)F may be fine but I think (-3)E is just a fantasy. > Ok. What about something like this? A, B, C, D, E, (-3, 1)F where -3 is the correct position in sequence and 1 is the number of revisions before F to whom apply the -3 rule. >