Heya, On Tue, Aug 9, 2011 at 00:24, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Hmm, which means you have a way to say "explicitly affirmative" vs "no > information", but no way to say "explicitly negative", for example, and > the worse part is that it is unclear if the approach the patch takes is > extensible enough to allow that in the future. That is the kind of "myopic > hack" attitude I did not particularly like in this patch. Do we have a way to say explicitly negative on the commandline? Is there a way to say "I don't want you to decorate this commit as anything at all"? > "The next person who needs more generic framework can rip out what this > patch does and the work required is the same amount" is not a convincing > argument---it would mean you are burdening that other person with an extra > work to _redo_ what this series does properly, and it is not likely to be > of help for that person after your interest in this codepath has long > waned. Be fair. How is "2 files changed, 8 insertions(+), 6 deletions(-)" going to make it any harder at all for someone who is going to be doing that huge patch series you described earlier? >> Don't we already store that in the name field? > > Please remind yourself why then it is not sufficient for your patch to > read from the name field please? Sure, we could do it. But it would be duplicating all the effort already being done in rev-parse! > After all, wasn't the issue that "master^0..master" yields an empty set > but you somehow wanted to know that the RHS of that dotdot was given as a > positive ref? The issue was that if I push "master" to origin but I already pushed a "next" which points at the same commit nothing happens because git-fast-export doesn't know to emit the "reset master :13878" line. -- Cheers, Sverre Rabbelier -- 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