Junio C Hamano wrote: > To me, it looks like all that is necessary is to accept your patch > but with a three-byte tightening to detect such a pathological case > and signal an error, which is what " &&", which I added to your new > line that sets revp=$(peel_committish ...), is about. > > This patch, with or without these extra " &&" three bytes, will not > be part of the upcoming 2.0 release anyway, so we have enough time > to iron it out. Ah, right, sorry, somehow I missed the " &&" in the amended patch. I don't know how I overlooked that. That indeed would be plenty. > Sorry, I am lost. What would be a problem exactly? > > A FETCH_HEAD can be pointing at an object that is not committish, > and users involved, both at the originating end who controls the > repository you fetched from and at the receiving end who wanted to > fetch the object, are *not* expeting to be able to make a merge of > such an object anyway. My suggestion was not to ask you to come up > with a sane behaviour when the user told us to add a single blob > with "subtree add"; it was merely to detect such unintended use as > an error. Yeah, what I meant by problem was the possibility of finding a way to pre-empt the case of a tag pointing to a blob and handle it as gracefully as possible, and try to leave the user with their working tree in the state from before the subtree call. The reason I'd suggest it might be worth handling at some point is that (in the far flung future) it may not be out of the scope of subtree to pull not only other repos to a local subtree, but also specific trees (or perhaps blobs) to a local subtree. Conceptually, I'd argue that a sensible future functionality in order to allow subtree users to deal with upstreams that don't split their projects up sanely (cough splutter Facebook's internal). Hence, working out a way to determine tag types, possibly before doing the fetch somehow, would be a boon to that methinks. Of course, this is something I haven't yet thought enough about and the idea is likely full of holes, but hey, I'm nothing if not impractically idealist. --- Regards, James Denholm. -- 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