Hi, On Wed, 1 Feb 2006, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes: > > > I think it would be trivial: just resolve ~A to the tree A points to: > > <tired> Hmph. I thought you meant "have-only A" to mean similar > to "have A" but additionally "do not assume I have things behind > A", and are going to extend rev-list to support ~A syntax to do > that. I am a bit surprised to see your "rev-list ~A" is to > include A, not exclude A and not what are behind A. Where is > the connection between this and "have-only A"? </tired> ;-) <tired> My patch was wrong. You'd have to introduce a new flag saying: Traverse this commit, but mark its parents as uninteresting. </tired> > > Now, is it possible that a fetch does something unintended, when there are > > grafts which are not cutoffs? I don't know yet, but I think so. > > I think we are disagreeing, so "not Exactly". I meant "grafts > are grafts, there is no cutoffs, they are also just grafts". So > the answer to your question is "it does not matter". Scenario: I have cvsimported a project. Using a graft, I told git that a certain commit is indeed a merge between two branches. That is, in addition to the parent the commit objects tells us about, it has another parent which was tip of another branch. How would this graft be interpreted by the server we want to pull from? As if we had cut off the history. Which we did not. In effect, we could be sent many, many objects we already have. Ciao, Dscho - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Fri Feb 03 05:45:32 2006
This archive was generated by hypermail 2.1.8 : 2006-02-03 05:45:41 EST